In-vehicle communication device
The in-vehicle communication device facilitates real-time data transfer protocol conversion and frame transmission, addressing the inefficiency of stopping vehicles for software updates by enabling continuous data transfer and security during motion.
Patent Information
- Application Number
- JP2024526243
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2022-06-09
- Filing Date
- 2023-03-10
- Publication Date
- 2025-11-06
- Estimated Expiration
- 2043-03-10
AI Technical Summary
Existing vehicle communication systems cannot change data transfer rules in real time while the vehicle is in motion, requiring vehicle stops for software updates, which affects vehicle control and is inefficient.
An in-vehicle communication device that converts data frames between different communication protocols and includes a transceiver unit to transmit frames in response to real-time transfer requests, allowing data transfer without stopping the vehicle.
Enables real-time data transfer changes while the vehicle is moving, ensuring vehicle control continuity and preventing unauthorized data modifications.
Smart Images

Figure 0007765630000001 
Figure 0007765630000002 
Figure 0007765630000003
Abstract
Description
[Technical Field]
[0001] The present invention relates to a communication device mounted on a vehicle, and more particularly to an in-vehicle communication device that controls data transfer between different communication paths. [Background technology]
[0002] In recent years, with the advancement of vehicle connectivity, there has been an increase in cases where vehicles communicate with external servers, such as by collecting and managing vehicle information on external servers. In this case, data from ECUs connected to a communication bus separate from the communication bus to which a telematics control unit (TCU) or other device is connected is transferred to the bus to which the TCU is connected via a communication device, such as a gateway, that relays the communication. The transfer rules, which determine which data is transferred to the TCU's bus and are referenced during the transfer, are operated according to a transfer table recorded on a storage medium within the vehicle during vehicle production. Therefore, if there is a change in the data to be collected, the transfer table must be rewritten. This data can be rewritten by taking the vehicle to a dealer or other facility for a software update. Recently, remote software update techniques (OTA: Over-the-Air) have also been used, as described in Patent Document 1. [Prior art documents] [Patent documents]
[0003] [Patent Document 1] Patent Publication No. 2021-128362 Summary of the Invention [Problem to be solved by the invention]
[0004] In Patent Document 1, the condition for starting a software update is "when the ignition is off," and vehicle software updates are generally performed while the vehicle is stopped so as not to affect vehicle control while the vehicle is in motion. For this reason, it is not possible to change the data collected by the server in real time depending on the vehicle condition or driving situation while the vehicle is in motion.
[0005] The present invention has been made in consideration of the above-mentioned problems, and aims to provide an in-vehicle communication device that enables data transfer without stopping the vehicle when an instruction to change transfer data is received from a server while the vehicle is traveling. [Means for solving the problem]
[0006] In order to solve the above problem, an in-vehicle communication device according to one embodiment of the present invention is an in-vehicle communication device connected to a first network that communicates using first frames generated according to a first communication protocol and a second network that communicates using second frames generated according to a second communication protocol, and is equipped with a transceiver unit that transmits and receives the first frames and the second frames, and when the transceiver unit receives a transfer request for multiple first frames from the second network, it transmits a second frame that stores the multiple first frames to the second network in response to the transfer request. [Effects of the Invention]
[0007] According to the present invention, when an instruction to change transfer data is received from a server while the vehicle is running, data transfer becomes possible without stopping the vehicle. Problems, configurations, and effects other than those described above will become apparent from the following description of the embodiments. [Brief explanation of the drawings]
[0008] [Figure 1] FIG. 1 is a block diagram showing a configuration of an in-vehicle communication device according to a first embodiment. [Figure 2] FIG. 10 is a diagram showing an example of a forwarding table before a change instruction frame is received. [Figure 3]FIG. 10 is a diagram showing an example of a forwarding table after receiving a change instruction frame and updating it. [Figure 4] FIG. 10 is a diagram showing an example of the configuration of a modification instruction frame. [Figure 5] FIG. 10 is a diagram showing an example of the configuration of a transfer frame when a plurality of communication frames are packed. [Figure 6] 4 is a flowchart showing a process executed by the in-vehicle communication device according to the first embodiment. [Figure 7] 4 is a flowchart showing a process executed by the T-ECU. [Figure 8] FIG. 10 is a block diagram showing the configuration of an in-vehicle communication device according to a second embodiment. [Figure 9] 10 is a flowchart showing a process executed by an in-vehicle communication device according to a second embodiment. DETAILED DESCRIPTION OF THE INVENTION
[0009] Hereinafter, an embodiment will be described with reference to the drawings.
[0010] [Example 1] 1 is a functional block diagram showing the configuration of an in-vehicle communication device 100 (hereinafter simply referred to as communication device 100) according to a first embodiment of the present invention. The communication device 100 is made up of a well-known microcomputer equipped with a memory and a CPU, and includes transmission / reception units 10a to 10c, a transfer control unit 20, and a transfer table 30.
[0011] The communication device 100 is connected to an in-vehicle device T-ECU (Telematics-Electrical Control Unit) 200 via a communication path 400a. The communication device 100 is also connected to ECUs 300a, 300b, and 300c via communication paths 400b and 400c. The communication device 100 controls the transfer of data received from each ECU.
[0012] The communication paths 400b and 400c are communication paths using a first communication protocol used by the ECUs 300a, 300b, and 300c, while the communication path 400a is a communication path using a second communication protocol used by the T-ECU 200, which has a faster transmission speed than the first communication protocol. The communication device 100 internally performs protocol conversion for transfers between these two communication protocols, changing the communication frame before transferring data. Note that the number of ECUs and communication paths is not limited to the number shown in the figure and can be adjusted as desired. The communication device 100 may have the function of not only passively receiving data from each ECU, but also actively communicating with each ECU. Furthermore, the first and second communication protocols are not necessarily limited to different types of communication protocols; the communication paths 400a, 400b, and 400c may use the same communication protocol.
[0013] The T-ECU 200 is connected to an external server and has a function of issuing an instruction to the communication device 100 to change the content of data transfer being performed from the communication device 100 to the T-ECU 200. The T-ECU 200 may send a change instruction in response to an external operation like a TCU or a navigation system, or may send a change instruction spontaneously depending on the situation.
[0014] Here, in this embodiment, T-ECU 200 is a device that realizes functions that are not directly related to the internal control of the vehicle in which communication device 100 is installed, and ECUs 300a, 300b, and 300c are devices that realize functions that are directly related to the internal control of the vehicle.
[0015] The transceivers 10a to 10c are well-known communication modules that have the function of transmitting and receiving data to and from each ECU via each communication path. For convenience of explanation, in Fig. 1, each transceiver 10a to 10c corresponds to one communication path, but each transceiver may correspond to multiple communication paths.
[0016] The forwarding table 30 is a storage medium that records the transfer rules for data received by the communication device 100 from the T-ECU 200 and ECUs 300a, 300b, and 300c via each communication path. In other words, the forwarding table is stored in, for example, a non-volatile storage medium of the communication device 100. The forwarding table is divided into vehicle rules 32 that indicate the transfer rules for data required for vehicle control internally and external rules 34 that indicate the transfer rules for data not related to vehicle control that is transferred to the T-ECU 200. The forwarding table 30 may be a simple table that lists identification symbols associated with signals (hereinafter, communication frames) such as IDs and the transfer destinations of each signal, or it may contain rules for packing multiple communication frames into one communication frame. This division of rules is merely a pseudo-separation to limit the modules that can be accessed by address, and the table may actually exist in a contiguous address space in memory.
[0017] The forwarding control unit 20 includes a vehicle forwarding determination unit 22, an outside-vehicle forwarding determination unit 24, and a forwarding frame generation unit 26, and controls the forwarding function of the communication device 100. The vehicle forwarding determination unit 22 is configured to be able to access only the vehicle rules 32, and the outside-vehicle forwarding determination unit 24 and the forwarding frame generation unit 26 are configured to be able to access only the outside-vehicle rules 34.
[0018] The vehicle transfer determination unit 22 refers to the vehicle rules 32 and determines whether or not it is necessary and / or possible to transfer the data received from the communication paths 400a, 400b, and 400c to the communication paths 400b and 400c. That is, it determines whether or not to transfer the data to the ECUs 300a, 300b, and 300c that have a function that directly affects the internal control of the vehicle.
[0019] On the other hand, the exterior transfer determination unit 24 refers to the exterior rule 34 and determines whether or not it is necessary and / or possible to transfer data received from the communication paths 400b and 400c to the communication path 400a. In other words, it determines whether or not to transfer data to the T-ECU 200, which has a function that does not directly affect the internal control of the vehicle. Furthermore, when the exterior transfer determination unit 24 receives from the T-ECU 200 a frame instructing the change of the contents of the transfer to the T-ECU 200, it updates the exterior rule 34 in accordance with the contents of the change instruction frame. Note that if the ID for which transfer is requested is not a periodic transmission frame, the exterior transfer determination unit 24 requests transmission from the ECU that transmits the first communication frame for the ID. This is for the following reason.
[0020] For example, data such as engine torque and values of various sensors are transferred periodically (e.g., every 10 ms or 100 ms) from each ECU. Therefore, data can be automatically received without an instruction to send data from the communication device 100 side. However, in the case of an ECU that does not transmit data periodically in this way, it will not transmit data unless an instruction to do so is given from the communication device 100 side, and the data necessary for transfer cannot be obtained. Examples of ECUs that do not transmit data periodically include ECUs related to diagnosis and ECUs related to vehicle control that do not need to always transmit the latest data.
[0021] The transfer frame generation unit 26 references the exterior rules 34 and generates a transfer frame to be transmitted to the communication path 400a. At this time, if the first communication protocol and the second communication protocol are different protocols, the transfer frame generation unit 26 converts the first communication frame conforming to the first communication protocol into a second communication frame conforming to the second communication protocol. Furthermore, if the exterior rules 34 include a packing rule, the transfer frame is generated by aggregating multiple first communication frames to be transferred into one second communication frame, and is transmitted to the communication path 400a. The transfer frame may be transferred periodically or aperiodically.
[0022] As described above, the outside-vehicle rule 34 is subject to two processes: an update process performed by the outside-vehicle transfer determination unit 24 when a change instruction is received, and a reference process performed by the transfer frame generation unit 26 when generating a transfer frame. However, if these update and reference processes are attempted simultaneously, data write and read operations will be attempted simultaneously, which may cause a malfunction in the operation of the communication device 100. Therefore, the transfer control unit 20 performs exclusive control over these two operations to prevent the update operation of the outside-vehicle transfer determination unit 24 for the outside-vehicle rule 34 and the reference operation of the transfer frame generation unit 26 from occurring simultaneously, causing a malfunction. Note that if these operations are attempted simultaneously, the update operation by the outside-vehicle transfer determination unit 24 takes priority.
[0023] As described above, the operation of the transfer control unit 20 does not change the vehicle rules used for vehicle control data transfer, but changes only the transfer rules to the outside of the vehicle, which do not directly affect vehicle control, making it possible to respond in real time to transfer change instructions from outside the vehicle. However, because vehicle information is rewritten upon receiving instruction frames from outside the vehicle, there is a possibility that a malicious third party may be allowed to make malicious changes to the vehicle information. For this reason, the transfer control unit 20 may use a memory protection function (MPU: Memory Protection Unit) equipped with a well-known microcomputer OS to perform memory access control so that the vehicle rules 32 cannot be accessed by change instruction frames from outside the vehicle. In addition, the communication frame itself may be digitally signed or encrypted to prevent change instructions from being accepted from any party other than a trusted communication partner.
[0024] FIG. 2 is a diagram illustrating an example of the forwarding table 30 in an initialized state, i.e., before receiving a change instruction frame. In the following description, it is assumed that CAN (Controller Area Network) is selected as the first communication protocol and CAN FD (CAN with Flexible Data Rate), which handles frames containing data portions larger than those handled by CAN, is selected as the second communication protocol. The forwarding table 30 indicates whether or not the ID (reception ID) of the received frame is forwarded to each channel (CH) when the communication device 100 receives the communication frame. Regarding the forwarding destinations shown in FIG. 2, CH1, CH2, and CH3 are communication paths to which vehicle rules apply, i.e., used for transmitting and receiving data that directly affect vehicle control, such as communication paths 400b and 400c in FIG. 1. The bus for the forwarding destination T-ECU is a communication path connected to a device connected to an external server (T-ECU 200 in FIG. 1) and transmits and receives data that does not directly affect vehicle control.
[0025] 2, the section describing the transfer rules to buses other than the T-ECU bus is referred to as vehicle rule 32, and the section describing the transfer rules to the T-ECU bus is referred to as exterior rule 34. The packing rules of exterior rule 34 describe which frame of which ID to pack and transfer when the received ID can be transferred to the T-ECU bus and multiple frames can be packed in one frame. As described above, vehicle rule 32 is referenced only by vehicle transfer determination unit 22, and is not updated by exterior transfer determination unit 24 in response to a transfer change instruction.
[0026] 2, a communication frame assigned a reception ID of 0x200 cannot be transferred to the T-ECU bus, and if it is to be packed, it is to be packed in a frame with ID of 0x222. Furthermore, communication frames assigned reception IDs of 0x100 and 0x300 can be transferred to the T-ECU bus, and are to be packed in frames with IDs of 0x111 and 0x222, respectively. In this case, when a change instruction frame stating "Make communication frames with reception ID of 0x200 transferable to the T-ECU bus and pack them in 0x111. Stop transferring communication frames with reception ID of 0x300" is received from T-ECU 200, exterior transfer determination unit 24 updates exterior rule 34 as shown in FIG.
[0027] 3 is a diagram showing an example of the forwarding table 30 that has been updated when the communication device 100 receives a change instruction frame. Changes have been made in accordance with the instructions in the change instruction frame, and the outside-vehicle forwarding determination unit 24 and the forwarding frame generation unit 26 will thereafter execute processing in accordance with this table.
[0028] Fig. 4 is a diagram showing an example of a change instruction frame. The change instruction frame has a data structure conforming to CAN FD, and its main fields are an arbitration field used to identify the data content and the sending node, and a data field in which the actual data is stored. The data field of the change instruction frame contains the number of transfer rules to be changed (n in Fig. 4), and linked data D consisting of a start / stop flag, a change target ID, and a packing destination ID for each change. k Includes:
[0029] The start / stop flag indicates an instruction to start or stop transfer for the change target ID, which will be described later. Specifically, it has an identification flag where, for example, a bit is set to 1 for a start instruction and a bit is set to 0 for a stop instruction. The change target ID specifies which ID of the first communication frame the transfer rule of which frame is to be changed. The packing ID specifies which ID of the second communication frame the frame of the change target ID is to be packed into and transferred. Note that the change target ID and packing ID may use the IDs actually used in communication as they are, or may use a different identifier corresponding to the actual ID that is predetermined between the instruction side, such as a server, and the communication device 100.
[0030] 5 is a diagram showing an example of the configuration of a transfer frame when packing a plurality of first communication frames. The following describes a packing method when a rule for packing a plurality of first communication frames into one second communication frame is set as the outside-vehicle rule 34.
[0031] First, the ID, data size, and data content of each frame are linked from among the first communication frames having the ID specified by the change instruction frame shown in Fig. 4. The IDs are acquired so that the receiving side (here, T-ECU 200 or a server) can understand which frames are being accumulated and the data size so that the receiving side can understand how much data is in each frame.
[0032] The ID used in the first communication frame may be used as is, or a different identifier may be prepared in advance and assigned so that the receiving side can understand which ID it is. After all the data in the first communication frames to be packed is concatenated, the number of frames to be concatenated is assigned to the concatenated data (m in Figure 5). The concatenated data from these multiple first communication frames is stored in the data field of the second communication frame to generate a transfer frame. Note that in Figure 5, the second communication frame has an arbitration field and a data field, but this is because CAN FD is assumed as an example of the second protocol that the second communication frame complies with. If another protocol such as Ethernet (registered trademark) is used, the terms MAC address, payload, etc. should be replaced with the corresponding concepts.
[0033] FIG. 6 is a flowchart of the process executed by the in-vehicle communication device 100 according to the first embodiment.
[0034] First, in step 100, the transmitter / receiver 10a receives a change instruction frame from the T-ECU 200. In step 102, the exterior transfer determination unit 24 checks whether the ID instructed to be changed exists in the transfer table 30. If the ID exists in the transfer table 30, the process proceeds to step 104. If the ID does not exist in the transfer table 30, the process proceeds to step 120.
[0035] In step 104, the outside-vehicle transfer determination unit 24 checks whether the transfer frame generation unit 26 is currently referring to the outside-vehicle rules 34. If not currently referring, the process proceeds to step 106, and if currently referring, the process waits until the reference is completed.
[0036] In step 106, the outside-vehicle transfer determination unit 24 checks whether the change instruction is a transfer start instruction or a transfer stop instruction. If it is a transfer start instruction, the process proceeds to step 108, and if it is a transfer stop instruction, the process proceeds to step 110.
[0037] In step 108, the outside-vehicle transfer determination unit 24 sets the outside-vehicle rule 34 for the corresponding ID to transferable. In step 110, the outside-vehicle rule 34 for the corresponding ID to transfer unacceptable.
[0038] In step 112, the outside-vehicle transfer determination unit 24 checks whether the corresponding ID is a periodic transmission frame that is periodically transmitted. If it is a periodic transmission frame, the process proceeds to step 116; if it is not a periodic transmission frame, the process proceeds to step 114.
[0039] In step 114, the exterior transfer determination unit 24 transmits a frame transmission request for the corresponding ID to the ECU that transmitted the corresponding ID. The reason for this is as described above. In step 116, the exterior transfer determination unit 24 checks whether there is an instruction to change the packing rule. If there is an instruction to change the packing rule, the process proceeds to step 118; if there is no instruction to change the packing rule, the process proceeds to step 120.
[0040] In step 118, the off-vehicle transfer determination unit 24 changes the packing rule for the corresponding ID. In step 120, the off-vehicle transfer determination unit 24 checks whether all change instructions in the change instruction frame have been implemented. If they have been implemented, the process proceeds to step 122. If there are any IDs that have not yet been changed, the process proceeds to step 102.
[0041] In step 122, the transfer frame generation unit 26 refers to the exterior rule 34 updated by the exterior transfer determination unit 24, and stores the corresponding first communication frame in a second communication frame (transfer frame). Finally, in step 124, the transfer frame generation unit 26 starts transmitting the generated transfer frame. At this time, the transfer frame generation unit 26 can also generate the first communication frame received within a predetermined time as a transfer frame.
[0042] FIG. 7 is a flowchart showing the processing that T-ECU 200 performs in parallel with the processing by communication device 100 described with reference to FIG.
[0043] First, in step 200, the transfer request unit 50 of the T-ECU 200 transmits a transfer request including a change instruction frame shown in Fig. 4 to the communication device 100. This change instruction frame may be received from a server connected via a network, for example, or may be manually input using a tool.
[0044] In response to the transmission of the transfer request in step 200, the communication device 100 performs the process described with reference to Fig. 6 and generates a transfer frame. In step 202, the transceiver 40 of the T-ECU 200 receives the transfer frame from the communication device 100.
[0045] In step 204, the frame processing unit 60 of the T-ECU 200 processes the received transfer frame. This is done, for example, by restoring the multiple first communication frames included in the data field of the transfer frame using a known method. The frame processing unit 60 can also generate a new second communication frame that stores the data of the multiple first communication frames received from an external server or the like, and retransmit the second communication frame to the communication device 100.
[0046] As described above, in this embodiment, data transfer is carried out while updating the outside-vehicle rules in real time based on the outside-vehicle rules that stipulate transfers that do not directly affect in-vehicle control, making it possible to send and receive appropriate data even while the vehicle is moving.
[0047] [Example 2] Next, an in-vehicle communication device 100 according to a second embodiment will be described. The communication device 100 according to the second embodiment is configured by adding a RAM 70, which is a volatile storage medium, and a vehicle state determination unit 80 to the configuration of the communication device 100 according to the first embodiment. Note that only configurations and operations that are different from those of the first embodiment will be described below, and descriptions of the same configurations and operations will be omitted.
[0048] 8 is a functional block diagram showing the configuration of an in-vehicle communication device 100 according to a second embodiment. The communication device 100 according to the second embodiment further includes the RAM 70 and the vehicle state determination unit 80 as described above. As the RAM 70, any known memory such as a dynamic random access memory (DRAM) or a static random access memory (SRAM) can be used. The vehicle state determination unit 80 is realized by the CPU in the communication device 100, similar to the other functional units.
[0049] The vehicle state determination unit 80 monitors whether the vehicle system is in a system stopped state or a system activated state. In this embodiment, the vehicle system stopped state refers to when the ignition is OFF, the vehicle engine speed is 0, or the communication device 100 has not received any communication for a certain period of time or more. Any one or all of these may be used as the conditions for determining the vehicle system state. Furthermore, the vehicle system activated state refers to when the ignition is ON, the vehicle engine speed is not 0, or the communication device 100 has received any communication.
[0050] When the vehicle state determination unit 80 determines that the vehicle system is in an activated state, the transfer table 30 loads the vehicle rule 32 and the outside-vehicle rule 34 into the RAM 70. The vehicle rule and the outside-vehicle rule loaded into the RAM 70 are respectively referred to as the vehicle rule 32' and the outside-vehicle rule 34'. The vehicle transfer determination unit 22 refers to the vehicle rule 32', and the outside-vehicle transfer determination unit 24 and the transfer frame generation unit 26 refer to and update the outside-vehicle rule 34'.
[0051] When the vehicle state determination unit 80 determines that the vehicle system is in a stopped state, if there is a difference between the outside-vehicle rules 34' in the RAM 70 and the outside-vehicle rules 34 in the transfer table, the outside-vehicle transfer determination unit 24 may partially update the outside-vehicle rules 34 to reflect the outside-vehicle rules 34'. The presence or absence of an update operation may be uniquely determined at the design stage, or information on the necessity of an update may be added to the change instruction frame from the server to make the presence or absence of an update operation variable.
[0052] Fig. 9 is a flowchart showing a process performed by the in-vehicle communication device 100 according to the second embodiment. In Fig. 9, the same processes as those performed in the first embodiment and described in Fig. 6 are denoted by the same reference numerals, and the description thereof will be omitted.
[0053] In step 300, when the vehicle state determination unit 80 determines that the vehicle system is in an activated state, the processing sequence begins.
[0054] In step 302, the vehicle rules 32 and the outside-vehicle rules 34 are loaded from the transfer table 30 into the RAM 70. This process may be performed, for example, at the same time that the vehicle state determination unit 80 determines that the vehicle system is in an activated state. Next, in step 304, it is confirmed whether the transceiver unit 10a has received a change instruction frame from the T-ECU 200. Thereafter, the same processes as in the first embodiment are performed up to step 124, where the transfer frame is transmitted.
[0055] After step 124, the vehicle state determination unit 80 checks whether the vehicle system is in a stopped state in step 306. If the vehicle system is in a stopped state, the process proceeds to step 308, and if the vehicle system is in an activated state, the process proceeds to step 304.
[0056] In step 308, the outside-vehicle rule 34' in the RAM 70 is compared with the outside-vehicle rule 34 in the transfer table 30, and if there is a difference between the two, the outside-vehicle transfer determination unit 24 determines whether or not it is necessary to update the outside-vehicle rule 34 in the transfer table 30. This determination can be made, for example, based on whether or not the changed rule is one that handles data temporarily. If it is necessary to update the outside-vehicle rule 34, the process proceeds to step 310; if it is not necessary to update it, the process proceeds to step 312.
[0057] In step 310, the outside-vehicle transfer determination unit 24 applies the changes in the outside-vehicle rule 34' to the outside-vehicle rule 34 of the transfer table to perform a partial update. In step 312, the outside-vehicle transfer determination unit 24 does not update the outside-vehicle rule 34 in the transfer table 30, and deletes the changes in the outside-vehicle rule 34' in the RAM 70.
[0058] According to this embodiment, since a transfer table temporarily expanded in RAM 70, which is a volatile storage medium, is used, it is possible to change the transfer table only during one driving session, and easily return it to the original transfer table after the driving session ends. Furthermore, when the outside-vehicle rules are changed, it is possible to select whether to apply the change to the original outside-vehicle rules 34 or to erase the change after the vehicle system is stopped. For example, even if the change to the outside-vehicle rules 34' in RAM 70 poses a safety problem, it is possible to easily roll back to the original safe state by applying the original outside-vehicle rules 34.
[0059] According to the embodiment of the present invention described above, the following advantageous effects are achieved. (1) An in-vehicle communication device according to one embodiment of the present invention is an in-vehicle communication device connected to a first network that communicates using first frames generated according to a first communication protocol and a second network that communicates using second frames generated according to a second communication protocol, and includes a transceiver unit that transmits and receives the first frames and the second frames, and when the transceiver unit receives a transfer request for multiple first frames from the second network, it transmits a second frame containing the multiple first frames to the second network in response to the transfer request.
[0060] With the above configuration, when an instruction to change transfer data is received from the server while the vehicle is running, data can be transferred without stopping the vehicle.
[0061] (2) A transfer frame generator is provided that stores a plurality of first frames in a second frame to generate a transfer frame, thereby making it possible to preferably realize the present invention.
[0062] (3) The transfer frame generator generates a transfer frame that stores multiple first frames received within a predetermined time. This allows a specific frame to be transferred periodically, for example, by defining a specific frame period as a predetermined time, which is advantageous in terms of data management.
[0063] (4) The system further includes a forwarding table storage unit that stores a forwarding table that describes forwarding rules for first and second frames, and a forwarding determination unit that, when a forwarding request for multiple first frames is received from the second network, determines whether to forward the requested first frames and controls the forwarding table, and the forwarding frame generation unit references the forwarding table and generates a forwarding frame that stores multiple first frames that the forwarding determination unit has determined to be forwardable. This eliminates the risk of causing some kind of problem by forwarding frames that should not be forwarded, by defining in advance criteria for determining that a frame is forwardable.
[0064] (5) The transfer determination unit allows the transfer of the first frame when the requested first frame does not include data related to the internal control of the vehicle in which the in-vehicle communication device is installed, thereby eliminating the risk of transferring data related to the internal control of the vehicle and causing problems with the vehicle's functions.
[0065] (6) If the first frame requested in the transfer request is not a frame that is periodically transmitted, the transfer determination unit requests the communication device that transmitted the requested first frame to transmit the requested first frame. This prevents data from being missed even for ECUs that do not transmit data voluntarily, such as ECUs related to diagnostics.
[0066] (7) The control of the forwarding table by the forwarding determination unit and the reference of the table by the forwarding frame generation unit are controlled exclusively, which prevents malfunctions caused by overlapping accesses to the forwarding table.
[0067] (8) The second frame in the second communication protocol includes a data portion larger than the data portion of the first frame, which makes it possible to store multiple first frames in the second frame.
[0068] (9) The forwarding table storage unit further includes a volatile storage medium capable of expanding the contents of the forwarding table stored therein, and the forwarding frame generation unit and forwarding determination unit can refer to the forwarding table expanded in the volatile storage medium. This makes it possible to change the forwarding table, for example, only during one trip, and easily return it to the original forwarding table after the trip has ended.
[0069] (10) The in-vehicle communication device further includes a vehicle state determination unit that determines the current operating state of the vehicle in which the in-vehicle communication device is installed, and when the vehicle is in a stopped state and the transfer table stored in the volatile storage medium is changed, the vehicle state determination unit reflects the change in the transfer table stored in the transfer table storage unit. This makes it possible to easily roll back to the original safe state by applying the original outside rules, for example, even if a change to the outside rules in RAM poses a safety problem.
[0070] (11) Another embodiment of the present invention provides an in-vehicle network system including an in-vehicle communication device and a second communication device connected to the in-vehicle communication device via a second network, the second communication device including a second frame transceiver, a transfer requester that transmits a transfer request to the in-vehicle communication device to store a plurality of first frames in the second frame and transfer the stored first frames, and a frame processor that extracts information of the plurality of stored first frames from the second frame that stores the plurality of first frames. This makes the in-vehicle communication device according to the present invention suitable for use in such an in-vehicle network system.
[0071] (12) The frame processing unit generates a second frame that stores the first frames to be transmitted to the first network through the in-vehicle communication device. This makes it possible to transmit the first frames received from an external server or the like to the in-vehicle communication device in a single communication.
[0072] The present invention is not limited to the above-described embodiments and includes various modifications. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to those including all of the described configurations. Furthermore, part of the configuration of one embodiment can be replaced with part of the configuration of another embodiment, or part of the configuration of another embodiment can be added to the configuration of one embodiment. Furthermore, part of the configuration of each embodiment can be used, deleted, or replaced with another configuration. Furthermore, the above-described configurations, functions, processing units, processing means, etc. may be implemented in hardware, in part or in whole, by designing them as integrated circuits, for example. Furthermore, the above-described configurations, functions, etc. may be implemented by software in which a processor realizes each function. Information such as programs, tables, and files that realize each function can be stored in recording devices such as memory, hard disks, and solid-state drives (SSDs), or in recording media such as IC cards, SD cards, and DVDs, or various recording media installed in microcomputers. [Explanation of symbols]
[0073] 10a to 10c, 40...Transmitter / receiver unit 22...Vehicle transfer determination unit 24...External transfer determination unit 26...Transfer frame generation unit 30...Transfer table 50...Transfer request unit 60...Frame processing unit 70...RAM (volatile storage medium) 80...Vehicle state determination unit 100...In-vehicle communication device 200...T-ECU (second communication device)
Claims
1. An in-vehicle communication device connected to a first network that communicates using a first frame generated in accordance with a first communication protocol and a second network that communicates using a second frame generated in accordance with a second communication protocol, a transmitting / receiving unit that transmits and receives the first frame and the second frame; a transfer frame generation unit that stores a plurality of the first frames in the second frame to generate a transfer frame; a forwarding table storage unit in which a forwarding table describing forwarding rules for the first frame and the second frame is stored; a determination process for determining whether to transfer the first frames when a transfer request for the plurality of first frames is received from the second network; and a transfer determination unit for updating the transfer rules of the transfer table in accordance with the contents of a change instruction for the second network that controls the transfer table when a change instruction for the transfer contents is received from the second network. Equipped with the transfer frame generation unit, when the transfer determination unit determines to perform transfer, references the transfer table and generates the transfer frame to be transmitted from the first network to the second network; the transmitting / receiving unit transmits the transfer frame to the second network in response to the transfer request; The update process of the forwarding table by the forwarding determination unit and the reference process of the forwarding table by the forwarding frame generation unit are controlled exclusively, and when the update process and the reference process are to be performed simultaneously, the update process takes priority. An in-vehicle communication device comprising:
2. The in-vehicle communication device according to claim 1, the transfer frame generation unit generates the transfer frame storing the plurality of first frames received within a predetermined time period; An in-vehicle communication device comprising:
3. The in-vehicle communication device according to claim 1, the transfer determination unit permits the transfer of the first frame when the first frame for which the transfer request has been made does not include data related to internal control of a vehicle in which the in-vehicle communication device is installed. An in-vehicle communication device comprising:
4. The in-vehicle communication device according to claim 1, When the first frame requested in the transfer request is not a frame that is periodically transmitted, the transfer determination unit requests a communication device that is a source of the requested first frame to transmit the requested first frame. An in-vehicle communication device comprising:
5. The in-vehicle communication device according to claim 1, the second frame in the second communication protocol includes a data portion larger than the data portion of the first frame; An in-vehicle communication device comprising:
6. The in-vehicle communication device according to claim 1, a volatile storage medium capable of expanding the contents of the forwarding table stored in the forwarding table storage unit; the transfer frame generation unit and the transfer determination unit can refer to the transfer table expanded in the volatile storage medium; An in-vehicle communication device comprising:
7. 7. The in-vehicle communication device according to claim 6, a vehicle state determination unit that determines a current operating state of a vehicle in which the in-vehicle communication device is installed; when the vehicle is in an operation-stopped state and the transfer table expanded in the volatile storage medium is changed, the vehicle state determination unit reflects the change in the transfer table stored in the transfer table storage unit; An in-vehicle communication device comprising:
8. 10. An in-vehicle network system including the in-vehicle communication device according to claim 1 and a second communication device connected to the in-vehicle communication device via the second network, The second communication device includes a transceiver for the second frame; a transfer request unit that transmits a transfer request to the in-vehicle communication device to store the plurality of first frames in the second frame and transfer the second frame; a frame processing unit that extracts information of the stored first frames from the second frame in which the first frames are stored, An in-vehicle network system comprising:
9. 9. The in-vehicle network system according to claim 8, the frame processing unit generates a second frame storing a plurality of first frames to be transmitted to the first network through the in-vehicle communication device; An in-vehicle network system comprising:
Citation Information
Patent Citations
Software update apparatus and software update method
JP2021128362A
Vehicle-mounted gateway device, electronic control device, and vehicle-mounted network system
WO2017090351A1
Statistic information generation device, statistic information generation method, and program
WO2020137304A1