In-vehicle relay device, program, and information processing method
Patent Information
- Application Number
- JP2025060604
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2025-04-01
- Publication Date
- 2026-10-14
AI Technical Summary
【0007】 本開示の一態様によれば、中継先となる車内通信部が同一の2つのフレームを統合した統合フレームを生成して出力する車載中継装置等を提供することができる。
Smart Images

Figure 2026167171000001_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to an in-vehicle relay device, a program, and an information processing method.
Background Art
[0002] Vehicles are equipped with ECUs (Electronic Control Units) for controlling in-vehicle devices such as drive control systems for engine control and the like, and body systems for air conditioner control and the like. Each ECU includes an arithmetic processing unit such as an MPU, a rewritable nonvolatile storage unit such as an EEPROM, and a communication unit for communicating with other ECUs, and reads and executes a control program stored in the storage unit, thereby controlling the in-vehicle devices. Further, a vehicle is mounted with a communication device having a wireless communication function, which communicates with a program providing apparatus connected to a network outside the vehicle via the communication device, can download (receive) the control program of the ECU from the program providing apparatus, and update the control program of the ECU (for example, see Patent Document 1).
Prior Art Documents
Patent Documents
[0003]
Patent Document 1
Summary of Invention
Problems to be Solved by the Invention
[0004] However, the communication device (relay device) of Patent Document 1 does not give any consideration to generating and outputting an integrated frame obtained by integrating two frames having the same in-vehicle communication unit as the relay destination.
[0005] An object of the present disclosure is to provide an in-vehicle relay device and the like capable of generating and outputting an integrated frame obtained by integrating two frames having the same in-vehicle communication unit as a relay destination.
Means for Solving the Problems
[0006] An in-vehicle relay device according to one aspect of the present disclosure is an in-vehicle relay device connected to an in-vehicle network mounted on a vehicle, comprising: a plurality of in-vehicle communication units that acquire frames transmitted and received between a plurality of in-vehicle ECUs connected to the in-vehicle network; and a control unit that performs relay processing on the frames acquired via the in-vehicle communication units, wherein the control unit identifies two frames from the plurality of acquired frames that are the same in-vehicle communication unit to be relayed, generates an integrated frame by integrating the two identified frames, and outputs the generated integrated frame via the in-vehicle communication unit to be relayed. [Effects of the Invention]
[0007] According to one aspect of this disclosure, it is possible to provide an in-vehicle relay device, etc., that generates and outputs an integrated frame by integrating two identical frames at the in-vehicle communication unit that serves as the relay destination. [Brief explanation of the drawing]
[0008] [Figure 1] This is a schematic diagram illustrating the configuration of an in-vehicle system including an in-vehicle relay device according to Embodiment 1. [Figure 2] This is a block diagram illustrating the physical configuration of an in-vehicle relay device. [Figure 3] This is an explanatory diagram illustrating integration within the CAN frame. [Figure 4] This flowchart illustrates the processing performed by the control unit and other components of an in-vehicle relay device. [Figure 5] Embodiment 2 is an explanatory diagram illustrating the integration in a CANFD frame. [Figure 6] This is an explanatory diagram illustrating integration necessity information (integration necessity table). [Figure 7] This flowchart illustrates the processing performed by the control unit and other components of an in-vehicle relay device. [Modes for carrying out the invention]
[0009] [Description of Embodiments in this Disclosure] First, embodiments of this disclosure will be listed and described. Furthermore, at least some of the embodiments described below may be arbitrarily combined.
[0010] (1) An in-vehicle relay device according to one aspect of the present disclosure is an in-vehicle relay device connected to an in-vehicle network mounted on a vehicle, comprising: a plurality of in-vehicle communication units that acquire frames transmitted and received between a plurality of in-vehicle ECUs connected to the in-vehicle network; and a control unit that performs relay processing on the frames acquired via the in-vehicle communication units, wherein the control unit identifies two frames from the plurality of acquired frames that are the same in-vehicle communication unit to be relayed, generates an integrated frame by integrating the two identified frames, and outputs the generated integrated frame via the in-vehicle communication unit to be relayed.
[0011] In this embodiment, the in-vehicle relay device is communicatively connected to a plurality of in-vehicle ECUs mounted on the vehicle and relays frames (communication data) transmitted and received between these in-vehicle ECUs. At this time, a relay table is stored in a storage area accessible by the control unit of the in-vehicle relay device, such as the storage unit of the in-vehicle relay device. The relay table stores, for example, an identifier (message ID, in the case of a CAN frame: CAN-ID) that uniquely defines the type or classification of a frame, and the channel number (CH) of the in-vehicle communication unit to which the frame with the identifier (CAN-ID) is relayed, in association with each other. The control unit of the in-vehicle relay device identifies two frames from among the multiple frames that are relayed to the same in-vehicle communication unit by referring to the relay table. At this time, the control unit of the in-vehicle relay device may determine the combination of frames to be identified as the two frames in order from the frame with the highest priority among the multiple frames that have been acquired. If the frame protocol is CAN or CANFD, the control unit of the in-vehicle relay device may determine priority based on the CAN-ID (message ID) of the frame (CAN frame, etc.), according to the relative magnitudes of the CAN-IDs. In this case, the control unit of the in-vehicle relay device may determine that a smaller CAN-ID value corresponds to a higher priority. The in-vehicle relay device is equipped with multiple in-vehicle communication units, each of which is connected to a communication line, such as a CAN bus. The in-vehicle relay device acquires frames from each of these in-vehicle communication units, buffers (temporarily stores) multiple frames acquired from multiple in-vehicle ECUs connected to different communication lines (CAN buses), and generates a single integrated frame by integrating two frames from the same in-vehicle communication unit that is the relay destination. Therefore, the integrated single integrated frame stores the identifiers (CAN-IDs) and transmission data of the two identified frames (the two frames before integration).By integrating in this way, in the integrated frame, for example in the case of a CAN frame, fields such as SOF, RTR, control field, CRC sequence, CRC delegate, ACK slot, ACK delegate, EOF, and ITM in the frame structure can be merged or shared. In other words, the header and tail are reduced to one, so the overall frame length of the integrated frame is smaller than the sum of the overall frame lengths of the two specified frames (the two frames before integration). That is, the frame size of the integrated frame can be smaller than the sum of the frame sizes of the two frames before integration. By outputting this integrated frame, which is created by integrating two frames in this way, to the in-vehicle network via the in-vehicle communication unit that serves as the relay destination, the communication load (traffic) in the in-vehicle network can be efficiently reduced. Therefore, if CAN frames are transmitted periodically at predetermined transmission intervals (e.g., 10ms, 20ms, 50ms, 100ms), even if the transmission intervals differ, the transmission timings will coincide at the least common multiple of the transmission intervals of each frame (e.g., 100ms), resulting in a high load condition. This raises concerns about communication delays and relay buffer overflow. However, when the transmission timings (communication timings) overlap, the two frames are combined (combined) into a single integrated frame for transmission, thereby suppressing the occurrence of this high load condition.
[0012] (2) An in-vehicle relay device according to one aspect of the present disclosure wherein the frame is a standard format CAN frame or CANFD frame, and the integrated frame is an extended format CAN frame or CANFD frame.
[0013] In this embodiment, the frame is a standard format CAN frame or CANFD frame, and in the standard format, the ID (ID field) in which the CAN-ID (message ID) is stored has a field length of 11 bits. The integrated frame is an extended format CAN frame or CANFD frame, and in the extended format, the fields corresponding to the ID (ID field) in the standard format include an 11-bit base ID (base ID field) and an 18-bit extended ID (extended ID field). Therefore, in the extended format, a field length of 29 bits (29 = 11 + 18) can be secured, so that the CAN-IDs of each of the two specified frames (the two frames before integration) can be reliably stored.
[0014] (3) An in-vehicle relay device according to one aspect of the present disclosure, wherein the integrated frame includes a base ID and an extended ID, and the control unit stores the message ID of the frame with higher priority among the two identified frames in the base ID and the message ID of the frame with lower priority in the extended ID.
[0015] In this embodiment, the integrated frame includes an 11-bit base ID (base ID field) and an 18-bit extended ID (extended ID field). Of the two identified frames (two frames before integration), the CAN-ID of one frame is stored in the base ID (base ID field), and the CAN-ID of the other frame is stored in the extended ID (extended ID field). In this case, in the integrated frame (extended format), the base ID (base ID field) is located at the beginning of the extended ID (extended ID field). The control unit stores the CAN-ID of the frame with higher priority, i.e., the frame with the smaller CAN-ID value, in the base ID, and the CAN-ID of the frame with lower priority, i.e., the frame with the larger CAN-ID value, in the extended ID. Therefore, in the two frames integrated into the integrated frame, the arrangement order according to the priority of the frames can be configured using the base ID and extended ID, and the arbitration priority in CAN can be maintained even in the integrated frame. This clarifies the integration rules in accordance with the arbitration priority in CAN, and enables the vehicle ECU (receiving ECU) that receives the integrated frame to efficiently extract signals from the integrated frame, even if there are no prior definitions. In this case, the control unit may store the transmission data of the higher-priority frame (the frame with the smaller CAN-ID value) from the first bit in the data field (payload area) of the integrated frame, similar to the CAN-ID, and store the transmission data of the lower-priority frame (the frame with the larger CAN-ID value) in the bits after the transmission data of the higher-priority frame. By making the storage order of the CAN-ID and the storage order of the transmission data the same in the two frames to be integrated, the vehicle ECU (receiving ECU) that receives the integrated frame can efficiently extract signals from the integrated frame, even if there are no prior definitions.The control unit calculates the sum of the data lengths (DLC) of the transmitted data from each of the two frames to be merged, and stores the calculated data length (DLC) in the DLC (Data Length Code) of the control field in the merged frame. Furthermore, the control unit may also store the DLC value of the lower-priority frame (the frame with the larger CAN-ID value) along with the CAN-ID of the lower-priority frame in the extended ID (extended ID field) of the merged frame. In this way, the extended ID (extended ID field) of the merged frame stores the CAN-ID and DLC value of the lower-priority frame, and the DLC of the control field in the merged frame stores the sum of the DLC values of the two frames. By subtracting the DLC value of the lower-priority frame from this sum, the DLC value of the higher-priority frame can be derived. In this way, the control unit generates the merged frame as a variable-length frame by defining the data length (DLC) of the merged frame according to the sum of the data lengths (DLC) of the transmitted data from each of the two frames to be merged. This optimizes the field length (size) of the data field (payload area) in the integrated frame, preventing the frame size of the integrated frame from becoming excessively large, and effectively suppressing the increase in communication load (traffic) in the in-vehicle network.
[0016] (4) An in-vehicle relay device according to one aspect of the present disclosure, wherein the frame is a CANFD frame in a standard format, and the integrated frame is a CANFD frame in an extended format, and the control unit generates an integrated frame by integrating the two identified frames if the sum of the transmission data lengths of the two identified frames exceeds 8 bytes, and the value obtained by subtracting the sum of the transmission data lengths of the two identified frames from the data length of the data field defined in the integrated frame is less than a predetermined threshold, and outputs the two identified frames via the in-vehicle communication unit that is the relay destination without integrating them if the value obtained by subtracting the sum of the transmission data lengths of the two identified frames from the data length of the data field defined in the integrated frame is equal to or greater than the threshold,
[0017] In this embodiment, the frame is a standard format CANFD frame, and the integrated frame is an extended format CANFD frame. In the CANFD frame, the length of the data field, i.e., the DLC value, increases in increments of 1 byte from 0 to 8 bytes, and when it exceeds 8 bytes, it is defined as one of the following values: 12, 16, 20, 24, 32, 48, or 64 bytes. That is, in a CANFD frame, if the size of the transmitted data exceeds 8 bytes, the length of the data field (DLC value) increases by a value exceeding 1 byte (increment value: 4, 8, or 168 bytes). In response to this, when the sum of the transmitted data lengths of two identified frames exceeds 8 bytes, the control unit determines whether integration is necessary based on the difference between the value obtained by subtracting the sum of the transmitted data lengths of the two frames to be integrated from the data length of the data field defined in the integrated frame, and a predetermined threshold. The data length of the data field defined in the integrated frame is the smallest of the following values, which are defined when the data length is greater than the sum of the data lengths of the transmitted data from the two frames to be integrated and exceeds 8 bytes: 12, 16, 20, 24, 32, 48, or 64 bytes. That is, if the sum of the data lengths of the transmitted data from the two frames is 13 bytes, then 16 bytes will be defined as the data field length (DLC value) of the integrated frame. In this case, if the value obtained by subtracting the sum of the data lengths of the transmitted data from the two frames (for example, 3 bytes = 16 - 13) from the data field length (DLC value) of the integrated frame is less than a predetermined threshold, an integrated frame will be generated; otherwise, an integrated frame will not be generated.The threshold is a frame length (size) that can be reduced by integrating two frames into an integrated frame. For example, in the integrated frame (extended format), it is the frame length (size) that is reduced by merging or sharing SOF, RTR, control field, CRC sequence, CRC delimiter, ACK slot, ACK delimiter, EOF, ITM, etc., that is, by reducing or fusing the header and tail part into one. When the value obtained by subtracting the sum of the transmission data lengths from the data length of the data field defined in the integrated frame is equal to or greater than the threshold, the free space of the data field becomes equal to or greater than the threshold, that is, exceeds the frame length (size) that can be reduced by integration, making it impossible to reduce the communication load in the in-vehicle network by the integrated frame. In contrast, when the sum of the transmission data lengths of the two identified frames exceeds 8 bytes, the control unit does not uniformly integrate the two frames, but determines the necessity of integration based on the difference from a predetermined threshold, so that it is possible to reliably prevent a situation where the transmission bits become longer on the contrary due to the integrated frame.
[0018] (5) An in-vehicle relay device according to an aspect of the present disclosure stores integration necessity information in which the necessity of integration according to the combination of the transmission data lengths of the two identified frames and the threshold is defined, in a storage area accessible by the control unit, and the control unit refers to the integration necessity information to determine the necessity of integrating the two identified frames.
[0019] In this aspect, in a storage area accessible by the control unit, such as a storage unit of the in-vehicle relay device, integration necessity information in which the necessity of integration corresponding to a combination of transmission data lengths of two specified frames and a threshold is defined is stored in, for example, a table format (integration necessity table). The integration necessity table has, for example, a matrix form in which the data length of one frame (DLC value) is defined in horizontal items and the data length of the other frame (DLC value) is defined in vertical items, and the necessity of integration is stored (defined) according to the combination of the data length of one frame and the data length of the other frame. The integration necessity information (integration necessity table) is defined based on a relationship corresponding to a difference between a value obtained by subtracting the sum of the data lengths of the transmission data of each of the two frames to be integrated from the data length of the data field defined in the integrated frame, and a predetermined threshold. That is, the integration necessity information (integration necessity table) is defined such that the free space of the data field defined in the integrated frame does not exceed the threshold, that is, does not exceed the frame length (size) that can be reduced by integration. The control unit can refer to the integration necessity information to determine the necessity of integration for the combination of the data lengths (DLC values) of the two frames to be integrated. As described above, when determining the necessity of integration for the combination of the data lengths (DLC values) of the two frames to be integrated, the control unit refers to the integration necessity information, so that arithmetic processing such as calculation of the sum of the data lengths corresponding to the combination and subtraction between the calculated sum and the threshold can be omitted, the arithmetic load on the control unit is reduced to shorten the processing time, and the necessity of integration can be efficiently determined.
[0020] (6) In the in-vehicle relay device according to one aspect of the present disclosure, the storage area accessible by the control unit includes a buffer area for temporarily storing the frames acquired via the in-vehicle communication unit, and the control unit specifies, among the plurality of the frames stored in the buffer area in a predetermined processing unit period, the two frames having the same in-vehicle communication unit serving as a relay destination.
[0021] In this embodiment, the control unit temporarily stores frames acquired via multiple in-vehicle communication units by buffering them in a buffer area pre-allocated in the storage unit. After transmission of a frame, the frame temporarily stored in the buffer area is deleted. Transmission of such frames includes transmission of an integrated frame. The control unit performs relay processing on the buffered multiple frames at predetermined processing unit intervals; that is, these multiple frames are relayed at the same relay timing. At this time, the control unit identifies two frames from among the multiple frames stored in the buffer area during the processing unit interval (same relay timing) that have the same in-vehicle communication unit as the relay destination, i.e., two frames with the same CAN bus as the relay destination, and integrates them into an integrated frame. By integrating the two identified frames into an integrated frame according to the processing unit interval (same relay timing) in this way, it is possible to efficiently reduce the communication load (traffic) in the in-vehicle network while suppressing deterioration or excessive occurrence of delay or latency in the relay processing.
[0022] (7) A program according to one aspect of the present disclosure includes a plurality of in-vehicle communication units connected to an in-vehicle network mounted in a vehicle, which acquire frames transmitted and received between a plurality of in-vehicle ECUs connected to the in-vehicle network, and causes a computer that performs relay processing of the frames acquired via the in-vehicle communication units to identify two frames from the plurality of acquired frames that are the same in-vehicle communication unit to be relayed, generate an integrated frame by integrating the two identified frames, and output the generated integrated frame via the in-vehicle communication unit to be relayed.
[0023] In this embodiment, a program can be provided that causes the in-vehicle communication unit, which is the relay destination, to run as an in-vehicle relay device that generates and outputs an integrated frame by integrating two identical frames.
[0024] (8) An information processing method according to one aspect of the present disclosure includes a plurality of in-vehicle communication units connected to an in-vehicle network mounted on a vehicle and which acquire frames transmitted and received between a plurality of in-vehicle ECUs connected to the in-vehicle network, and causes a computer that performs relay processing of the frames acquired via the in-vehicle communication units to identify two frames from the plurality of acquired frames that are the same in-vehicle communication unit to be relayed, generate an integrated frame by integrating the two identified frames, and output the generated integrated frame via the in-vehicle communication unit to be relayed.
[0025] In this embodiment, it is possible to provide an information processing method that causes the in-vehicle communication unit, which is the relay destination, to operate as an in-vehicle relay device that generates and outputs an integrated frame by integrating two identical frames.
[0026] [Details of the Embodiments of the Invention] The present invention will be specifically described based on the drawings illustrating its embodiments. An in-vehicle relay device 2 according to an embodiment of this disclosure will be described below with reference to the drawings. However, the present invention is not limited to these examples and is intended to include all modifications within the meaning and scope equivalent to the claims as indicated by the claims.
[0027] (Embodiment 1) The embodiments will be described below with reference to the drawings. Figure 1 is a schematic diagram illustrating the configuration of an in-vehicle system S including an in-vehicle relay device 2 according to Embodiment 1. Figure 2 is a block diagram illustrating the physical configuration of the in-vehicle relay device 2. The in-vehicle system S is configured with the in-vehicle relay device 2 as the main device, and the in-vehicle relay device 2 is connected to an in-vehicle ECU 3 (Electronic Control Unit) connected to an in-vehicle network 4 so as to be able to communicate. Furthermore, the in-vehicle relay device 2 may be connected to an external server (OTA server, etc.) located outside the vehicle via an external communication device 1 connected to the in-vehicle relay device 2 so as to be able to communicate.
[0028] The in-vehicle relay device 2 relays communication data (such as CAN frames) transmitted and received between in-vehicle ECUs 3 connected to the in-vehicle network 4. The in-vehicle relay device 2 is a gateway that manages multiple bus (segment) systems, such as control system in-vehicle ECUs 3, safety system in-vehicle ECUs 3, and body system in-vehicle ECUs 3, and relays communication between these buses (segments) between the in-vehicle ECUs 3. Each of the communication lines 41 constituting these multiple CAN buses (segments) is connected to the in-vehicle relay device 2, and the in-vehicle network 4 is formed by the multiple communication lines 41 (segments) aggregated by the in-vehicle relay device 2. The in-vehicle relay device 2 includes a control unit 20, a storage unit 23, an input / output interface 21, and an in-vehicle communication unit 22.
[0029] The control unit 20 is composed of a CPU (Central Processing Unit) or an MPU (Micro Processing Unit), and performs various control and calculation processes by reading and executing a control program P (program product) and data that have been pre-stored in the storage unit 23.
[0030] The storage unit 23 is composed of volatile memory elements such as RAM (Random Access Memory) or non-volatile memory elements such as ROM (Read Only Memory), EEPROM (Electrically Erasable Programmable ROM), or flash memory. The storage unit 23 stores the control program P and data referenced during processing, such as the relay table and integration necessity table described later. Furthermore, the storage unit 23 stores various intermediate data and result data generated when the control unit 20 performs various calculation processes. The control program P (program product) stored in the storage unit 23 may be a control program P (program product) read from a recording medium M that the in-vehicle relay device 2 can read. Alternatively, the control program P may be downloaded from an external computer (not shown) connected to a communication network (not shown) and stored in the storage unit 23.
[0031] The input / output interface 21 is, for example, a communication interface for serial communication. The in-vehicle relay device 2 may be connected to an external communication device 1, etc., via the input / output interface 21.
[0032] The in-vehicle communication unit 22 is an input / output interface (CAN transceiver, CAN controller, etc.) that uses a communication protocol such as CAN or CANFD. The control unit 20 communicates with the in-vehicle ECU 3 which is connected to the in-vehicle network 4 via the in-vehicle communication unit 22.
[0033] The external communication device 1 includes an external communication unit (not shown) and an input / output interface (I / F) for communicating with the in-vehicle relay device 2. The external communication unit is a communication device for wireless communication using mobile communication protocols such as LTE®, 4G, 5G, and WiFi®, and transmits and receives data with an external server via an antenna connected to the external communication unit. Communication between the external communication device 1 and the external server is performed via an external network N, such as a public network or the Internet.
[0034] Vehicle C is equipped with multiple on-board ECUs 3 for controlling various in-vehicle devices. The on-board relay device 2 and the on-board ECUs 3 are connected to each other via an on-board network 4 that supports communication protocols such as CAN (Control Area Network) or CANFD. Various sensors such as cameras, infrared sensors, and LiDAR (Light Detection and Ranging), or various actuators such as door mirrors and lamps are connected to the on-board ECUs 3. The on-board ECUs 3 acquire various signals output from these sensors or actuators at a predetermined period (update period). The signal update period corresponds to the signal transmission period, and the on-board ECUs 3 periodically output each acquired signal via the on-board network 4 according to the signal transmission period (update period), thereby periodically transmitting it to other on-board ECUs 3 connected to the on-board network 4. The on-board ECUs 3, like the on-board relay device 2, include a control unit, a storage unit, and an in-vehicle communication unit.
[0035] Figure 3 is an explanatory diagram illustrating integration in CAN frames. In this embodiment, the two frames to be integrated are shown, that is, two frames (pre-combination CAN frame F1 and pre-combination CAN frame F2) that are the same in-vehicle communication unit 22 that will be relayed to them, among a plurality of frames stored in the buffer area during a predetermined processing unit period (same relay timing). In this case, the absolute value of the CAN-ID of frame F1 (e.g., 001h) is smaller than the absolute value of the CAN-ID of frame F2 (e.g., 002h) (001h < 002h), and therefore, the priority of frame F1 is higher than the priority of frame F2 (priority: F1 > F2).
[0036] The two frames to be merged are standard format CAN frames and include an 11-bit ID (ID field). This ID (ID field) stores the CAN-ID. The data field (payload area) of each of the two frames to be merged (standard format CAN frames) stores transmission data such as signals used when various applications are executed. The DLC of each of the two frames to be merged (standard format CAN frames) stores the data length of the transmission data.
[0037] The combined frame, formed by merging these two frames, is an extended-format CAN frame containing a base ID (base ID field) with a field length of 11 bits and an extended ID (extended ID field) with a field length of 18 bits. The base ID (base ID field) stores the CAN-ID of the higher-priority frame F1. The extended ID (extended ID field) stores the CAN-ID of the lower-priority frame F2, and also stores the DLC (Data Length Code) value of frame F2.
[0038] In the integrated frame, the DLC of the control field stores the sum of the data lengths (DLC) of the transmission data from the two frames to be integrated (frame F1 and frame F2), i.e., the total data length of frame F1 and frame F2 is set. In the data field (payload area) of the integrated frame, the transmission data of frame F1, which has higher priority, is stored from the beginning, and after the transmission data of frame F1, the transmission data of frame F2, which has lower priority, is stored.
[0039] When performing this type of integration (combination), the transmission bit length before combination is given by "94 + (total data length) × 8", and the transmission bit length after combination is given by "67 + (total data length) × 8". Therefore, by performing integration (combination), a net saving of 27 bits of time, i.e., the time required to transmit 27 bits of data, can be saved. As a result, if the bandwidth is 500kbps, the transmission time can be reduced by 54us, and if the data length is 2 bytes (1+1=2), the bus load rate, which is 24.5% (24.5 = (110-83) / 110), will be improved (reduced).
[0040] Figure 4 is a flowchart illustrating the processing performed by the control unit 20 of the in-vehicle relay device 2. The control unit 20 of the in-vehicle relay device 2 performs the following processing when, for example, vehicle C is stopped (e.g., IG switch is off) or started (e.g., IG switch is on).
[0041] The control unit 20 of the in-vehicle relay device 2 buffers frames acquired via multiple in-vehicle communication units 22 (S101). The control unit 20 of the in-vehicle relay device 2 temporarily stores the frames acquired via the multiple in-vehicle communication units 22 by buffering them in a buffer area pre-allocated in the storage unit 23. The frames are standard format CAN frames and include an ID (ID field) with a field length of 11 bits. The buffered frames are relayed at predetermined processing unit intervals. Therefore, the relay timing for the buffered frames is determined based on the processing unit interval.
[0042] The control unit 20 of the in-vehicle relay device 2 identifies two frames that are the same in the in-vehicle communication unit 22 that will be relayed to the same destination in the buffered multiple frames (S102). The control unit 20 of the in-vehicle relay device 2 identifies two frames that are the same in the in-vehicle communication unit 22 that will be relayed to the same destination in the multiple frames that will be relayed at the same relay timing (same processing unit period).
[0043] The storage unit 23 of the in-vehicle relay device 2 stores a relay table, in which the CAN-ID and the channel number (CH) of the in-vehicle communication unit 22 that will be the relay destination for the CAN-ID are stored in association. That is, the relay table includes management items for the CAN-ID and management items for the channel number (CH: a number that uniquely identifies the in-vehicle communication unit 22) as management items. The control unit 20 of the in-vehicle relay device 2 refers to the relay table to extract the in-vehicle communication unit 22 (channel number: CH) that will be the relay destination for each of the multiple frames that will be relayed at the same relay timing (same processing unit period), and identifies two frames in which the in-vehicle communication unit 22 (channel number: CH) is the same.
[0044] The control unit 20 of the in-vehicle relay device 2 generates an integrated frame by integrating the two identified frames (S103). The control unit 20 of the in-vehicle relay device 2 generates an integrated frame by integrating the two identified frames (CAN frames in standard format) assuming that the relay destination is the same. In this case, the integrated frame is a CAN frame in extended format and includes a base ID (base ID field) with a field length of 11 bits and an extended ID (extended ID field) with a field length of 18 bits.
[0045] As described above, the control unit 20 of the in-vehicle relay device 2 stores the CAN-ID of the high-priority frame (standard format) in the base ID (base ID field) of the integrated frame, and the CAN-ID of the low-priority frame (standard format) in the extended ID (extended ID field) of the integrated frame. Furthermore, the control unit 20 of the in-vehicle relay device 2 stores the DLC value of the low-priority frame (standard format) in the extended ID (extended ID field) of the integrated frame. The control unit 20 of the in-vehicle relay device 2 stores the sum of the DLC values of the two identified frames (standard format) in the DLC of the control field in the integrated frame. The control unit 20 of the in-vehicle relay device 2 stores the transmission data of the high-priority frame from the beginning of the data field (payload area) of the integrated frame, and then stores the transmission data of the low-priority frame thereafter. The integrated frame is generated by storing the CAN-ID, DCL, and transmission data contained in the two identified frames in this way in the integrated frame.
[0046] The control unit 20 of the in-vehicle relay device 2 transmits the generated integrated frame via the in-vehicle communication unit 22 which is the relay destination (S104). When the control unit 20 of the in-vehicle relay device 2 identifies two frames to be integrated, the in-vehicle communication unit 22 which is the relay destination for these two frames is the same, and the control unit 20 transmits the generated integrated frame via the in-vehicle communication unit 22 which is the relay destination.
[0047] The control unit of the in-vehicle ECU 3 receives the integrated frame transmitted by the in-vehicle relay device 2 (T101). The control unit of the in-vehicle ECU 3 receives the integrated frame transmitted by the in-vehicle relay device 2 via the in-vehicle network 4. The in-vehicle ECU 3 (receiving ECU) identifies two frames to be integrated and is connected to a communication line 41 such as a CAN bus to which the in-vehicle communication unit 22, which will be the relay destination for these two frames, is connected.
[0048] The control unit of the in-vehicle ECU3 decomposes the received integrated frame into two frames (T102). The control unit of the in-vehicle ECU3 identifies the CAN-ID of the higher-priority frame in the two integrated frames by extracting the CAN-ID stored in the base ID (base ID field) of the received integrated frame. The control unit of the in-vehicle ECU3 identifies the CAN-ID of the lower-priority frame in the two integrated frames by extracting the CAN-ID stored in the extended ID (extended ID field) of the received integrated frame.
[0049] The control unit of the in-vehicle ECU3 determines the data length of the sum of the transmitted data of the two integrated frames by extracting the value stored in the DLC of the control field (DLC value) in the received integrated frame. The control unit of the in-vehicle ECU3 determines the DLC value of the lower-priority frame by extracting the DLC value of the lower-priority frame stored in the extended ID (extended ID field) in the received integrated frame. The control unit of the in-vehicle ECU3 derives the DLC value of the higher-priority frame by subtracting the DLC value of the lower-priority frame from the value stored in the DLC of the control field (sum of the DLC values of the two frames).
[0050] The control unit of the in-vehicle ECU3 extracts data stored from the beginning of the data field (payload area) in the integrated frame based on the DLC values of the high-priority frames and the low-priority frames extracted or derived in this way. This separates or decomposes the transmission data of the high-priority frames from the transmission data of the low-priority frames, and extracts the respective transmission data. The control unit of the in-vehicle ECU3 thus decomposes a single integrated frame (extended format) into two frames (standard format), and uses the decomposed frames (standard format) to execute various applications and other processes.
[0051] (Embodiment 2) Figure 5 is an explanatory diagram illustrating the integration of CANFD frames in Embodiment 2. In the illustration of this embodiment, two frames to be integrated are shown, that is, two frames (pre-combination CANFD frame F1 and pre-combination CANFD frame F2) that are the same in-vehicle communication unit 22 to be relayed from among a plurality of frames stored in the buffer area during a predetermined processing unit period (same relay timing). In this case, the absolute value of the CAN-ID of frame F1 (e.g., 001h) is smaller than the absolute value of the CAN-ID of frame F2 (e.g., 002h) (001h < 002h), and therefore, the priority of frame F1 is higher than the priority of frame F2 (priority: F1 > F2).
[0052] The two frames to be merged are standard format CANFD frames and include an 11-bit ID (ID field). The CAN-ID is stored in this ID (ID field). The data field (payload area) of each of the two frames to be merged (standard format CANFD frames) stores transmission data such as signals used when various applications are executed. The DLC of each of the two frames to be merged (standard format CANFD frames) stores the data length of the transmission data.
[0053] The combined frame, formed by merging these two frames, is an extended-format CANFD frame containing a base ID (base ID field) with a field length of 11 bits and an extended ID (extended ID field) with a field length of 18 bits. The base ID (base ID field) stores the CAN-ID of the higher-priority frame F1. The extended ID (extended ID field) stores the CAN-ID of the lower-priority frame F2, and also stores the DLC (Data Length Code) value of frame F2.
[0054] In the integrated frame, the DLC of the control field stores the sum of the data lengths (DLC) of the transmission data from the two frames to be integrated (frame F1 and frame F2), i.e., the total data length of frame F1 and frame F2 is set. In the data field (payload area) of the integrated frame, the transmission data of frame F1, which has higher priority, is stored from the beginning, and after the transmission data of frame F1, the transmission data of frame F2, which has lower priority, is stored.
[0055] When performing such integration (combination), if the bit rate of the high-speed section is four times that of the low-speed section, the bit length of the low-speed section is used for conversion. If the data length after combination is 16 bytes or less, the transmission bit length before combination is shown as "70 + (total data length) × 2", and the transmission bit length after combination is shown as "54 + (total data length) × 2". Therefore, by performing integration (combination), a net 16 bits of time, i.e., the time required to transmit 16 bits of data, can be saved. As a result, if the bandwidth is the low-speed section rate of 500 kbps, the transmission time can be reduced by 32 us, and the bus load rate, which is 21.6% ("21.6 = (74 - 58) / 74") for a data length of 2 bytes (1 + 1 = 2), is improved (reduced).
[0056] Figure 6 is an explanatory diagram illustrating integration necessity information (integration necessity table). In the storage area accessible by the control unit 20, such as the storage unit 23 of the in-vehicle relay device 2, integration necessity information is stored, for example, in a table format (integration necessity table), which defines the necessity of integration according to the combination of transmission data lengths of two specified frames and a threshold. The integration necessity table is, for example, a matrix in which the data length (DLC value) of one frame is defined as a horizontal item and the data length (DLC value) of the other frame is defined as a vertical item. That is, both the horizontal and vertical items define the number of bytes (1, 2, 3, 4, 5, 6, 7, 8, 12, 16, 20, 24, 32, 48, 64) that can be set as the data length of the CANFD frame (data length of the data field).
[0057] A field (storage cell in the matrix) that shows the combination of the number of bytes in the vertical column and the number of bytes in the horizontal column stores whether or not integration is necessary for that combination. In this embodiment, to indicate whether or not integration is necessary, the data length (DLC value) when the number of bytes in the vertical column and the number of bytes in the horizontal column are integrated is stored, and the color scheme of the cell in which this data length is stored is saved as information indicating whether or not integration is necessary for that combination. In this embodiment, the storage cell in the matrix stores the data length (DLC value) when integrated and indicates whether or not integration is necessary by the color scheme of the cell, but it is not limited to this, and the storage cell may also store an integration necessity flag (needed: 0, not needed: 1).
[0058] Whether or not integration is necessary for a combination of the number of bytes in the vertical and horizontal fields is determined when the sum of the byte counts, i.e., the sum of the data lengths (DLC values) of the two frames to be integrated, exceeds 8 bytes. In other words, if the sum is 8 bytes or less, the data length (DLC value) of the integrated frame (CANFD frame in extended format) will increase by 1 byte at a time from 0 to 8 bytes, and therefore, the available space in the data field will not be a practical issue.
[0059] In contrast, if the data length (DLC value) of the integrated frame (CANFD frame in extended format) exceeds 8 bytes, it is defined as one of the following values: 12, 16, 20, 24, 32, 48, or 64 bytes. In this case, depending on the sum of the data lengths (DLC values) of the transmission data from the two frames to be integrated, it is possible that the free space in the data field may exceed the frame length (size) reduced by the integrated frame. This reduced frame length (size) is the size determined by the reduction of the header and tail portion into one in the integrated frame (reduced size), and the necessity of integration is determined based on a threshold corresponding to this reduced size. That is, if the value obtained by subtracting the sum of the transmission data lengths from the data length of the data field defined in the integrated frame is less than a predetermined threshold, it is determined that the generation of an integrated frame is necessary. If the value obtained by subtracting the sum of the transmission data lengths from the data length of the data field defined in the integrated frame is equal to or greater than a predetermined threshold, it is determined that the generation of an integrated frame is unnecessary.
[0060] Based on the said criteria, the integration necessity table is defined such that the free capacity of the data fields defined in the integrated frame does not exceed a threshold, i.e., the frame length (size) that can be reduced by integration. Alternatively, the integration necessity table may define that the generation of an integrated frame is necessary only if the software processing time associated with frame synthesis (integrated frame generation process) by the control unit 20 of the in-vehicle relay device 2 is shorter than the reduction in transmission time obtained by its effect (effect of integrated frame). When the integration necessity table is defined in such a way that takes into account the software processing time associated with frame synthesis, the in-vehicle system S can be expected to reduce not only the CAN bus load, i.e., the communication load in the in-vehicle network 4, but also the frame transmission delay.
[0061] Figure 7 is a flowchart illustrating the processing performed by the control unit 20 of the in-vehicle relay device 2. The control unit 20 of the in-vehicle relay device 2 performs the following processing when, for example, vehicle C is stopped (e.g., IG switch is off) or started (e.g., IG switch is on).
[0062] The control unit 20 of the in-vehicle relay device 2 buffers the frames acquired via the multiple in-vehicle communication units 22 (S201). The control unit 20 of the in-vehicle relay device 2 identifies two frames that are the same in-vehicle communication unit 22 to be relayed from among the buffered frames (S202). The control unit 20 of the in-vehicle relay device 2 executes the processes from S201 to S202 in the same way as the processes from S101 to S102 of Embodiment 1. In this case, the target frame in the process of Embodiment 1 is a CAN frame, while the target frame in the process of this embodiment is a CANFD frame, so the overall frame format is different. However, the process of buffering the frame and identifying the in-vehicle communication unit 22 to be relayed based on the CAN-ID (message ID) stored in the frame by referring to the relay table is the same for both CAN frames and CANFD frames.
[0063] The control unit 20 of the in-vehicle relay device 2 determines whether it is necessary to merge two frames that have been identified as being from the same in-vehicle communication unit 22 that will be relayed to it (S203). The control unit 20 of the in-vehicle relay device 2 calculates the sum of the transmission data lengths of the two identified frames, and determines that it is necessary to merge the two frames if the sum is 8 bytes or less.
[0064] The control unit 20 of the in-vehicle relay device 2 may determine whether to merge the two frames by referring to the merger necessity table stored in the storage unit 23 if the combined value exceeds 8 bytes. The merger necessity table defines whether to merge the two frames according to the combination of the transmission data lengths of the two frames. The control unit 20 of the in-vehicle relay device 2 identifies the combinations corresponding to the transmission data lengths of the two identified frames in the merger necessity table, and determines whether to merge the two frames by extracting the merger necessity for the identified combinations.
[0065] If it is determined that the two frames need to be merged (S203: YES), the control unit 20 of the in-vehicle relay device 2 generates a merged frame by merging the two identified frames (S204). The control unit 20 of the in-vehicle relay device 2 transmits the generated merged frame via the in-vehicle communication unit 22, which is the relay destination (S205). If it is determined that the two frames need to be merged, the control unit 20 of the in-vehicle relay device 2 executes the processes from S204 to S205 in the same way as the processes S103 to S104 of Embodiment 1. In this case, in the process of Embodiment 1, the target frame is a CAN frame, while in the process of this embodiment, the target frame is a CANFD frame, so the overall frame format is different. However, the process of generating and transmitting a merged frame is the same for both CAN frames and CANFD frames.
[0066] If it is determined that merging the two frames is unnecessary (S203: NO), the control unit 20 of the in-vehicle relay device 2 transmits each of the two identified frames separately without merging them (S2031). If it is determined that merging the two frames is unnecessary, the control unit 20 of the in-vehicle relay device 2 transmits each of the two identified frames separately via the in-vehicle communication unit 22 without merging them.
[0067] The control unit of the in-vehicle ECU 3 receives a frame transmitted by the in-vehicle relay device 2 (T201). The frame transmitted by the in-vehicle relay device 2 may be an integrated frame (CANFD frame in extended format) or a frame (CANFD frame in standard format). The control unit of the in-vehicle ECU 3 receives the frame transmitted by the in-vehicle relay device 2 and stores the received frame in the memory unit of the in-vehicle ECU 3.
[0068] The control unit of the in-vehicle ECU3 determines whether the received frame is an integrated frame or not (T202). The control unit of the in-vehicle ECU3 determines whether the received frame is an integrated frame (CANFD frame in extended format) or a frame (CANFD frame in standard format) based on whether, for example, the format of the received frame includes an extended ID (extended ID field). That is, the control unit of the in-vehicle ECU3 determines that if an extended ID (extended ID field) is included, it is an integrated frame (CANFD frame in extended format), and if an extended ID (extended ID field) is not included, it is a frame (CANFD frame in standard format). Alternatively, the control unit of the in-vehicle ECU3 may determine that it is an integrated frame if the message ID and DLC values are stored in the extended ID (extended ID field).
[0069] If the received frame is an integrated frame (T202:YES), the control unit of the in-vehicle ECU3 decomposes the received integrated frame into two frames (T203). If the received frame is an integrated frame (CANFD frame in extended format), the control unit of the in-vehicle ECU3 executes the process in T203, similar to the process T102 in Embodiment 1.
[0070] If the received frame is not an integrated frame (T202:NO), that is, if the received frame is a CANFD frame in standard format, then no decomposition process is required for the received frame (CANFD frame in standard format), and the control unit of the in-vehicle ECU3 uses the received frame to perform various application execution processes, etc.
[0071] The embodiments disclosed herein should be considered in all respects to be illustrative and not restrictive. The scope of this disclosure is indicated by the claims, not in the sense described above, and all modifications within the sense and scope equivalent to the claims are intended.
[0072] With respect to the multiple claims described in the claims, they can be combined with each other regardless of the form of reference. Multiple dependent claims that depend on multiple claims may be described in the claims. Multiple dependent claims that depend on multiple dependent claims may also be described. Even if multiple dependent claims that depend on multiple dependent claims are not described, this does not limit the description of multiple dependent claims that depend on multiple dependent claims. [Explanation of Symbols]
[0073] C Vehicle S In-vehicle system 1. External communication device 2. Vehicle-mounted relay device 20 Control Unit 21 Input / Output Interfaces 22 In-vehicle communication unit 23 Memory section M recording medium P Control Program (Program Product) 3 In-vehicle ECU 4. In-vehicle network 41 Communication lines
Claims
1. An in-vehicle relay device connected to an in-vehicle network installed in a vehicle, Multiple in-vehicle communication units that acquire frames transmitted and received between multiple in-vehicle ECUs connected to the aforementioned in-vehicle network, The system includes a control unit that performs relay processing of the frame acquired via the in-vehicle communication unit, The control unit, Of the multiple frames acquired, the in-vehicle communication unit that will be relaying to the same frame identifies two frames. A combined frame is generated by integrating the two identified frames. The generated integrated frame is output via the in-vehicle communication unit, which acts as the relay destination. Vehicle-mounted relay device.
2. The frame is a standard format CAN frame or CANFD frame. The integrated frame is a CAN frame or CANFD frame in an extended format. The in-vehicle relay device according to claim 1.
3. The aforementioned integrated frame includes a base ID and an extended ID, The control unit, Of the two identified frames, the message ID of the frame with the higher priority is stored in the base ID. The message ID of a low-priority frame is stored in the extended ID. The in-vehicle relay device according to claim 2.
4. The aforementioned frame is a CANFD frame in standard format. The aforementioned integrated frame is a CANFD frame in an extended format, When the control unit determines that the sum of the transmission data lengths of the two identified frames exceeds 8 bytes, If the value obtained by subtracting the sum of the transmission data lengths of the two identified frames from the data length of the data field defined in the integrated frame is less than a predetermined threshold, then the integrated frame is generated by integrating the two identified frames. If the value obtained by subtracting the sum of the transmission data lengths of the two identified frames from the data length of the data field defined in the integrated frame is greater than or equal to the threshold, the two identified frames will be output via the in-vehicle communication unit that will act as the relay destination without being integrated. The in-vehicle relay device according to claim 1.
5. The storage area accessible by the control unit stores integration necessity information, which determines whether integration is necessary or not according to the combination of transmission data lengths of the two identified frames and the threshold. The control unit refers to the integration necessity information and determines whether or not the two identified frames need to be integrated. The in-vehicle relay device according to claim 4.
6. The storage area accessible by the control unit includes a buffer area for temporarily storing the frames acquired via the in-vehicle communication unit. The control unit identifies two frames from among the multiple frames stored in the buffer area within a predetermined processing unit period that are relayed to the same in-vehicle communication unit. An in-vehicle relay device according to any one of claims 1 to 5.
7. The system includes a computer that is connected to an in-vehicle network installed in the vehicle and has multiple in-vehicle communication units that acquire frames transmitted and received between multiple in-vehicle ECUs connected to the in-vehicle network, and performs relay processing on the frames acquired via the in-vehicle communication units, Of the multiple frames acquired, the in-vehicle communication unit that will be relaying to the same frame identifies two frames. A combined frame is generated by integrating the two identified frames. The generated integrated frame is output via the in-vehicle communication unit, which acts as the relay destination. A program that executes a process.
8. The system includes a computer that is connected to an in-vehicle network installed in the vehicle and has multiple in-vehicle communication units that acquire frames transmitted and received between multiple in-vehicle ECUs connected to the in-vehicle network, and performs relay processing on the frames acquired via the in-vehicle communication units, Of the multiple frames acquired, the in-vehicle communication unit that will be relaying to the same frame identifies two frames. A combined frame is generated by integrating the two identified frames. The generated integrated frame is output via the in-vehicle communication unit, which acts as the relay destination. An information processing method that executes a process.
Citation Information
Patent Citations
Relaying apparatus and method and program for relaying
JP2017097851A