Communication devices and in-vehicle electronic devices

Abstract

To provide a communication device capable of improving the communication efficiency of an on-vehicle network.SOLUTION: A communication device includes: a classification unit that classifies frames received by a receiving unit into two or more classes; a queuing unit that buffers the frames for each class; a gate unit that opens / closes the queued frames; a scheduling unit that determines the open / closed state of the gate unit and secures data transmission timing for other classes by setting a guard band that is a transmission prohibited time near the end time of the gate open state of each class; and a transmitting unit that transmits frames passed by the gate unit. The classification unit classifies the frames based on determination of the classes of the frames by a class table. The scheduling unit sets a guard band width corresponding to the maximum frame length for each class specified in the class table, and controls the open / closed state to ensure the guard band width determined for each class.SELECTED DRAWING: Figure 7

Description

[Technical Field]

[0001] The present invention relates to a communication device and an in-vehicle electronic device. [Background technology]

[0002] In-vehicle networks, which are networks inside automobiles, interconnect multiple sensors and actuators and enable communication between them. With the recent advances in technologies such as autonomous driving (AD) and advanced driver assistance systems (ADAS), advances in in-vehicle networks are also expected. One of these advances is the creation of zone architecture and the accompanying network sharing.

[0003] Previous in-vehicle networks were configured with separate networks for each communication target, known as domains, such as the powertrain / chassis system, vehicle body, AD / ADAS system, and information system. These networks were configured using incompatible communication methods, such as CAN (Controller Area Network), LIN (Local Interconnect Network), FlexRay (registered trademark), or Ethernet (registered trademark), depending on the purpose of each domain. However, this type of domain-specific network configuration not only complicates network management, but also places a burden on automotive design in terms of wiring weight and wiring costs.

[0004] The solution to this problem is zone architecture and network sharing. The zone architecture eliminates the traditional domain-specific networks and connects spatially close sensors and actuators to a single sub-network. Furthermore, by connecting the sub-networks via a common bus across domains, network sharing is achieved.

[0005] One of the challenges of network sharing is that the network must provide the communication quality required by the communication application. For example, powertrain and chassis communications require short latency from source to destination and a low data loss rate. On the other hand, AD / ADAS communications require large volumes of data, such as camera data. Furthermore, for information communications, both latency and data loss rates are acceptable to a certain extent.

[0006] One technology that can solve these issues is TSN (Time-Sensitive Network). TSN is an Ethernet-based technology that logically divides communications into multiple classes, synchronizes time within the network, and controls frame transmission based on that time. This makes it possible to achieve communications that meet the quality requirements of applications on a shared network.

[0007] TSN is a general term for technologies that consist of multiple standards, with IEEE (Institute of Electrical and Electronics Engineers) 802.1Qbv being a representative standard. This is a method in which a transmission time, called a time slot, is periodically set for each class, and frame transmission is strictly controlled within the set transmission time. The IEEE 802.1Qbv standard specifies a guard band to prevent frames of one class from interfering with the transmission of frames of other classes. The guard band is set at the end of the transmission time for each class, and during the guard band period, transmission of frames currently being transmitted is permitted, but the start of transmission of new frames is not permitted. This ensures that transmissions of a certain class are within the range of the time slot, preventing delays in the transmission of frames of other classes.

[0008] However, the introduction of TSN based on the IEEE802.1Qbv standard raises concerns about a decline in communication efficiency. The standard specifies that the size of the guard band must be set to the maximum frame length of frames transmitted in that class. In this case, even if a frame shorter than the maximum frame length is included in the class and fits within the guard band, its transmission is not permitted, resulting in a decline in communication efficiency.

[0009] Patent Document 1 discloses a technique for improving communication efficiency in a time division network. The technique described in Patent Document 1 comprises a time scheduler, a priority class unit, a non-priority class unit, and a scheduling information change unit. Here, the time scheduler has a priority gate state and a non-priority gate state. That is, in the priority gate state, signals queued in the priority class part are passed in the open state, and the passage of signals is blocked in the blocked state. On the other hand, in the non-priority gate state, signals queued in the non-priority class part are passed in the open state, and the passage of signals is blocked in the blocked state.

[0010] The time scheduler then performs processing to control the timing of state change of the priority gate based on the scheduling information. That is, the scheduling information change unit instructs the time scheduler to change the timing of state change indicated by the scheduling information in accordance with the priority class signal. [Prior art documents] [Patent documents]

[0011] [Patent Document 1] Japanese Patent Application Publication No. 2019-004379 Summary of the Invention [Problem to be solved by the invention]

[0012] The technology described in Patent Document 1 is effective when the number of frames in a priority class signal changes dynamically over time. On the other hand, in a control network such as an in-vehicle network, there are cases where the pattern of transmitted data changes little over time. In such cases, the technology described in Patent Document 1 cannot be expected to improve communication efficiency.

[0013] An object of the present invention is to provide a communication device and an in-vehicle electronic device that can improve communication efficiency when applied to an in-vehicle network. [Means for solving the problem]

[0014] In order to solve the above problems, for example, the configurations described in the claims are adopted. The present application includes a plurality of means for solving the above problems, and examples thereof include: A communication device that is mounted on a vehicle and communicates information related to vehicle driving or driving assistance and information unrelated to vehicle driving, a receiving unit that receives frames from inside or outside the vehicle; a classification unit that classifies the frames received by the receiving unit into a priority class in which the information contained in the frame is related to driving or driving assistance, and a non-priority class in which the information contained in the frame is not related to driving; a queuing unit that buffers frames for each class classified by the classifying unit; a gate unit that allows frames queued in the queuing unit to pass in a gate open state and blocks the frames from passing in a gate closed state; a scheduler that determines whether the gate is open or closed and sets a guard band that is a transmission prohibition time near the end time of the gate open state of a class, thereby ensuring data transmission timing for other classes; and a transmitting unit that transmits the frame that the gate unit has passed. Here, the classification unit: a frame data classification unit that classifies the frame data according to data conditions; a frame length classification unit that classifies frames according to their frame lengths; a class table that holds frame data conditions and frame length conditions as classification criteria in the frame data classification unit and the frame length classification unit, and class data assigned based on the data conditions and frame length conditions; a classification execution unit that classifies the frame based on the class determination of the frame according to the class table; The scheduler sets a guard band width corresponding to the maximum frame length for each class specified in the class table, The gate section controls the open / closed state to ensure the guard band width determined for each class. Furthermore, the schedule section a gate state table that controls the open / close state of the gate corresponding to each class at each periodic time; a guard band table that sets the guard band width for each class; Determine the open / closed state of the gate section based on the gate state table and the guard band table; The class table, gate state table, and guard band table can be rewritten as needed based on the characteristics of the communication traffic. The classification unit uses statistical information on frames that were not transmitted due to guard bands as characteristics of communication traffic, and further divides classes if there are frames that were not transmitted. [Effects of the Invention]

[0015] According to the present invention, even when a guard band is used, the transfer efficiency of the network is improved and the processing load of the communication device can be averaged. Problems, configurations, and effects other than those described above will become apparent from the following description of the embodiments. [Brief explanation of the drawings]

[0016] [Figure 1] 1 is a diagram showing a network configuration of a communication device according to a first embodiment of the present invention. [Figure 2] 1 is a diagram illustrating a hardware configuration of a communication device according to a first embodiment of the present invention. [Figure 3] 2 is a schematic diagram of a communication frame in a zone architecture according to a first example embodiment of the present invention; FIG. [Figure 4] FIG. 1 is a schematic diagram of a time slot setting (example 1) in IEEE802.1Qbv. [Figure 5] FIG. 10 is a schematic diagram of a time slot setting (example 2) in IEEE802.1Qbv. [Figure 6] FIG. 10 is a schematic diagram of a time slot setting (example 3) in IEEE802.1Qbv. [Figure 7] FIG. 2 is a schematic diagram of a time slot setting according to a first embodiment of the present invention. [Figure 8] 1 is a diagram showing a frame configuration (example 1) handled by a communication device according to a first embodiment of the present invention. [Figure 9] FIG. 10 is a diagram showing a frame configuration (example 2) handled by a communication device according to the first embodiment of the present invention. [Figure 10] 1 is a block diagram showing the configuration of a communication device according to a first embodiment of the present invention. [Figure 11] FIG. 3 is a diagram illustrating the configuration of a class table according to the first embodiment of the present invention. [Figure 12] FIG. 2 is a configuration diagram of a scheduling unit according to the first embodiment of the present invention. [Figure 13] 5 is a flowchart showing the processing of a classification unit according to the first embodiment of the present invention. [Figure 14] 4 is a flowchart for setting a guard band table according to a first exemplary embodiment of the present invention. [Figure 15] FIG. 10 is a diagram illustrating the configuration of a class table according to a second embodiment of the present invention. [Figure 16] 10 is a flowchart showing the processing of a frame data classification unit according to a second embodiment of the present invention. [Figure 17] 10 is a flowchart showing the processing of a frame length classification unit according to the second embodiment of the present invention. [Figure 18] 10 is a flowchart showing the processing of a classification execution unit according to a second embodiment of the present invention. [Figure 19] FIG. 10 is a configuration diagram of a communication device according to a third embodiment of the present invention. [Figure 20] 10 is a flowchart showing the processing of a monitoring unit according to a third embodiment of the present invention. [Figure 21]10 is a flowchart showing the processing of a setting management unit according to a third embodiment of the present invention. [Figure 22] 10 is a flowchart showing a setting change process in a class table according to a third embodiment of the present invention. [Figure 23] 10 is a flowchart showing a setting change process in a gate status table according to a third embodiment of the present invention. [Figure 24] 10 is a flowchart showing a setting change process in a guard band table according to a third embodiment of the present invention. [Figure 25] FIG. 10 is a configuration diagram showing an example of a setting preset table according to a fourth embodiment of the present invention. [Figure 26] 10 is a flowchart showing processing in a setting management unit according to a fourth embodiment of the present invention. [Figure 27] FIG. 10 is a diagram showing a network configuration of a communication device according to a fifth embodiment of the present invention. [Figure 28] FIG. 13 is a schematic diagram showing the flow of a setting update by OTA according to a fifth embodiment of the present invention. [Figure 29] FIG. 10 is a diagram illustrating the configuration of a communication device according to a fifth embodiment of the present invention. [Figure 30] 10 is a flowchart illustrating a setting update via OTA according to a fifth embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0017] <First embodiment> A first embodiment of the present invention will be described below with reference to FIGS. FIG. 1 shows a communication network connection within a vehicle equipped with a communication device according to this embodiment. FIG. 1 shows an example in which a zone architecture is adopted as a network within a vehicle 1. The network is made up of zone ECUs (Electronic Control Units) 2a to 2d, sensors 3a to 3d connected to the zone ECUs 2a to 2d, and actuators 4a to 4d connected to the zone ECUs 2a to 2d.

[0018] The numbers of zone ECUs 2a to 2d, sensors 3a to 3d, and actuators 4a to 4d shown in FIG. 1 are merely examples, and one or more of each may be provided. In the following description, the zone ECUs 2a to 2d, the sensors 3a to 3d, and the actuators 4a to 4d will be referred to as the zone ECU 2, the sensor 3, and the actuator 4, unless it is necessary to distinguish between them.

[0019] As the name suggests, the zone ECUs 2 are arranged in positions (zones) such as front, rear, left, and right in the vehicle, and are connected to sensors 3 and / or actuators 4 that are close to their installation positions. The zone ECUs 2 are connected to other zone ECUs 2 via a shared bus 5 that uses a common communication method. At least some of the sensors 3 and / or actuators 4 may be connected to the zone ECUs 2 via the shared bus 5. The communication device described in this embodiment is implemented in the zone ECU 2. In the following description, the zone ECU is referred to as the communication device.

[0020] FIG. 2 shows the hardware configuration of the communication device 2. The communication device 2 includes a network switch 6 for connecting to other communication devices 2 or for connecting to sensors 3 and actuators 4. The communication device 2 also includes a CPU (Central Processing Unit) 7 for processing information received from the sensors 3 and actuators 4 or the shared bus 5, and is connected to the network switch 6.

[0021] 2, the thick lines connecting the various components represent the shared bus 5 that communicates using a common communication method, which is a connection method between communication devices 2 in the zone architecture. Also, the thin lines connecting the various components in FIG. 2 represent communication using a communication method other than the zone architecture. If the sensor 3 and the actuator 4 are compatible with the common communication method, they are directly connected to the network switch 6. If the sensor 3 and the actuator 4 are not compatible with the common communication method, they can be connected to the CPU 7 and converted to the common communication method within the CPU 7.

[0022] The common communication method is assumed to be Ethernet (registered trademark), but other methods may be used as long as they provide the same functionality as TSN. The network switch 6 and the other CPUs 7 can be connected using Ethernet or other methods. Examples of communication methods that are not common communication methods include CAN, LIN, and FlexRay.

[0023] The communication device 2 receives data from the sensor 3 and the actuator 4. The communication device 2 also receives data generated by the CPU 7. This data is processed by the CPU 7 or transmitted to another communication device 2. The communication device 2 also receives data from another communication device 2 connected via the shared bus 5. The received data is processed by the CPU 7 as necessary and then transferred to the sensor 3 or the actuator 4.

[0024] In a zone architecture, one communication device 2 houses multiple sensors 3 and actuators 4 . For example, there are Power Train / Chassis (PT / CH) ECUs that are responsible for engine control and steering control. There are also Autonomous Driving / Advanced Driver Assistance System (AD / ADAS) ECUs that process information obtained from external sensors such as cameras and radar to enable autonomous driving and provide safe driving assistance to the driver. There are also BODY ECUs that control power windows and air conditioning, and INFO ECUs that distribute audio and video and access the Internet.

[0025] Figure 3 is a schematic diagram of communication frames on the shared bus 5 in the zone architecture. PT / CH system data 11, 14, 17, AD / ADAS system data 12a, 12b, 15a, 15b, and BODY system data 13, 16 are transmitted periodically. These data have different communication requirements, such as communication cycle, frame size, required delay time, and frame loss tolerance. Therefore, simply communicating over a shared network cannot satisfy these communication requirements, and in some cases, vehicle control may become unstable.

[0026] In such a communications environment, Time-Sensitive Networking (TSN) has been standardized as a method for separating multiple communications with different communication requirements, enabling communication control appropriate for each type of communication and improving safety. TSN is composed of multiple standards, but here we will assume communication control based on the IEEE802.1Qbv standard explained in the Background Technology section. IEEE802.1Qbv, also known as Time-Aware Shaper, is a method for separating communications by classifying communication frames into multiple classes and setting transmittable times, called time slots, for each class, thereby performing time-division communication.

[0027] An example of communication using IEEE802.1Qbv is shown in Figure 4. 4, communications are classified into priority and non-priority classes, and transmission times called time slots are defined for each classification. That is, time slots 18a to 18c are set for priority data, and time slots 19a and 19b are set for non-priority data. The designer can arbitrarily determine the priority / non-priority classification of communications, but here, PT / CH system data that has a large impact on vehicle control is classified as priority class data 11, 14, and 17, while the other AD / ADAS system data 12, 12b, 15a, and 15b, BODY system data 13 and 16, and INFO data (not shown) are classified as non-priority class data. In this embodiment, too, PT / CH system data that has a large impact on vehicle control is classified as priority class data, while the other AD / ADAS system data, BODY system data, and INFO data are classified as non-priority class data. This allows the priority of communications to be set appropriately.

[0028] In simple time-division communication such as that shown in FIG. 4, the non-priority class may affect the transmission time of the priority class. Figure 5 shows an example of this case. Let us assume that the transmission time of the AD / ADAS-related data 12 is delayed for some reason. The last AD / ADAS-related data 12c in the non-priority class time slot 19a is included in that time slot 19a at the start of transmission, but the transmission completion time exceeds that time slot 19a and encroaches on the next priority class time slot 18b. In this case, the transmission of the priority class data 14 will be delayed, or in the worst case scenario, it will have to be transmitted in the next time slot 18c, which means that the required delay value cannot be met, and this could have a significant impact on vehicle control.

[0029] To prevent this situation, IEEE802.1Qbv adopts a method called a guard band. A guard band is set at the end of each time slot. Within the guard band, frames currently being transmitted are allowed to continue transmitting, but the start of transmission of new frames (frames that have not yet been transmitted) is prohibited. By setting the width of the guard band to the maximum frame length of frames included in the class, it is possible to prevent encroachment into subsequent time slots.

[0030] Figure 6 shows the state of guard bands. Guard bands 20a and 20b are set at the ends of non-priority time slots 19a and 19b, respectively. Here, the last frame 12c of the AD / ADAS system data 12, which was scheduled to be transmitted at the same timing as the example of Figure 5, is prohibited from being transmitted because its transmission start time falls within the guard band 20a. Therefore, the subsequent PT / CH system data 14 can be transmitted within the scheduled time slot 18b, thereby satisfying the delay requirement. The last frame 12c of the AD / ADAS system data 12 is transmitted in the next non-priority data time slot 19b.

[0031] On the other hand, the protection of other classes by guard bands comes at a cost: the guard band is set to the maximum frame length within the class, so that shorter frames are not allowed to be transmitted even if requested. 6, a BODY related data frame 13 is received at the same timing and is waiting to be transmitted, but is not transmitted because its transmission start time falls within the guard band 20a. However, this BODY related data frame 13 is sufficiently short, and transmission is completed by the time slot 18b of the next priority class. Therefore, the frame is not transmitted within the guard band 20a.

[0032] Using guard bands in this way creates wasted time when no communication occurs. At the same time, frames accumulate in queues within the communications device, and transmission is suspended until the next low-priority time slot. This operation can cause the queue to overflow with data, resulting in frame loss, and also increases the load on the communications device as many frames must be transmitted in the next low-priority time slot.

[0033] Therefore, in this embodiment, the transmission opportunities for such short frames are increased, thereby improving communication efficiency, reducing frame loss, and reducing the load on the communication device. Specifically, as shown in FIG. 7, the low-priority class is divided into two or more subclasses that share time slots 21a and 21b, and frames in the low-priority class are classified into the subclasses according to their frame lengths. Because a maximum frame length is determined for each subclass, guard bands 22a, 22b corresponding to that maximum frame length can be set for each subclass. For example, AD / ADAS-related data 12, which has a long frame length, is classified as subclass 1, and BODY-related data 13, which has a short frame length, is classified as subclass 2. Even within guard band 22a for subclass 1, subclass 2 is not included in guard band 22b, and frames 13 belonging to subclass 2 can be transmitted. Hereinafter, the priority class and low priority class subclasses will be collectively referred to as classes. As explained in FIG. 5, the guard bands 22a and 22b are provided to permit the continuation of transmission of a frame currently being transmitted, but to prohibit the start of transmission of a new frame that has not yet been transmitted.

[0034] FIG. 8 is a diagram showing an example of a frame structure in this embodiment. In this embodiment, an Ethernet frame is applied. The communication device 2 transmits and receives a frame 30 shown in FIG. 8. The frame 30 includes a destination address (DA) 31, a source address (SA) 32, a type 33, a payload 35, and a frame check sequence (FCS) 36. It may also include a virtual local area network (VLAN) tag 34, which is a code for logically dividing a network. The portion from the destination address 31 to the VLAN tag 34 is referred to as a frame header 37.

[0035] The communication device 2 can also add additional information to the frame. 9 shows an example of a frame structure when additional information is added to a frame. In this case, the additional information is added to the beginning of a frame 38 as an internal header 39. Examples of the additional information include a receiving port number, a destination port number, and a class number.

[0036] FIG. 10 is a diagram illustrating the configuration of the communication device 2. The communication device 2 receives frames from inside or outside the communication device 2 at the receiving unit 40. The frames received by the receiving unit 40 are classified into classes by the classification unit 41 according to the information contained in the frames. Next, the queuing unit 46 buffers the frames for each class classified by the classification unit 41. Next, the gate unit 47 passes the frames queued in the queuing unit 46 when the gate is open, and blocks their passage when the gate is closed. The open / closed state of the gate unit 47 is controlled by the scheduling unit 48. The scheduling unit 48 determines the control timing of the gate unit 47 and sets guard bands that are transmission prohibition times near the end time of the gate open state for each class, thereby ensuring the timing of data transmission for other classes. This allows the guard bands to function effectively.

[0037] Furthermore, when multiple gates of the gate unit 47 are simultaneously opened and multiple frames are about to be output, the transmission selection unit 49 performs a transmission priority determination process to select one frame from the multiple frames and select the transmission frame in order. As a result, the frames classified by the classification unit 41 are transmitted at the transmission timing determined by the schedule unit 48. The frame selected by the transmission selection unit 49 is transmitted by the transmission unit 50. These components are mainly implemented in the network switch 6 (FIG. 2).

[0038] The classification unit 41 includes a frame data classification unit 42, a frame length classification unit 43, a class table 45, and a classification execution unit 44. The frame data classification unit 42 classifies the frame data into at least two categories according to the data conditions. The frame length classification unit 43 classifies frames into at least two categories according to the frame length of the frame. The classification criteria in the frame data classification unit 42 and the frame length classification unit 43 include frame data conditions and frame length conditions. The class data allocated according to the frame data conditions and frame length conditions is held in a class table 45 .

[0039] The classification execution unit 44 classifies the frame into one of the queues in the queuing unit 46 based on the class of the frame determined by the class table 45 . The gate unit 47 also holds gates for each class, each of which is connected to a corresponding queue in the queuing unit 46. For example, when there are two classes, the queuing unit 46 has two class-specific queues, and the gate unit 47 has two class-specific gates, with the queues and gates of the same class connected. The gate unit 47 controls the opening and closing of gates for each class based on information from the schedule unit 48. This ensures that the guard band settings for each class are strictly observed and that the transmission of frames for each class is properly controlled.

[0040] FIG. 11 is an example of the class table 45 in this embodiment. The class table 45 holds frame data conditions 60, frame length conditions 61, and classification class 62. The frame data conditions 60 hold data conditions for frames to be classified into classes. For example, the frame data conditions 60 are set as conditions based on the value of a specific field in the frame header 37, or a value (at least a portion of the value) at a specific position in the frame payload 35, or a combination of these. This allows the data conditions for the frame to be set appropriately.

[0041] The frame length condition 61 sets a condition for the frame length to be classified into each class. For example, the frame length condition 61 sets a condition such as the frame length being greater than, less than, or equal to a specific value. The class 62 to which the frame is classified is specified as a combination of the frame data condition 60 and the frame length condition 61.

[0042] 11, frame data condition 60 is set so that if source address (SA) 31 is XXX, it will be class 1, and if it is YYY, it will be class 2 or 3. Furthermore, frame length condition 61 is set so that if source address 31 is YYY and the frame length is greater than 500B, it will be class 2, and if source address 31 is YYY and the frame length is 500B or less, it will be class 3.

[0043] In addition, the scheduler 48 sets a guard band width corresponding to the maximum frame length for each class 62 specified in the class table 45, and the gate unit 47 controls the open / closed state of the gate so as to secure the guard band width determined for each class. 12 shows the configuration of the scheduler 48. The scheduler 48 holds a gate state table 70 that controls the open / closed state of the gate corresponding to each class at each periodic time, and a guard band table 71 that sets the guard band width for each class. The gate state table 70 holds the open / closed state 73 of the gate relative to time 72.

[0044] The gate open / closed state 73 in the gate state table 70 holds data indicating changes in the gate state at each time. For example, "o" indicates an open gate state (Open), and "C" indicates a closed gate state (Closed). This "o" or "C" is held for the number of classes. The order can be arbitrary as long as the class ID and gate correspond to each other, but for example, the data is held in ascending order of the class ID. Examples of gate state data are "oC...C" if only class 1 is open and classes 2 and above are closed, "Co...o" if only class 1 is closed and classes 2 and above are open, and "CC...C" if all classes are closed.

[0045] The guard band table 71 also holds a guard band width 75 for each class 74. In this embodiment, the settings of this guard band table 71 are set to match the maximum frame length specified in the frame length condition 61 of the class table 45. In this way, by matching the settings in the guard band table 71 with the maximum frame length specified in the frame length condition 61 of the class table 45, the guard bands can be set appropriately.

[0046] FIG. 13 is a flowchart showing the classification process performed by the classification unit 41. Classification unit 41 processes the frame received from reception unit 40 in frame data classification unit 42 to extract frame data, and inputs the frame data to frame data condition 60 in class table 45 (step S100). Here, frame data means the frame header and payload.

[0047] Next, frame length classification unit 43 calculates the frame length and inputs it to frame length condition 61 of class table 45 (step S101). Class table 45 searches for its entry based on input from frame data classification unit 42 and frame length classification unit 43 (step S102). Class table 45 determines whether this search results in a hit (step S103). If there is a hit in step S103, the corresponding class ID 62 is returned. If there is no hit, an error is returned or the default class ID is returned.

[0048] If the result is a hit (YES in step S103), the classification execution unit 44 stores the frame in the queue of the queuing unit 46 that corresponds to the hit class ID (step S104). If the result is not a hit (NO in step S103), the classification execution unit 44 stores the frame in the queue that corresponds to the default class (step S105).

[0049] FIG. 14 is a flowchart showing the process in which the scheduler 48 sets the guard band table 71. When the scheduling unit 48 sets the guard band table 71, the following process is repeated for each class (step S110). First, the scheduling unit 48 searches the frame length condition in the class table using the class ID (step S111). In searching for the frame length condition, the scheduling unit 48 determines whether or not there is a setting that specifies the maximum value of the frame length (step S112).

[0050] If there is a setting that defines the maximum value of the frame length in step S112 (YES in step S112), the scheduler 48 acquires the set maximum frame length (step S113). If there is no setting that defines the maximum value of the frame length in step S112 (NO in step S112), the scheduler 48 uses the Maximum Transmission Unit (MTU) as the maximum frame length (step S114).

[0051] Next, the scheduler 48 calculates the maximum frame duration from the maximum frame length to determine the guard band (step S115). Finally, the scheduler 48 sets the guard band in the corresponding class in the guard band table (step S116). The above is performed for all classes, and the loop ends (step S117). For example, since the maximum frame length (500 bytes) is set in the class table for class 3, the length is set to 4 μs (for 1 Gbps, the same applies below). Since there is no maximum frame length condition for class 2, the MTU value common to the entire in-vehicle network is used. If this is 1500 bytes, 12 μs is set in the guard band table accordingly.

[0052] As described above, according to this embodiment, the maximum frame length is determined for each subclass, and therefore guard bands 22a, 22b corresponding to the maximum frame length can be set for each subclass, as shown in Fig. 7. This increases the opportunities to transmit frames with short frame lengths, thereby improving communication efficiency, reducing frame loss, and reducing the load on communication devices.

[0053] In this embodiment, application to a vehicle employing a zone architecture has been described as an example, but the same effect can also be obtained when the architecture is applied to a domain-specific architecture that constitutes a hierarchical network for each major vehicle control function, provided that data with different priorities are mixed. Furthermore, the application of the present invention to an in-vehicle network using an in-vehicle electronic device such as the communication device 2 is merely an example of an application of the present invention to a network, and the present invention can also be applied to other networks such as a control network in a factory or a communication carrier network.

[0054] <Second embodiment> Next, a second embodiment of the present invention will be described with reference to Figures 15 to 18. In Figures 15 to 18 showing the second embodiment, parts corresponding to Figures 1 to 14 described in the first embodiment are given the same reference numerals. The second embodiment of the present invention is different from the first embodiment in that the data storage in the class table 45 and the classification processing operation of the classification unit 41 are changed. The other configurations and processes are the same as those in the first embodiment, so a description thereof will be omitted.

[0055] FIG. 15 is a diagram showing the configuration of the class table 45 in this embodiment. In this embodiment, the class table 45 is realized as three sub-tables. The first sub-table is a frame data condition table 63, which holds frame data conditions 60 and data condition IDs (ID-D) 66. The second sub-table is a frame length condition table 64, which holds a frame length condition 61 and a frame condition ID (ID-L) 67. The third sub-table is a class condition table 65, which holds a frame data condition ID (ID-D) 68, a frame length condition ID (ID-L) 69, and the class IDs 62 corresponding thereto.

[0056] The configuration of the classification units is the same as in the first embodiment, but the connections and operations are different. The frame data classification unit 42 is connected to a frame data condition table 63. The frame length classification unit 43 is connected to a frame length condition table 64. The classification execution unit 44 is connected to a class condition table 65.

[0057] FIG. 16 is a flowchart showing the operation process of the frame data classification unit 42. The frame data classification unit 42 first searches the frame data condition table 63 using the frame data (step S200) and determines whether the search results in a hit (step S201). If a hit is found in step S201 (YES in step S201), the frame data classification unit 42 obtains a data condition ID and writes the obtained data condition ID to the internal header 37 (step S202). If a hit is not found in step S201 (NO in step S201), the frame data classification unit 42 writes a default data condition ID to the internal header 37 (step S203).

[0058] FIG. 17 is a flowchart showing the operation process of the frame length classification unit 43. The frame length classification unit 43 calculates the frame length (step S204). Then, the frame length classification unit 43 searches the frame length condition table 64 using the frame length (step S205) and determines whether the search results in a hit (step S206). If a hit is found in step S206 (YES in step S206), the frame length classification unit 43 writes the frame length ID into the internal header 37 (step S207). If a hit is not found in step S206 (NO in step S206), the frame length classification unit 43 writes the default frame length ID into the internal header 37 (step S208).

[0059] FIG. 18 is a flowchart showing the operation process of the classification execution unit 44. The classification execution unit 44 acquires the data condition ID 66 and the frame length ID 67 from the internal header 37 (step S209). Then, the classification execution unit 44 searches the class condition table based on the acquired data condition ID 66 and frame length ID 67 (step S210), and determines whether the search results in a hit (step S211). If a hit is found in step S211 (YES in step S211), the classification execution unit 44 acquires the class ID and classifies the frame into the queue corresponding to the class ID (step S212). If a hit is not found in step S211 (NO in step S21), the classification execution unit 44 classifies the frame into the default queue (step S213).

[0060] <Third embodiment> Next, a third embodiment of the present invention will be described with reference to Figures 19 to 24. In Figures 19 to 24 showing the third embodiment, parts corresponding to Figures 1 to 18 described in the first and second embodiments are given the same reference numerals. In the third embodiment of the present invention, in order to further improve communication efficiency, the class table 45 and the scheduler 48 are dynamically changed depending on the operating status of the communication device 2. The other configurations and processes are the same as those of the first and second embodiments, and therefore will not be described here.

[0061] For example, by dynamically changing the frame length condition for two or more classes classified by the frame length condition, the communication efficiency can be improved according to the network state by changing the class table 45 and the scheduler 48. In other words, if the result of classifying by the frame length condition is that there are many frames whose transmission is prohibited by guard bands, further dividing this class can be expected to improve the communication efficiency.

[0062] FIG. 19 is a configuration diagram of a communication device 2 in the third embodiment. In addition to the configuration (FIG. 10) described in the first embodiment, the communication device 2 of the third embodiment additionally includes a monitoring unit 51 and a setting management unit 52. The monitoring unit 51 and the setting management unit 52 are mainly implemented in the CPU 7 (FIG. 2). The remaining parts of the communication device 2 are implemented in the network switch 6, similar to the first embodiment.

[0063] The monitoring unit 51 monitors the internal state of the communication device 2. For example, it collects information from the receiving unit 40, the classification unit 41, the queuing unit 46, the gate unit 47, the transmission selection unit 49, and the transmitting unit 50, and analyzes this information to monitor the state of the communication device 2. FIG. 20 is a flowchart showing an example of the operation process of the monitoring unit 51. As an example of monitoring, the monitoring unit 51 collects statistical information from the gate unit 47 for each class and collects information on frames whose transmission is prohibited by guard bands (step S300). Specifically, the monitoring unit 51 collects the number of frames whose transmission is prohibited by guard bands and their frame lengths.

[0064] The setting management unit 52 shown in FIG. 19 determines whether to change the settings based on the state of the communication device 2 monitored by the monitoring unit 51, and changes the settings of the class table 45 and the schedule unit .

[0065] FIG. 21 is a flowchart showing an example of the operation process of the setting management unit 52. The setting management unit 52 performs the following process for each class (step S301). First, the setting management unit 52 acquires statistical information on frames not transmitted due to the guard band from the monitoring unit 51 (step S302). Next, the setting management unit 52 creates a histogram of frame lengths for frames not transmitted due to the guard band based on the acquired information (step S303). Next, the setting management unit 52 adds up the number of frames for each interval starting from the minimum value of the created histogram to obtain a cumulative histogram (step S304). Furthermore, the setting management unit 52 acquires the frame length at which the frame count ratio in the cumulative histogram exceeds a preset threshold value (step S305).

[0066] Then, the setting management unit 52 determines whether the calculated frame length is smaller than the frame length currently used for class division (step S306). If the calculated frame length is smaller than the frame length currently used for class division in step S306 (YES in step S306), the setting management unit 52 executes the following steps S310 to S330, since dividing the classes is expected to improve communication efficiency.

[0067] That is, the setting management unit 52 first changes the setting of a class table that is defined separately (step S310). Next, the setting management unit 52 changes the setting of a gate state table that is defined separately (step S320). Finally, the setting management unit 52 changes the setting of a guard band table that is defined separately (step S330), and ends the loop (step S307).

[0068] If the frame length is not smaller than the frame length used for class division in step S306 (NO in step S306), the setting management unit 52 omits the processes of steps S310 to S330 and ends the loop (step S307).

[0069] FIG. 22 is a flowchart showing the operational process for changing the settings of the class table 45. First, the setting management unit 52 extracts the settings of the class from the class table 45 (step S311). Next, the setting management unit 52 copies the extracted settings into the class table (step S312). Here, the setting management unit 52 adds a condition that "the frame length is greater than the calculated frame length" to one of the copied settings (step S313). Furthermore, the setting management unit 52 overwrites the other of the copied settings with a condition that "the frame length is equal to or less than the calculated frame length," and sets a currently unused class ID as the class ID (step S314).

[0070] FIG. 23 is a flowchart showing the operation process for changing the settings of the gate status table 70. When changing the settings of the gate state table 70, the setting management unit 52 first acquires the gate settings of the class ID from the gate state table 70 (step S321). Next, the setting management unit 52 copies and sets the acquired gate settings as the gate settings of the class ID newly used in the class table setting change (step S322).

[0071] FIG. 24 is a flowchart showing the operational process for changing the settings of the guard band table 71. When changing the settings of the guard band table 71, the setting management unit 52 sets a guard band equivalent to the calculated frame length as the guard band setting for the class ID newly used in the class table setting change (step S310) (step S331). In this way, it is possible to set an appropriate guard band table according to the communication situation at the time by making the class table, gate state table, and guard band table rewritable as needed based on statistical information, i.e., the characteristics of communication traffic, of communication device 2. For example, if statistical information on frames that were not transmitted due to guard bands is obtained and there are many frames that were not transmitted, further division of classes can be expected to improve communication efficiency.

[0072] In addition, statistical information of frames passing through this communication device 2 may be used as statistical information of the communication device 2, and the operation pattern of this communication device 2 may be estimated from the statistical information of frames passing through this communication device 2, and the settings of the class table, gate state table, and guard band table may be selected from the estimated operation pattern of the communication device 2.

[0073] <Fourth embodiment> Next, a fourth embodiment of the present invention will be described with reference to FIGS. In the fourth embodiment of the present invention, as a modification of the third embodiment, the settings of the class table 45 and the scheduler 48 are stored as presets in advance, and the settings are switched from the presets depending on the operating status of the communication device 2. The other configurations and processes are the same as those of the first to third embodiments, and therefore description thereof will be omitted.

[0074] The configuration of the communication device 2 in the fourth embodiment of the present invention is the same as the configuration of the communication device 2 in the third embodiment, except that the setting management unit 52 is provided with a setting preset table. 25 is an example of a setting preset table 80 held by the setting management unit 52. The setting preset table 80 holds class table settings 82, gate state table settings 83, and guard band table settings 84 corresponding to statistical information conditions 81. These settings are set in advance assuming the operation patterns of the communication device 2.

[0075] FIG. 26 is a flowchart showing the operation process of the setting management unit 52 in the fourth embodiment. The setting management unit 52 collects statistical information of the communication device 2 from the monitoring unit 51 (step S400). For example, the frame length for each class, the frame reception period, the number of frames, etc. may be used as the statistical information of the communication device 2. Alternatively, the hardware and software status of the communication device 2 may be monitored and used as statistical information.

[0076] Next, the setting management unit 52 searches the setting preset table 80 using the collected statistical information, and obtains the optimal class table setting 82, gate state table setting 83, and guard band table setting 84 for the operation pattern of the communication device (step S401). Finally, the setting management unit 52 uses these setting information to change the settings of the class table, gate state table, and guard band table in this order (step S402). The collection of statistical information, the identification of communication device operation patterns, and the determination of setting presets may be performed by another communication device 2 connected via the shared bus 5, rather than by the target communication device 2 itself.

[0077] <Fifth embodiment> Next, a fifth embodiment of the present invention will be described with reference to Figures 27 to 30. In Figures 27 to 30 showing the fifth embodiment, parts corresponding to Figures 1 to 26 described in the first to fourth embodiments are given the same reference numerals. In the fifth embodiment of the present invention, as a modification of the third and fourth embodiments, the settings of the class table 45, gate state table 70, and guard band table 71 are changed over-the-air (OTA) from outside the vehicle. The other configurations and processes are the same as those of the first to fourth embodiments, and therefore description thereof will be omitted.

[0078] FIG. 27 is a configuration diagram of an in-vehicle network in the fifth embodiment. In the network in the vehicle 1 shown in FIG. 27, a Tele-Communication Unit (TCU) 8 is added to the network shown in FIG. The TCU 8 is connected to one of the communication devices 2. The TCU 8 communicates with communication devices outside the vehicle. Although the communication performed by the TCU 8 includes the transmission of vehicle information, the following description will be given assuming that the communication performed by the TCU 8 is the reception of information for changing various settings.

[0079] FIG. 28 is a schematic diagram showing the flow of setting update via OTA. When the TCU 8 receives the OTA data 90, the OTA data 90 is transferred to the communication device 2a that performs the OTA processing. In the communication device 2a that performs the OTA processing, the setting information is divided into pieces for each setting destination. For example, in communication device 2a, the information is classified into setting information 91 for each communication device and other setting information 92. Then, communication device 2a transfers communication device setting information 91 to the corresponding communication device 2b. When communication device 2b receives setting information 91, communication device 2b applies the settings. In this case, the settings of class table 45, gate state table 70, and guard band table 71 are applied.

[0080] FIG. 29 is a configuration diagram of a communication device 2 in the fifth embodiment of the present invention. The communication device 2 shown in FIG. 29 differs from the communication device 2 of the third embodiment in that a setting acceptance unit 53 is added. The setting reception unit 53 waits for a setting change from the communication device 2a that performs OTA processing, and when a setting is input, it sets the communication device 2. The setting reception unit 53 is mainly implemented in the CPU 7. The monitoring unit 51 and the setting management unit 52 are implemented in the CPU 7 as in the third embodiment, and the remaining parts are implemented in the network switch 6 as in the first embodiment.

[0081] FIG. 30 is a flowchart showing the operational process of updating settings via OTA in the fifth embodiment of the present invention. First, the TCU 8 receives the setting information (step S500), and transfers the setting information received by the TCU 8 to the communication device 2a that performs the OTA process (step S501). Next, the communication device 2a performing the OTA processing receives the setting information from the TCU 8 and classifies it into communication device settings 91 and other settings 92 (step S502). Subsequently, the communication device 2a performing the OTA processing transfers the communication device setting information 91 to each communication device 2b (step S503).

[0082] If the communication device 2b to be set is the communication device 2a itself that performs the OTA processing, the communication device setting information 91 is not actually transmitted, but is generally regarded as being transferred within the communication device 2a itself. Finally, the communication device 2b extracts the settings of the class table 45, the gate state table 70, and the guard band table 71 from the received communication device setting information 91 (step S504), and updates the settings of each table. The classification of the setting information may be performed by the TCU instead of the communication device. In this way, the class table, gate state table, and guard band table can be rewritten through communication with the outside of the vehicle, making it possible to set appropriate guard bands based on instructions from the outside of the vehicle. Note that communication with the outside of the vehicle is just one example, and rewriting may also be performed in a similar manner through communication with another device inside the vehicle.

[0083] <Modification> The embodiments described above have been described in detail to clearly explain the present invention, and are not necessarily limited to those including all of the configurations described. For example, the application of the present invention to an in-vehicle network using in-vehicle electronic devices such as the communication device 2 is just one example of a network application, and the network including the communication device 2 described in each embodiment can also be applied to other networks such as a control network for a factory or a communication carrier network.

[0084] In addition, in the configuration diagrams shown in Figures 1, 2, 10, etc., only control lines and information lines that are considered necessary for explanation are shown, and not all control lines and information lines in the product are necessarily shown. In reality, it can be assumed that almost all components are interconnected. Furthermore, the time slot settings shown in FIG. 7 and the frame configurations shown in FIG. 8 are merely preferred examples, and are not limited to the examples shown. Furthermore, the flow of operational processing in the flowcharts shown in FIG. 13 and the like is also an example, and as long as the processing results are the same, the order of some of the processing may be changed or multiple processes may be executed simultaneously. [Explanation of symbols]

[0085] 1...vehicle, 2, 2a, 2b...communication device, 3...sensor, 4...actuator, 5...shared bus, 6...network switch, 7...CPU, 8...TCU, 40...receiving unit, 41...classifying unit, 42...frame data classifying unit, 43...frame length classifying unit, 44...classification execution unit, 45...class table, 46...queuing unit, 47...gate unit, 48...scheduling unit, 49...transmission selection unit, 50...transmitting unit, 51...monitoring unit, 52...setting management unit, 53...setting reception unit, 63...frame data condition table, 64...frame length condition table, 65...class condition table, 70...gate status table, 71...guard band table, 80...setting preset table

Claims

1. A communication device that is mounted on a vehicle and communicates information related to driving or driving assistance of the vehicle and information unrelated to driving of the vehicle, a receiving unit that receives frames from inside or outside the vehicle; a classification unit that classifies the frames received by the receiving unit into a priority class in which the information included in the frames is related to driving or driving assistance, and a non-priority class in which the information included in the frames is not related to driving; a queuing unit that buffers the frames for each class classified by the classifying unit; a gate unit that allows the frames queued in the queuing unit to pass in a gate open state and blocks the frames from passing in a gate closed state; a scheduling unit that determines whether the gate unit is open or closed, and that ensures data transmission timing for other classes by setting a guard band that is a transmission prohibition time near the end time of the gate open state of the class; a transmission unit that transmits the frame that has been passed by the gate unit, The classification unit a frame data classification unit that classifies the frames according to data conditions; a frame length classification unit that classifies the frames according to their frame lengths; a class table that holds data conditions and frame length conditions of the frame as classification criteria in the frame data classification unit and the frame length classification unit, and class data assigned based on the data conditions and the frame length conditions; a classification execution unit that classifies the frame based on the determination of the class of the frame by the class table, the scheduling unit sets a guard band width corresponding to a maximum frame length for each of the classes defined in the class table; the gate unit controls an open / closed state so as to ensure the guard band width determined for each class; The scheduling unit a gate state table that controls the open / close state of the gate corresponding to each class at each periodic time; a guard band table that sets the guard band width for each class, determining an open / closed state of the gate unit based on the gate state table and the guard band table; the class table, the gate state table, and the guard band table can be rewritten as needed based on the characteristics of communication traffic; The classification unit further divides the classes by using statistical information on frames that were not transmitted due to guard bands as the characteristics of the communication traffic, and if there are frames that were not transmitted, Communication equipment.

2. The scheduling unit Near the end time of the gate open state of each class, the gate section is kept open for frames being transmitted, and the gate section is closed for frames not yet transmitted, thereby securing the guard band. The communication device according to claim 1 .

3. the queuing unit is configured with at least two or more class-specific queues, the gate section is composed of at least two or more class-specific gates, Queues and gates of the same class are connected The communication device according to claim 1 .

4. A transmission selection unit is provided behind the gate unit to determine the transmission priority of each frame, and when gate units of a plurality of classes are opened at the same time and frames are output at the same time, the transmission selection unit determines the transmission priority of the frames. The communication device according to claim 3 .

5. The transmitting unit transmits the frames in the order determined by the transmission selecting unit. The communication device according to claim 4.

6. The frame length classification criteria in the class table and the guard band table are determined so as to be consistent with each other. The communication device according to claim 1 .

7. The classification unit classifies the frames into priority classes and non-priority classes according to the data content. The communication device according to claim 1 .

8. The data condition of the frame is a condition based on a field value in a frame header, a value of at least a part of a frame payload, or a combination thereof. The communication device according to claim 1 .

9. using statistical information of frames passing through the communication device as the characteristics of the communication traffic; An operation pattern of the communication device is estimated from the statistical information of frames passing through the device, and a setting is selected based on the estimated operation pattern of the communication device. The communication device according to claim 1 .

10. The class table, the gate state table, and the guard band table are Can be rewritten via communication The communication device according to claim 1 .

11. The vehicle is equipped with a plurality of ECUs, The plurality of ECUs include a first ECU that controls engine control or steering control, a second ECU that performs automatic control or safe driving assistance, a third ECU for a body system, and a fourth ECU for an info system, The information regarding the driving or driving assistance is information regarding communication performed between the first ECU and the second ECU, The communication of information not related to the running of the vehicle is communication performed by the third ECU and the fourth ECU. The communication device according to claim 1 .

12. The communication device according to claim 1 is mounted In-vehicle electronic equipment.

Images