Communication design device and communication design method

Abstract

This communication design device performs communication design of a network to which a plurality of communication devices are connected and via which the plurality of communication devices communicate with each other in accordance with a request from an application, wherein: the device comprises a communication requirement storage unit that stores a delay allowable time indicating the length of a communication delay time that is permitted for each application and a packet length of communication data prescribed for each application, and a schedule setting unit that allocates a time slot of the communication to each application; and the schedule setting unit sets the period of the time slot on the basis of the delay allowable time pertaining to the plurality of applications, and sets the length of the time slot on the basis of the packet length pertaining to the plurality of applications.

Description

Communication design device and communication design method

[0001] The present invention relates to an apparatus and method for performing communication design for a network.

[0002] Conventionally, there are known communication networks in which communication by multiple types of applications is performed in parallel, and communication requirements such as allowable delay time differ for each application, such as an in-vehicle network configured with multiple electronic control units (ECUs) installed in a vehicle. In such communication networks, it is important to reliably guarantee the communication requirements of all applications, so it is important to perform a communication design that sets appropriate communication timing for each application.

[0003] Time-Sensitive Networking (TSN), for example, is known as a technology for ensuring real-time communication of communication data in a network. TSN is defined as a communication method that extends standard Ethernet (registered trademark) and realizes real-time communication in Ethernet communication. TSN standards include a time synchronization method within a network (IEEE 802.1AS), a method for guaranteeing transmission bandwidth using a credit-based shaper (IEEE 802.1Qav), and a method for communicating in predetermined time slots based on synchronized time (IEEE 802.1Qbv).

[0004] In recent years, methods have been proposed for realizing optimal communication design by treating communication requirements that differ for each application as an optimization problem and solving this problem. For example, Patent Literature 1 describes a wireless communication method in which a single channel can be used by multiple wireless systems in a time-sharing manner by using a time slot commonly defined based on information about all devices included in the wireless communication system. Furthermore, for traffic to be transmitted by each communication device, a counter value is set that takes into account the transmission timing and allowable delay amount and is expressed as an integer value in units of the time slot length. Based on this counter value, the wireless communication method identifies the traffic to be transmitted in each time slot. This wireless communication method is capable of solving a combinatorial optimization problem of determining the best timing for transmitting each time slot using a simple technique, and is therefore said to be able to appropriately control the transmission timing of traffic even in a narrow space where many wireless communication devices exist.

[0005] Japanese Patent Application Publication No. 2020-155857

[0006] The technique described in Patent Document 1 requires that time slots be defined in advance without taking into account the communication requirements of each application, making it difficult to set an appropriate time slot width according to the communication requirements that differ for each application. As a result, there is a problem in that optimal communication design cannot be achieved.

[0007] Therefore, an object of the present invention is to provide a technology that can realize an optimal communication design for a network in which communication is performed according to the requests of various applications with different communication requirements.

[0008] A communication design apparatus according to the present invention performs communication design for a network to which a plurality of communication devices are connected and which communicate with each other in accordance with application requests, the apparatus comprising: a communication requirements storage unit that stores an allowable delay time indicating the length of the communication delay time allowed for each of the applications and a communication data packet length determined for each of the applications; and a schedule setting unit that allocates communication time slots for each of the applications, the schedule setting unit setting a period of the time slot based on the allowable delay times for each of the applications and setting the length of the time slot based on the packet lengths for each of the applications. A communication design method according to the present invention performs communication design for a network to which a plurality of communication devices are connected and which communicate with each other in accordance with application requests, the communication design method storing an allowable delay time indicating the length of the communication delay time allowed for each of the applications and the communication data packet length determined for each of the applications in a computer, the computer allocating communication time slots for each of the applications, the computer setting the period of the time slot based on the allowable delay time for each of the applications and setting the length of the time slot based on the packet lengths for each of the applications.

[0009] According to the present invention, it is possible to provide a technique that can realize an optimal communication design for a network in which communication is performed according to the requests of various applications with different communication requirements.

[0010] 1 is a diagram showing an example of a network for which a communication design device of the present invention performs communication design. FIG. 2 is a diagram showing an example of the configuration of each communication device in an in-vehicle network. FIG. 3 is a diagram showing an example of the configuration of a system including a communication design device according to a first embodiment of the present invention. FIG. 4 is a functional block diagram showing the configuration of a communication design device according to a first embodiment of the present invention. FIG. 5 is a diagram showing an example of a communication schedule for an in-vehicle network. FIG. 6 is a diagram showing an example of a time-guaranteed communication requirements table. FIG. 7 is a diagram showing an example of a bandwidth-guaranteed communication requirements table. FIG. 8 is a flowchart explaining a method for setting a communication schedule in the communication design device according to the first embodiment of the present invention. FIG. 9 is a flowchart showing the flow of a schedule calculation process for time-guaranteed communication. FIG. 10 is a diagram showing an example of time slots assigned to time-guaranteed applications by the schedule calculation process for time-guaranteed communication. FIG. 11 is a diagram showing an example of a result of the schedule calculation process for time-guaranteed communication. FIG. 12 is a flowchart showing the flow of a communication path calculation process for bandwidth-guaranteed communication. FIG. 13 is a diagram showing an example of link usage information. FIG. 14 is a diagram showing example network design data. FIG. 14 is a diagram showing an example of the configuration of a system including a communication design device according to a second embodiment of the present invention. FIG. 15 is a functional block diagram showing the configuration of a communication design device according to the second embodiment of the present invention. FIG. 16 is a flowchart explaining a method for resetting a communication schedule in the communication design device according to the second embodiment of the present invention. FIG. 17 is a flowchart showing the flow of a schedule recalculation process for time-guaranteed communication. FIG. 18 is a flowchart showing the flow of a communication path recalculation process for bandwidth-guaranteed communication. FIG. 10 is a functional block diagram showing a configuration of a communication design apparatus according to a third embodiment of the present invention.

[0011] The communication design device of the present invention will be described below with reference to the drawings.

[0012] (Network Configuration) Fig. 1 is a diagram showing an example of the configuration of an in-vehicle network used in an automobile, as an example of a network for which the communication design device of the present invention performs communication design. In Fig. 1, (a) shows an example of the configuration of an in-vehicle network based on domain architecture, and (b) shows an example of the configuration of an in-vehicle network based on zone architecture.

[0013] 1(a) and 1(b) are mounted on a vehicle 1 and perform communication by various applications used during operation of the vehicle 1. In the example of the domain-specific architecture configuration shown in FIG. 1(a), the in-vehicle network 20 is configured by interconnecting a gateway 2, a plurality of domain ECUs 3, sensors 4, and actuators 5 combined by domain, and a TCU (Telematics Control Unit) 7.

[0014] The domain ECUs 3 each execute a predetermined application, transmit and receive various signals to and from sensors 4 and actuators 5 connected via signal lines 6, and communicate with each other via the gateway 2 in accordance with requests from the applications they execute. The domain ECUs 3 include, for example, a domain ECU 3a that executes an application related to the ADAS (Advanced Driver Assistance Systems) of the vehicle 1, a domain ECU 3b that executes an application related to driving control of the vehicle 1, a domain ECU 3c that executes an application related to electrical components of the vehicle 1, and a domain ECU 3d that executes an application related to infotainment devices (navigation device, audio device, etc.) mounted on the vehicle 1. Note that the domain ECUs 3 may further include domain ECUs 3 that execute other applications, or may be replaced by the domain ECUs 3a to 3d.

[0015] The domain ECUs 3a to 3d are connected to sensors 4a to 4d and actuators 5a to 5d via signal lines 6a to 6d, respectively. The domain ECUs 3a to 3d control the actuators 5a to 5d based on the sensor signals received from the sensors 4a to 4d, and can also transmit and receive communication data related to the sensor signals of the sensors 4a to 4d and communication data related to the control of the actuators 5a to 5d via the gateway 2, and use the data for controlling the actuators 5a to 5d.

[0016] The TCU 7 is a device that performs wireless communication with a predetermined communication partner (for example, a vehicle control device that controls multiple vehicles including the vehicle 1, or other vehicles around the vehicle 1). The TCU 7 and the domain ECUs 3a to 3d are connected to each other via a gateway 2. By using this TCU 7, the in-vehicle network 20 in FIG. 1(a) can transmit communication data exchanged between the domain ECUs 3a to 3d to the communication partners, and provide communication data received from the communication partners to the domain ECUs 3a to 3d.

[0017] The gateway 2 is a device that performs communication control required when transmitting and receiving communication data between the domain ECUs 3a to 3d and the TCU 7. The domain ECUs 3a to 3d and the TCU 7 can communicate with each other via the gateway 2.

[0018] In the example of the zone architecture configuration shown in Figure 1(b), the in-vehicle network 20 is configured by interconnecting a central ECU 8, multiple zone ECUs 9 combined by zone, sensors 4 and actuators 5, and a TCU 7.

[0019] The zone ECUs 9 each execute a predetermined application, transmit and receive various signals to and from the sensors 4 and actuators 5 arranged in each zone within the vehicle 1, and communicate with each other via the central ECU 8 and the shared bus 10 in accordance with requests from the applications they are executing. The zone ECUs 9 include, for example, zone ECUs 9a and 9b arranged on the right and left sides of the front of the vehicle 1 and executing predetermined applications, and zone ECUs 9c and 9d arranged on the right and left sides of the rear of the vehicle 1 and executing predetermined applications. Note that the vehicle may further include zone ECUs 9 arranged in other locations, or may replace the zone ECUs 9a to 9d.

[0020] The zone ECUs 9a to 9d are connected to the sensors 4a to 4d and the actuators 5a to 5d via signal lines and communication buses, respectively. Similar to the domain ECUs 3a to 3d in Fig. 1A, the zone ECUs 9a to 9d control the actuators 5a to 5d based on the sensor signals received from the sensors 4a to 4d, respectively, and can transmit and receive communication data related to the sensor signals of the sensors 4a to 4d and communication data related to the control of the actuators 5a to 5d to each other via the central ECU 8 and the shared bus 10, and use the data for controlling the actuators 5a to 5d.

[0021] The TCU 7 operates in the same manner as in Fig. 1(a). By using this TCU 7, the in-vehicle network 20 in Fig. 1(b) can transmit communication data exchanged between the central ECU 8 and the zone ECUs 9a to 9d to the communication partner, and provide communication data received from the communication partner to the central ECU 8 and the zone ECUs 9a to 9d.

[0022] FIG. 2 is a diagram showing an example of the configuration of each communication device (domain ECU 3, zone ECU 9, gateway 2, and central ECU 8) in the in-vehicle network 20 shown in FIG.

[0023] 2A shows an example of the configuration of the domain ECU 3. As shown in FIG. 2A, the domain ECU 3 is configured to include a CPU 11 and a memory 12. The CPU 11 executes predetermined processes using various data and programs stored in the memory 12, thereby executing an application corresponding to the function of the domain ECU 3. In accordance with requests from the application, communication is performed between the CPU 11 and the gateway 2, and various signals are transmitted and received between the CPU 11 and the sensors 4 and actuators 5.

[0024] 2(b) shows an example of the configuration of the zone ECU 9. As shown in FIG. 2(b), the zone ECU 9 is configured to include a CPU 11, a memory 12, and a network switch 13. The network switch 13 performs communication control processing for communication data exchanged between other zone ECUs 9 and the central ECU 8. The CPU 11 executes predetermined processing using various data and programs stored in the memory 12, thereby executing an application corresponding to the function of the zone ECU 9. In accordance with requests from this application, network communication is performed between the CPU 11 and other zone ECUs 9 or the central ECU 8 via the network switch 13, and various signals are exchanged between the CPU 11 and the sensors 4 and actuators 5.

[0025] 2(c) shows an example of the configuration of the gateway 2. As shown in Fig. 2(c), the gateway 2 is configured to include a CPU 11, a memory 12, and a network switch 13. The CPU 11 controls the operation of the network switch 13 by executing predetermined processes using various data and programs stored in the memory 12. The network switch 13 operates under the control of the CPU 11, and performs communication control processing for communication data transmitted and received between each domain ECU 3.

[0026] 2(d) shows an example of the configuration of the central ECU 8. As shown in Fig. 2(d), the central ECU 8 is configured to include a CPU 11, a memory 12, and a network switch 13. The CPU 11 executes predetermined processes using various data and programs stored in the memory 12, thereby controlling the operation of the network switch 13 and executing predetermined applications. The network switch 13 operates under the control of the CPU 11, and performs communication control processing for communication data transmitted and received between the central ECU 8 and the zone ECU 9.

[0027] [First Embodiment] Next, a communication design device according to a first embodiment of the present invention will be described below with reference to Figures 3 to 14. In this embodiment, an example of a communication design device will be described in which communication design for the in-vehicle network 20 described in Figure 1 is performed in advance and the design results are reflected in the in-vehicle network 20.

[0028] 3 is a diagram showing an example of the configuration of a system including a communication design device according to the first embodiment of the present invention. The system shown in Fig. 3 is a system for performing communication settings for an in-vehicle network 20 of a vehicle 1, and is configured to include a network information input device 21 and a communication design device 22 provided at a design base 30, and a communication setting device 23 provided at a manufacturing base 31.

[0029] The network information input device 21 inputs network information required for communication design of the in-vehicle network 20 to the communication design device 22. The network information input device 21 can accept an operation from, for example, a designer working at the design base 30, set the network information specified by this operation as a prerequisite for communication design of the in-vehicle network 20, and input the network information to the communication design device 22.

[0030] The communication design device 22 automatically performs communication design for the in-vehicle network 20 based on the network information input from the network information input device 21. At this time, the communication design device 22 accepts operations from the designer and determines communication setting conditions for each application so as to satisfy the communication requirements of each application specified by this operation. The results of the communication design by the communication design device 22 are transmitted from the communication design device 22 to the communication setting device 23 as network design data 40 for the in-vehicle network 20. Details of the communication design device 22 will be described later.

[0031] The communication setting device 23 determines the setting contents for each communication device (such as the domain ECU 3, the zone ECU 9, the gateway 2, and the central ECU 8) in the in-vehicle network 20 based on the network design data 40 transmitted from the communication design device 22. The setting contents for each communication device by the communication setting device 23 are transmitted from the communication setting device 23 to the in-vehicle network 20 as network setting data 41 for the in-vehicle network 20.

[0032] In the in-vehicle network 20, each communication device is configured based on the network setting data 41 transmitted from the communication setting device 23. This allows communication settings for the in-vehicle network 20 to be made so that each communication device can communicate with each other in accordance with requests from applications executed in each domain ECU 3 and each zone ECU 9.

[0033] (Configuration of the communication design device) Fig. 4 is a functional block diagram showing the configuration of the communication design device according to the first embodiment of the present invention. As shown in Fig. 4, the communication design device 22 is configured to include, for example, functional blocks of a communication requirement storage unit 50, a schedule setting unit 51, and a setting output unit 52. These functional blocks in the communication design device 22 are realized, for example, by a computer executing a predetermined program.

[0034] The communication requirement storage unit 50 stores communication requirement information, which is information relating to the communication requirements of each application in the in-vehicle network 20. The communication requirement storage unit 50 can be realized, for example, using various storage devices (HDD, SSD, flash memory, etc.) provided in a computer. Details of the communication requirement information stored in the communication requirement storage unit 50 will be described later.

[0035] The schedule setting unit 51 sets a communication schedule for the in-vehicle network 20 for each application based on the communication requirement information stored in the communication requirement storage unit 50. The schedule setting unit 51 can set the communication schedule for the in-vehicle network 20 by allocating time slots for communication by each application so as to satisfy the communication requirements that differ for each application. Note that the method for setting the communication schedule by the schedule setting unit 51 will be described in detail later.

[0036] The setting output unit 52 determines setting information related to communication control of the in-vehicle network 20 based on the communication schedule set by the schedule setting unit 51, and outputs this setting information as network design data 40. The network design data 40 output from the setting output unit 52 is transmitted from the communication design device 22 to the communication setting device 23 as described above, and is used in the processing performed by the communication setting device 23.

[0037] (Communication Schedule) Fig. 5 is a diagram showing an example of a communication schedule for the in-vehicle network 20 set by the schedule setting unit 51. The schedule setting unit 51 sets time slots 100, 101, and 102 at predetermined cycles, for example, and allocates these time slots to communication for each application, thereby setting the communication schedule for the in-vehicle network 20. The time slots can be realized by the IEEE 802.1Qbv of the TSN standard.

[0038] The time slot 100 is assigned to an application that performs communication at short intervals and requires time guarantee to keep delay time within a predetermined delay tolerance. In the in-vehicle network 20, the time slot 100 is reserved at regular intervals for communication performed in accordance with the request of the application, and communication data is transmitted and received between communication devices within the in-vehicle network 20 within the time slot 100. In this way, communication that satisfies the communication requirements of the application is performed.

[0039] The time slot 101 is allocated to an application that performs communication over a long period that requires time guarantee. In the in-vehicle network 20, the time slot 101 is reserved at regular intervals with a period longer than the above-mentioned time slot 100 for communication performed in accordance with the request of the application, and communication data is transmitted and received between communication devices in the in-vehicle network 20 within the period of this time slot 101. In this way, communication that satisfies the communication requirements of the application is performed.

[0040] The time slot 102 is assigned to each application that performs communication that does not require time guarantee. In the in-vehicle network 20, a period excluding the above-mentioned time slots 100 and 101 is reserved as the time slot 102 for communication performed in accordance with the request of the application, and communication data is transmitted and received between communication devices in the in-vehicle network 20 during the period of the time slot 102. In the time slot 102, three classes that guarantee communication bandwidth and another best-effort class are set corresponding to the multiple communication ports of the communication device, and one of the classes is assigned according to the communication requirements of each application. Note that the guarantee of communication bandwidth can be achieved by the IEEE 802.1Qav of the TSN standard. As a result, communication that meets the communication requirements of the application is performed.

[0041] 5 is an example, and other communication schedules may be used. For example, one or three or more time slots may be set for time guarantee, and the number of bandwidth guaranteed classes set within the time slots 102 may be other than three. Furthermore, all of the time slots 102 may be assigned to the bandwidth guaranteed class, or conversely, all of the time slots 102 may be assigned to the best-effort class. In addition to this, the communication schedule of the in-vehicle network 20 may be set using any other time slot configuration.

[0042] (Communication Requirement Information) Fig. 6 is a diagram showing an example of a time-guaranteed communication requirement table that indicates communication requirement information for applications (hereinafter referred to as "time-guaranteed applications") that perform communication requiring time assurance, among the communication requirement information stored in the communication requirement storage unit 50. The time-guaranteed communication requirement table 200 shown in Fig. 6 has records set for each type of communication data by each time-guaranteed application, and each record has data on a source 201, a destination 202, a communication cycle 203, a delay requirement 204, and a packet length 205.

[0043] The source 201 and destination 202 fields store information representing the source and destination communication devices of each communication data, respectively. The communication cycle 203 stores information representing the communication cycle of each communication data. The delay requirement 204 stores information representing the allowable delay time of each communication data. The packet length 205 stores information representing the packet length (amount of communication data) of each communication data. These pieces of information represent the communication requirements that must be met for each communication data for each time guarantee application.

[0044] 7 is a diagram showing an example of a bandwidth-guaranteed communication requirement table that represents communication requirement information for applications (hereinafter referred to as "bandwidth-guaranteed applications") that perform communication that does not require time guarantee but requires securing a predetermined communication bandwidth, among the communication requirement information stored in communication requirement storage unit 50. Bandwidth-guaranteed communication requirement table 210 shown in Fig. 7 has records set for each type of communication data by each bandwidth-guaranteed application, and each record has data for source 211, destination 212, and communication bandwidth 213.

[0045] Information representing the communication device of the source and destination of each communication data is stored in source 211 and destination 212, respectively. Information representing the communication bandwidth of each communication data is stored in communication bandwidth 213. This information represents the communication requirements that must be met for each communication data for each bandwidth guaranteed application that has a relatively large amount of communication data and therefore needs to regularly reserve a certain amount of communication bandwidth.

[0046] 6 and the contents of the bandwidth-guaranteed communication requirement table 210 shown in Fig. 7 are stored in the communication requirement storage unit 50, for example, by a designer inputting them in advance into the communication design device 22 using the network information input device 21. Alternatively, the contents automatically set by the network information input device 21 based on information on past design history or information collected from outside and input to the communication design device 22 may be stored in the communication requirement storage unit 50 as the time-guaranteed communication requirement table 200 or the bandwidth-guaranteed communication requirement table 210.

[0047] (Method of Setting a Communication Schedule) Fig. 8 is a flowchart illustrating a method of setting a communication schedule in the communication design device according to the first embodiment of the present invention. In the communication design device 22 of this embodiment, the schedule setting unit 51 sets a communication schedule for the in-vehicle network 20 by, for example, executing the process shown in the flowchart of Fig. 8 in response to an instruction from a designer.

[0048] In step S100, a schedule calculation process for time-guaranteed communication is performed. Here, by executing the process shown in the flowchart of Fig. 9, time slots to be assigned to each time-guaranteed application whose communication requirements are defined by the communication requirement information exemplified in Fig. 6 are determined. Details of the process shown in the flowchart of Fig. 9 will be described later.

[0049] In step S101, time slots for bandwidth-guaranteed communication and best-effort communication are determined. Here, the time slots for bandwidth-guaranteed communication and best-effort communication are determined to be the time slots for bandwidth-guaranteed communication and best-effort communication, excluding the time slots for time-guaranteed communication determined in the processing of step S100.

[0050] In step S102, a communication path calculation process for bandwidth-guaranteed communication is performed. Here, by executing the process shown in the flowchart of Fig. 12, the communication path and class of each bandwidth-guaranteed application whose communication requirements are defined by the communication requirement information exemplified in Fig. 7 are determined. Details of the process shown in the flowchart of Fig. 12 will be described later.

[0051] In step S103, a class for best-effort communication is determined. Here, in the time slot determined in the process of step S101, the remaining classes, excluding the classes used for bandwidth-guaranteed communication, are determined as classes for best-effort communication.

[0052] In step S104, it is determined whether the communication design result of the in-vehicle network 20 by the communication design device 22 satisfies the communication requirements of each application represented by the communication requirement information stored in the communication requirement storage unit 50. Here, it is determined whether the delay time and communication bandwidth when each application communicates according to the communication schedule obtained in the processes of steps S100 to S103 satisfy the communication requirements of all applications. As a result, if the communication requirements of all applications are satisfied, the process proceeds to step S105, and if the communication requirements of at least one application are not satisfied, the process proceeds to step S106.

[0053] In step S105, information indicating that the communication design of the in-vehicle network 20 by the communication design device 22 has been successful is output to the network information input device 21. This information is received by the network information input device 21, and by presenting a predetermined message to the network information input device 21 in response to this, it is possible to notify the designer that the communication design of the in-vehicle network 20 has been successful. This makes it possible to prompt the designer to output the obtained design results as network design data 40 from the communication design device 22 to the communication setting device 23.

[0054] In step S106, information indicating that the communication design of the in-vehicle network 20 by the communication design device 22 has failed is output to the network information input device 21. This information is received by the network information input device 21, and by presenting a predetermined message to the network information input device 21 in response to this, it is possible to notify the designer that the communication design of the in-vehicle network 20 has failed. This makes it possible to prompt the designer to review the settings of the communication requirements and the configuration of the in-vehicle network 20.

[0055] After executing the process of step S105 or S106, the communication design device 22 ends the process shown in the flowchart of FIG.

[0056] (Schedule Calculation Process for Time-Guaranteed Communication) FIG. 9 is a flowchart showing the flow of the schedule calculation process for time-guaranteed communication executed in step S100 of FIG.

[0057] In steps S110 to S118, a loop process is performed for each delay requirement of time-guaranteed communication. Here, for example, in the communication requirement information represented by the time-guaranteed communication requirement table 200 shown in FIG. 6, communication data having the same value of the delay requirement 204 are grouped together, thereby grouping time-guaranteed applications by delay requirement. Note that other information related to time-guaranteed communication, such as the communication cycle 203, may also be used for grouping. Then, steps S110 to S118 are executed for each group to perform a schedule calculation process for time-guaranteed communication. As a result, time slots with the same cycle are assigned to multiple time-guaranteed applications having the same delay allowance. In the following, the group of time-guaranteed applications currently subject to the loop process is referred to as the "first group of applications to be processed," and the loop process of steps S110 to S118 will be described.

[0058] After the loop process is started in step S110, the next step S111 is to determine the class to be used for the first group of applications to be processed. Here, one of the currently available classes is selected and determined as the class to be used for the first group of applications to be processed.

[0059] In step S112, the total packet length of all communication data flows of the first application group to be processed that have the same delay requirement is calculated by adding up the values ​​of the packet length 205 of the records corresponding to each time-guaranteed application of the first application group to be processed in the communication requirement information represented by the time-guaranteed communication requirement table 200 of FIG.

[0060] In step S113, the maximum number of hops within the in-vehicle network 20 for communication by the first target application group is calculated from the topology information of the in-vehicle network 20. Here, in the communication requirement information represented by the time-guaranteed communication requirement table 200 of FIG. 6 , the contents of the source 201 and destination 202 of the record corresponding to each time-guaranteed application of the first target application group are used to identify the corresponding communication devices in the in-vehicle network 20. Then, the number of other communication devices that may be passed through when communicating between these communication devices is identified from the topology information of the in-vehicle network 20, and the maximum number among them can be obtained as the maximum number of hops. Note that the topology information of the in-vehicle network 20 is information that represents the connection relationships between the communication devices in the in-vehicle network 20, and is included in network information input from the network information input device 21, for example.

[0061] In step S114, the maximum delay time in communication by the first processing target application group is calculated based on the maximum number of hops calculated in step S113. Here, the delay time at the maximum number of hops can be calculated as the maximum delay time by multiplying the preset delay time per hop by the maximum number of hops calculated in step S113. Note that the delay time calculated here includes the switch delay time (switch processing time, store-and-forward time, etc.) caused by the network switch 13, the transmission delay time of the communication data, etc.

[0062] In step S115, the time slot length for communication by the first group of applications to be processed is calculated based on the sum of the packet lengths calculated in step S112 and the maximum delay time calculated in step S114. Here, the sum of the packet lengths is added to the maximum delay time to calculate the time slot length for communication by the first group of applications to be processed. As a result, the length of the time slot is set based on the sum of the sum of the packet lengths for multiple time-guaranteed applications to which time slots of the same period are assigned, the sum of the switch delay times within the in-vehicle network 20, which are the time required for switch processing by the network switch 13 in the communication device, and the sum of the transmission delay times within the in-vehicle network 20, which are the time required for communication transmission.

[0063] In step S116, a time slot for communication by the first application group to be processed is set for each communication cycle based on the time slot length calculated in step S115. Here, the end time of the time slot determined in the previous loop processing is set as the start time (offset) of the time slot for the current loop processing, and the time obtained by adding the time slot length calculated in step S115 to that time is set as the time slot for communication by the first application group to be processed. This allows the schedule setting unit 51 of this embodiment to set the time slot cycle for multiple time-guaranteed applications included in the first application group to be processed based on the allowable delay times associated with these time-guaranteed applications, and to set the time slot length based on the packet length associated with these time-guaranteed applications. As a result, it is possible to assign time slots for communication performed by each time-guaranteed application in the first application group to be processed.

[0064] In step S117, routing is performed for the first group of applications to be processed. Here, the shortest route for communication by the first group of applications to be processed is identified based on, for example, topology information of the in-vehicle network 20, and routing is performed along this shortest route. Note that, at this time, routing along a route other than the shortest route may be performed so as to distribute the communication load across the entire in-vehicle network 20.

[0065] In step S118, the loop process for the current first group of applications to be processed is terminated. Then, it is determined whether this loop process has been performed for all of the aforementioned groups, in which applications requiring time guarantee are grouped according to delay requirements. If a group for which the loop process has not yet been performed exists, one of the groups is set as the next first group of applications to be processed, and the next loop process is initiated. On the other hand, if the loop process has been performed for all groups, the schedule calculation process for time-guaranteed communication shown in the flowchart of FIG. 9 is terminated.

[0066] In the schedule calculation process for time-guaranteed communications, the above-described process is executed for each of the multiple time-guaranteed applications by the schedule setting unit 51. As a result, the cycle of the communication time slots assigned to each time-guaranteed application is set based on the allowable delay times for the multiple time-guaranteed applications, and the length of the time slot is set based on the packet lengths of the communication data for the multiple time-guaranteed applications.

[0067] 10 is a diagram showing an example of time slots assigned to time-guaranteed applications by the schedule calculation process for time-guaranteed communications described above. Fig. 10 shows an example in which communication data is transmitted from one ECU ("ECU1" in Fig. 10) to another ECU ("ECU2" in Fig. 10) via network switches 13 ("Switch1" and "Switch3" in Fig. 10) provided in ECU1 and ECU2, respectively, and via a network switch 13 ("Switch2" in Fig. 10) of another communication device located between them. The network switches 13 of each ECU are time-synchronized by the TSN function.

[0068] For example, assume that communication data 110, 111, and 112 generated by different time-guaranteed applications have the same delay requirement, and that time slots 100a and 100b are assigned to these communication data at predetermined communication intervals by the schedule calculation process for time-guaranteed communication. In these time slots 100a and 100b, packets of communication data 110-112 are transmitted from ECU1 to ECU2. However, if communication data is output from the time-guaranteed application running on ECU1 at a timing that would prevent it from reaching ECU2 within time slot 100a, such as packet 110c in FIG. 10, the network switch 13 (Switch1) of ECU1 temporarily suspends transmission of the communication data. After that, when time 120 elapses between time slot 100a and the next time slot 110b, communication data 110-112 are continuously transmitted from ECU1 to ECU2.

[0069] In time slot 110b, communication data 110-112 output from the time guarantee application running in ECU1 are assembled into a series of packets by Switch1 in ECU1, and then passed to the time guarantee application running in ECU2 via Switch2 and Switch3. At this time, a transmission delay time 121a and a switch delay time 122a at Switch2 occur between the transmission timing of ECU1 and the transmission timing of Switch2. Similarly, a transmission delay time 121b and a switch delay time 122b at Switch3 are added together between the transmission timing of Switch2 and the reception timing of Switch3. Furthermore, a transmission delay time 121c within ECU2 and a packet length 123, which is the sum of the communication data 110-112, are added together between the reception timing of Switch3 and the delivery timing to the time guarantee application running in ECU2.

[0070] The length of the time slots 110a and 110b (time slot width) is τ i Then, τ i is expressed by the following formula (1). In formula (1), τ Packets represents the total value of packet lengths for time-guaranteed communication flows with the same delay requirement, which corresponds to the packet length 123 in FIG. 10. Proc and τ SF τ represents the sum of the internal processing delay and the store-and-forward delay in each network switch 13 in the in-vehicle network 10, and corresponds to the switch delay times 122a and 122b in FIG. 10. Trans represents the total value of the transmission delay in each link in the in-vehicle network 10, which corresponds to the transmission delay times 121a to 121c in FIG. i = τ Packets +τ Proc +τ Trans +τ SF ...(1)

[0071] The maximum delay time of the time-guaranteed communication flow in the time slots 110a and 110b (the time from when the ECU 1 starts transmitting the head of the packet of the communication data 110 to 112 until the ECU 2 completes receiving the tail of the packet of the communication data 110 to 112) is denoted by d E2E Then, d E2E is expressed by the following formula (2): In formula (2), d Timeslot represents the time from the end of the time slot of the previous period to the start of the time slot of the next period, which corresponds to time 120 in FIG. 10. i represents the period of time-guaranteed communication. E2E = d Timeslot +τ SF +τ Trans +τ Packets +τ Proc =C i -τ i +τ SF +τ Trans +τ Packets +τ Proc =C i ... (2)

[0072] As explained above, various delay times related to the transmission of communication data are added between the start of output in the application and the end of transmission. In the schedule calculation process for time-guaranteed communication explained in the flowchart of Figure 9, these delay times can be taken into consideration when setting time slots 100a and 100b.

[0073] Fig. 11 is a diagram showing an example of the results of a schedule calculation process for time-guaranteed communication. A schedule table 220 shown in Fig. 11 has a record set for each time slot determined by the schedule calculation process for time-guaranteed communication, and each record has data for a period 221, a reference time 222, and a slot length 223. These data represent the settings for each time slot in which time-guaranteed communication is performed.

[0074] (Communication Path Calculation Processing for Bandwidth-Guaranteed Communication) FIG. 12 is a flowchart showing the flow of communication path calculation processing for bandwidth-guaranteed communication executed in step S102 of FIG.

[0075] In step S120, the communication bandwidth of each link available for bandwidth-guaranteed communication is calculated by subtracting the used bandwidth for all time slots calculated by the schedule calculation process for time-guaranteed communication in step S100 from the available bandwidth of all links of the in-vehicle network 20. The available bandwidth of all links of the in-vehicle network 20 is included in the network information input from the network information input device 21, for example.

[0076] In steps S121 to S129, a loop process is executed for each communication flow that requires bandwidth guarantee. Here, for example, one or more bandwidth-guaranteed applications that share a common source and destination are identified from each record in the bandwidth-guaranteed communication requirements table 210 shown in FIG. 7, and communication data from these bandwidth-guaranteed applications is grouped into a series of communication flows. The loop process of steps S121 to S129 is executed for each communication flow set up by grouping one or more bandwidth-guaranteed applications in this way. In the following, the group of applications corresponding to the communication flow that is the target of the current loop process, among the bandwidth-guaranteed applications whose communication requirement information is indicated in the bandwidth-guaranteed communication requirements table 210, will be referred to as a "second group of applications to be processed," and the contents of the loop process of steps S121 to S129 will be explained.

[0077] In the loop process of steps S121 to S129, the loop process of steps S122 to S125 is executed for each communication path available for communication by the second group of applications to be processed. Here, for example, in the communication requirement information represented by the bandwidth-guaranteed communication requirement table 210 shown in FIG. 7, the communication devices of the in-vehicle network 20 corresponding to each of the bandwidth-guaranteed applications belonging to the second group of applications to be processed are identified based on the contents of the sender 211 and destination 212 of the record corresponding to each of the bandwidth-guaranteed applications. Then, a route list is created by listing all of the communication paths of the in-vehicle network 20 connecting these communication devices, and the loop process of steps S122 to S125 is executed for each communication path listed in this route list. Hereinafter, the communication path currently being processed in the loop process will be referred to as the "path to be processed," and the loop process of steps S122 to S125 will be described.

[0078] After starting the loop process in step S122, the next step S123 obtains the available bandwidth and the number of available classes for each link on the target route. Here, the available bandwidth and the number of available classes for each link on the target route can be obtained using, for example, the link usage information described below.

[0079] Fig. 13 is a diagram showing an example of link usage information indicating the bandwidth usage and the number of usage classes of each link used in the processing of step S123 in Fig. 12. The link usage table 230 shown in Fig. 13 has a record set for each link in the in-vehicle network 20, and each record has data on a link 231, a bandwidth usage 232, and a number of usage classes 233. These data represent the bandwidth usage and the number of classes of each link assigned to a communication route set in the previous processing. The link usage table 230 is stored in the communication design device 22, and its contents are updated in step S127, which will be described later.

[0080] 12, in step S123, the available bandwidth and the number of available classes for each link on the target route can be calculated from the link usage information as follows. That is, for each link on the target route, the available bandwidth for each link can be calculated by subtracting the value of the bandwidth used 232 in the link usage table 230 shown in FIG. 13 from the available bandwidth value calculated in step S120. Also, for each link on the target route, the number of available classes for each link on the target route can be calculated by subtracting the value of the number of used classes 233 in the link usage table 230 from the number of classes set in advance.

[0081] In step S124, it is determined whether the available bandwidth and the number of available classes for each link of the target route calculated in step S123 satisfy the communication route usage conditions. Here, the total communication bandwidth (flow bandwidth) required for the communication flow of the second target application group is calculated from the value of the communication bandwidth 213 in the record corresponding to each bandwidth-guaranteed application belonging to the second target application group in the communication requirement information represented by the bandwidth-guaranteed communication requirement table 210 shown in FIG. 7 . If the available bandwidth is equal to or greater than the flow bandwidth and the number of available classes is one or more for all links on the target route, it is determined that the communication route usage conditions are satisfied, and the process proceeds to step S127, terminating the loop processing of steps S122 to S125 for all communication routes. On the other hand, if the available bandwidth is less than the flow bandwidth or the number of available classes is less than one for any link on the target route, it is determined that the communication route usage conditions are not satisfied, and the process proceeds to step S125.

[0082] In step S125, the loop processing of steps S122 to S125 for the current processing target route is terminated. Then, it is determined whether this loop processing has been performed for all communication routes in the route list created in step S122. As a result, if there are communication routes for which the loop processing has not been performed, one of those communication routes is set as the next processing target route, and the next loop processing is started. As a result, a communication route other than the previous one is determined to satisfy the communication route usage conditions in step S124, and the communication load related to the requests of the second processing target application group is distributed among multiple communication routes. On the other hand, if the loop processing has been performed for all communication routes, the loop processing is terminated and the process proceeds to step S126.

[0083] In step S126, a message indicating that the communication path calculation process for the bandwidth-guaranteed communication has failed is output. This message is notified to the designer by being displayed on the network information input device 21, for example. This prompts the designer to review the configuration and communication requirements of the in-vehicle network 20.

[0084] In step S127, the link usage table 230 shown in Fig. 13 is updated. Specifically, records corresponding to each link on the target route that was the target of the immediately preceding loop process are identified in the link usage table 230, and the required bandwidth value used in the determination process in step S124 and 1 are added to the values ​​of the bandwidth in use 232 and the number of classes in use 233 of these records. This allows the link usage table 230 to be updated to reflect the results of the communication route setting performed in the next step S128.

[0085] In step S128, the communication paths and classes for which it was determined in step S124 that the available bandwidth and number of available classes for each link satisfy the usage conditions are set as the communication paths and classes to be used in communication for each bandwidth-guaranteed application belonging to the second group of applications to be processed, and information indicating these settings is output as the processing result of step S102 in FIG.

[0086] After execution of step S126 or S128, in step S129, the loop processing of steps S121 to S129 for the current second group of applications to be processed is terminated. Then, it is determined whether this loop processing has been performed for all of the communication flows set in step S121. If, as a result, there is a communication flow for which loop processing has not yet been performed, one of the remaining communication flows is selected, and the group of bandwidth-guaranteed applications corresponding to that communication flow is set as the next second group of applications to be processed, and the next loop processing is started. On the other hand, if loop processing has been performed for all communication flows, the communication path calculation processing for bandwidth-guaranteed communication shown in the flowchart of FIG. 12 is terminated.

[0087] In the communication path calculation process for bandwidth-guaranteed communication, the above-described process is executed for each of the multiple bandwidth-guaranteed applications by scheduler 51. As a result, the multiple bandwidth-guaranteed applications are divided into one or more groups for each communication flow, and a communication path is set and a class is assigned to each group according to the communication bandwidth.

[0088] In the communication path calculation process for bandwidth-guaranteed communication described above, the scheduler 51 may determine the communication path taking into consideration the location of communication devices through which the communication flow passes within the in-vehicle network 20. For example, in the in-vehicle network 20 based on the zone architecture shown in FIG. 1B, the communication load may be distributed by changing the communication path between the zone ECUs 9a and 9b, which are communication devices located at the front of the vehicle 1, for at least some of the communications related to requests from bandwidth-guaranteed applications grouped by communication flow, to a communication path between the zone ECUs 9c and 9d, which are communication devices located at the rear of the vehicle. Alternatively, the communication load within the in-vehicle network 20 may be distributed by setting any communication path for each communication flow of a bandwidth-guaranteed application.

[0089] (Network Design Data) FIG. 14 is a diagram showing an example of network design data 40 output from the communication design device 22 to the communication setup device 23 when the communication design of the in-vehicle network 20 by the communication design device 22 is completed.

[0090] The network design data 40 includes, for example, a schedule table 220 shown in Fig. 14(a) and a routing table 240 shown in Fig. 14(b). The schedule table 220 represents the result of the schedule calculation process for time-guaranteed communication executed in step S100 of Fig. 8, and is the same as the example shown in Fig. 11. The routing table 240 represents the result of the communication path calculation process for bandwidth-guaranteed communication executed in step S102 of Fig. 8, and has records set for each type of communication data by a bandwidth-guaranteed application executed within the in-vehicle network 20.

[0091] Each record in the routing table 240 has data on a source 241, a destination 242, and a communication path 243. Information representing the source and destination communication devices of each communication data is stored in the source 241 and the destination 242, respectively. Information representing the communication path of each communication data, on the communication path of each bandwidth guaranteed application output in step S128 of FIG. 12, is stored in the communication path 243.

[0092] According to the first embodiment of the present invention described above, the following advantageous effects are achieved.

[0093] (1) The communication design device 22 is a device for performing communication design for an in-vehicle network 20 to which multiple communication devices are connected and which communicate with each other in accordance with application requirements. The communication design device 22 includes a communication requirement storage unit 50 that stores communication requirement information (a time-guaranteed communication requirement table 200 and a bandwidth-guaranteed communication requirement table 210) that indicates an allowable delay time indicating the length of communication delay time allowed for each time-guaranteed application and a packet length of communication data specified for each time-guaranteed application, and a schedule setting unit 51 that assigns communication time slots to each application. The schedule setting unit 51 sets the time slot period based on the allowable delay times associated with the multiple time-guaranteed applications and sets the time slot length based on the packet lengths associated with the multiple time-guaranteed applications (steps S115 and S116). This configuration enables an optimal communication design to be realized for a network in which communication is performed in accordance with the requirements of various applications with different communication requirements.

[0094] (2) The schedule setting unit 51 executes a schedule calculation process for time-guaranteed communication for the time-guaranteed application (step S100). In this process, time slots with the same cycle are assigned to multiple time-guaranteed applications with the same delay tolerance. This allows time slots to be assigned to each time-guaranteed application so that communication can be reliably carried out within the specified delay tolerance.

[0095] (3) In addition, in the schedule calculation process for time-guaranteed communication, the schedule setting unit 51 sets the length of the time slot based on the packet lengths of multiple time-guaranteed applications to which time slots with the same period are assigned (step S115). Specifically, the schedule setting unit 51 sets the length of the time slot based on the sum of the total packet lengths of the multiple time-guaranteed applications to which time slots with the same period are assigned, the total switch delay time within the in-vehicle network 20, which is the time required for switch processing in each communication device of the in-vehicle network 20, and the total transmission delay time within the network, which is the time required for communication transmission. This makes it possible to appropriately set the length of the time slot used for communication related to the time-guaranteed application.

[0096] (4) The applications executed within the in-vehicle network 20 include a first group of applications whose communications require time guarantee and a second group of applications whose communications require bandwidth guarantee. The scheduler 51 determines one or more time slots to be assigned to the first group of applications according to the allowable delay time of each time-guaranteed application belonging to the first group of applications (step S100). After determining the time slots to be assigned to the first group of applications, the scheduler 51 determines one or more time slots to be assigned to the second group of applications (step S102). This ensures that time slots that satisfy the respective communication requirements can be assigned to each time-guaranteed application belonging to the first group of applications and each bandwidth-guaranteed application belonging to the second group of applications.

[0097] (5) One or more classes that guarantee a predetermined communication bandwidth are assigned to the time slots assigned to the second application group. The scheduler 51 divides the bandwidth-guaranteed applications belonging to the second application group into one or more groups and assigns a class to each group according to the communication bandwidth. Specifically, the scheduler 51 sets groups of bandwidth-guaranteed applications that share a common source and destination according to the communication path in the in-vehicle network 20 (step S121), and for each group, calculates the available bandwidth and the number of available classes for each link included in the communication path (step S123). Then, if, for any link on the communication path, the total communication bandwidth of the bandwidth-guaranteed applications belonging to the same group exceeds the available bandwidth or the total number of communication classes of the bandwidth-guaranteed applications belonging to the same group exceeds the number of available classes (step S124: No), the scheduler 51 executes the loop process of steps S122 to S125 for another communication path, thereby distributing the communication load related to the requests of the second application group across multiple communication paths. This allows bandwidth-guaranteed communication to be achieved throughout the in-vehicle network 20.

[0098] Second Embodiment Next, a communication design device according to a second embodiment of the present invention will be described below with reference to Figures 15 to 19. In this embodiment, an example of a communication design device will be described in which, when a change in communication control is required due to an application update for the in-vehicle network 20 described in Figure 1, time slots and communication paths are redesigned and the design results are reflected in the in-vehicle network 20.

[0099] 15 is a diagram showing an example of the configuration of a system including a communication design device according to the second embodiment of the present invention. The system shown in Fig. 15 is a system that is mounted on a vehicle 1 and used, and is configured to include the in-vehicle network 20 and communication design device 22 described in the first embodiment, and an application management device 24.

[0100] The application management device 24 receives update data transmitted from an OTA (Over The Air) server 32 installed on the cloud, and uses this update data to update applications executed in the in-vehicle network 20. In this embodiment, the communication design device 22 determines whether or not a change in communication control is required due to the application update, based on the update data output from the application management device 24, and if it determines that a change in communication control is required, redesigns the time slots and communication paths and outputs the results to the in-vehicle network 20. By reflecting the results of the redesign of the time slots and communication paths by the communication design device 22, the in-vehicle network 20 can continue communication between the communication devices even if a change in communication control is required due to the application update.

[0101] (Configuration of communication design device) Fig. 16 is a functional block diagram showing the configuration of a communication design device according to the second embodiment of the present invention. As shown in Fig. 16, the communication design device 22 is configured to further include the functional blocks of a network information collection unit 53 and a schedule storage unit 54 in addition to the communication requirement storage unit 50, schedule setting unit 51, and setting output unit 52 described in the first embodiment, for example. These functional blocks in the communication design device 22 are realized, for example, by a computer executing a predetermined program.

[0102] The network information collection unit 53 collects network information including the connection relationships and operation states of each communication device in the in-vehicle network 20, and updates the communication requirement information stored in the communication requirement storage unit 50 as needed based on the collected network information. For example, if the most recently collected network information has changed compared to previously collected network information, the communication requirement information stored in the communication requirement storage unit 50 is updated to reflect the changes.

[0103] In this embodiment, the communication requirement information stored in the communication requirement storage unit 50 is updated in accordance with the contents of update data when update data is input from the application management device 24, in addition to when network information is changed as described above. Specifically, when a new application is added to the in-vehicle network 20, when an application is deleted, when the allowable communication delay time or packet length changes due to an application update, or the like, update data is input from the application management device 24 to the communication requirement storage unit 50, and the communication requirement information is updated.

[0104] The schedule storage unit 54 stores a schedule for communication by each application of the in-vehicle network 20. That is, time slot information relating to time slots for time-guaranteed communication by the time-guaranteed application, such as information on the communication cycle, timing, slot length, etc., and information on the communication path for bandwidth-guaranteed communication by the bandwidth-guaranteed application, are stored in the schedule storage unit 54. This information has a data structure similar to that of the network design data 40 in FIG. 14 , which is exemplified in the first embodiment, for example.

[0105] In this embodiment, when it is determined that a change in communication control is necessary due to an application update, the schedule setting unit 51 resets the communication schedule using information stored in the schedule storage unit 54. As a result, time slots and communication paths are redesigned in accordance with the contents of the application update, and are reflected in the communication control of the in-vehicle network 20.

[0106] (Communication Schedule Resetting Planning Method) Fig. 17 is a flowchart illustrating a communication schedule resetting method in a communication design device according to the second embodiment of the present invention. In the communication design device 22 of this embodiment, when update data is input from the application management device 24, for example, the schedule setting unit 51 executes the process shown in the flowchart of Fig. 17 in response to the input, thereby resetting the communication schedule of the in-vehicle network 20.

[0107] In step S200, it is determined whether or not redesign of time-guaranteed communication is necessary. Here, for example, if any of the following conditions (a1) to (d1) is met, it is determined that redesign of time-guaranteed communication is necessary and the process proceeds to step S201; if none of the conditions is met, it is determined that redesign of time-guaranteed communication is unnecessary and the process proceeds to step S204. Note that these conditions are merely examples, and other conditions may be used to make the determination in step S200. Alternatively, condition (b1) does not degrade the communication performance of time-guaranteed applications that are not deleted, so it can be determined that redesign of time-guaranteed communication is unnecessary. (a1) Addition of a time-guaranteed application (b1) Deletion of a time-guaranteed application (c1) Change in the communication allowable time or packet length of a time-guaranteed application (d1) Change in network information

[0108] In step S201, a schedule recalculation process for time-guaranteed communication is performed. Here, the time slots to be assigned to each time-guaranteed application are re-determined by executing the process shown in the flowchart of Fig. 18. Details of the process shown in the flowchart of Fig. 18 will be described later.

[0109] In step S202, the time slots for bandwidth-guaranteed communication and best-effort communication are redetermined. Here, the time slots for bandwidth-guaranteed communication and best-effort communication are redetermined for the period excluding the time slots for time-guaranteed communication redetermined in the processing of step S201.

[0110] In step S203, it is determined whether or not there is a link whose bandwidth is overflowing due to bandwidth-guaranteed communication in the time slot redetermined in step S202. For example, the available bandwidth for each link in the redetermined time slot is calculated, and this available bandwidth is compared with the bandwidth used for each link in the current communication schedule by the bandwidth-guaranteed application. If the available bandwidth for all links is equal to or greater than the used bandwidth, it is determined that no link has bandwidth overflow, and the process proceeds to step S205. On the other hand, if the available bandwidth for any link is less than the used bandwidth, it is determined that a link has bandwidth overflow, and the process proceeds to step S204. Note that information on the bandwidth used for each link in the current communication schedule by the bandwidth-guaranteed application is stored, for example, in the schedule storage unit 54.

[0111] In step S204, the redesign of the bandwidth-guaranteed communication is set to "necessary." For example, by switching predetermined flag information regarding the redesign of the bandwidth-guaranteed communication from "invalid" to "valid," the communication design device 22 executes the process of step S206, which will be described later.

[0112] In step S205, it is determined whether redesign of the bandwidth-guaranteed communication is necessary. Here, for example, if the redesign of the bandwidth-guaranteed communication is set to "necessary" in step S204, or if any of the following conditions (a2) to (d2) is met, it is determined that redesign of the bandwidth-guaranteed communication is necessary and the process proceeds to step S206; otherwise, it is determined that redesign of the bandwidth-guaranteed communication is not necessary and the process shown in the flowchart of FIG. 8 is terminated. Note that these conditions are merely examples, and the determination in step S205 may be made using other conditions. Alternatively, condition (b2) does not degrade the communication performance of the bandwidth-guaranteed application that is not deleted, so it can be determined that redesign of the bandwidth-guaranteed communication is not necessary. (a2) Addition of a bandwidth-guaranteed application (b2) Deletion of a bandwidth-guaranteed application (c2) Change in the communication bandwidth of the bandwidth-guaranteed application (d2) Change in network information

[0113] In step S206, a communication path recalculation process for bandwidth-guaranteed communication is performed. Here, the communication path and class allocation for each bandwidth-guaranteed application are re-determined by executing the process shown in the flowchart of Fig. 19. Details of the process shown in the flowchart of Fig. 19 will be described later.

[0114] After executing the process of step S206, the communication design device 22 ends the process shown in the flowchart of FIG.

[0115] (Schedule recalculation process for time-guaranteed communication) Figure 18 is a flowchart showing the flow of the schedule recalculation process for time-guaranteed communication executed in step S201 of Figure 17. In the flowchart of Figure 18, parts that perform the same processes as the schedule calculation process for time-guaranteed communication shown in the flowchart of Figure 9 explained in the first embodiment are assigned common step numbers. Unless particularly necessary, explanations of the processes that have common step numbers to Figure 9 will be omitted below.

[0116] 9 described in the first embodiment, loop processing is performed for each delay requirement of time-guaranteed communication. After loop processing is started in step S110, in the next step S210, time slot information representing the current communication schedule of the first group of applications to be processed is obtained from the schedule storage unit 54.

[0117] In step S211, the current communication schedule represented by the time slot information acquired in step S210 is compared with the update data input from the application management device 24 to determine whether there has been a change in the communication schedule for the first group of applications to be processed. If a change in the communication schedule is necessary, for example, if the update data adds a new time-guaranteed application whose communication requirements differ from those of the other time-guaranteed applications, thereby requiring the addition of a time slot for communication by that time-guaranteed application, the process proceeds to step S111. In this case, the same processing as that shown in the flowchart of FIG. 9 described in the first embodiment is performed for the first group of applications to be processed. On the other hand, if no change in the communication schedule is necessary, the process proceeds to step S118, where the loop processing for the current first group of applications to be processed is terminated.

[0118] In the schedule recalculation process for time-guaranteed communications, the above-described process is executed for each of the multiple time-guaranteed applications by the schedule setting unit 51. As a result, the cycle of the communication time slots assigned to each time-guaranteed application is reset on the vehicle 1 in accordance with the communication requirements of the updated time-guaranteed applications, and the length of the time slot is reset on the vehicle 1 based on the packet length of the communication data related to the multiple time-guaranteed applications.

[0119] (Communication Path Recalculation Processing for Bandwidth-Guaranteed Communication) FIG. 19 is a flowchart showing the flow of communication path recalculation processing for bandwidth-guaranteed communication, which is executed in step S206 of FIG.

[0120] In step S220, it is determined whether or not the application update content represented by the update data input from the application management device 24 is a change only to time-guaranteed communication, and whether or not there is a change to bandwidth-guaranteed communication. If there is no change to bandwidth-guaranteed communication, the process proceeds to step S221. If there is a change, it is determined that the communication path for bandwidth-guaranteed communication needs to be recalculated, and the process proceeds to step S102.

[0121] In step S221, it is determined whether there is a link where the total bandwidth of bandwidth-guaranteed communication exceeds the available bandwidth. If there is a link in the in-vehicle network 20 where the available bandwidth has decreased due to a change in time-guaranteed communication and the available bandwidth after the decrease is less than the total bandwidth of bandwidth-guaranteed communication, it is determined that the communication path for bandwidth-guaranteed communication needs to be recalculated, and the process proceeds to step S102. On the other hand, if there is no such link, it is determined that there is no need to recalculate the communication path for bandwidth-guaranteed communication, and the process shown in the flowchart of FIG. 19 ends.

[0122] If the process proceeds from step S220 or S221 to step S102, the process performs the same communication path calculation process for bandwidth-guaranteed communication as described in the first embodiment. That is, the process shown in the flowchart of Fig. 12 is performed to determine the communication path and class for each bandwidth-guaranteed application. After the process of step S102 is performed, the process shown in the flowchart of Fig. 19 ends.

[0123] In the communication path recalculation process for bandwidth-guaranteed communication, the above-described processes are executed by the schedule setting unit 51. As a result, the communication path is reconfigured and classes are reassigned in accordance with the communication requirements of the updated bandwidth-guaranteed application.

[0124] According to the second embodiment of the present invention described above, the communication design device 22 further includes a network information collection unit 53 that collects network information including the connection relationships and operation states of communication devices in the in-vehicle network 20, and a schedule storage unit 54 that stores time slot information related to the time slots set by the schedule setting unit 51. When at least one of the following conditions is met (step S200: Yes): a new time guarantee application is added to the in-vehicle network 20; a time guarantee application is deleted from the in-vehicle network 20; the allowable delay time or packet length has changed; or the network information collected by the network information collection unit 53 has changed, the schedule setting unit 51 resets the period or length of the time slot based on the time slot information stored in the schedule storage unit 54 (steps S115 and S116). This allows for immediate response when a change in communication control is required due to an application update in the in-vehicle network 20.

[0125] [Third Embodiment] Next, a communication design device according to a third embodiment of the present invention will be described below with reference to Fig. 20. In this embodiment, an example of a communication design device will be described, which monitors the communication status of the in-vehicle network 20 described in Fig. 1, and if there is an application that does not satisfy the desired communication performance requirements, redesigns the time slots and communication paths, and reflects the design results in the in-vehicle network 20.

[0126] (Configuration of the communication design device) Fig. 20 is a functional block diagram showing the configuration of a communication design device according to a third embodiment of the present invention. As shown in Fig. 20, the communication design device 22 is configured to include, for example, the communication requirement storage unit 50, schedule setting unit 51, and setting output unit 52 described in the first embodiment, the network information collection unit 53, and schedule storage unit 54 described in the second embodiment, as well as the functional blocks of a communication performance monitoring unit 55. These functional blocks in the communication design device 22 are realized, for example, by a computer executing a predetermined program.

[0127] The communication performance monitoring unit 55 monitors, for each application, whether or not communication performance requirements, including the allowable delay time, are met among the communication requirements of each application executed on the in-vehicle network 20. If there is an application that does not satisfy the communication performance requirements, the communication performance monitoring unit 55 identifies the application and outputs the result to the schedule setting unit 51.

[0128] In this embodiment, the schedule setting unit 51 resets the communication schedule of the in-vehicle network 20 not only when the conditions described in the second embodiment are satisfied, but also when the communication performance monitoring unit 55 identifies an application that does not satisfy the communication performance requirements. In this case, the schedule setting unit 51 can reset the communication schedule of the in-vehicle network 20 in the same manner as in the second embodiment, for example, by executing the process shown in the flowchart of Fig. 17 described in the second embodiment.

[0129] According to the third embodiment of the present invention described above, the communication design device 22 further includes a network information collection unit 53 that collects network information including connection relationships and operation states of communication devices in the in-vehicle network 20, a communication performance monitoring unit 55 that monitors, for each application, whether communication performance requirements, including an allowable delay time, among the communication requirements of the applications, are met, and identifies the application if the application does not satisfy the communication performance requirements, and a schedule storage unit 54 that stores time slot information regarding the time slots set by the schedule setting unit 51. The schedule setting unit 51 resets the period or length of the time slot based on the time slot information stored in the schedule storage unit 54 when at least one of the following conditions is met: a new time-guaranteed application is added to the in-vehicle network 20; a time-guaranteed application is deleted from the in-vehicle network 20; the allowable delay time or packet length has changed; the network information collected by the network information collection unit 53 has changed; or the communication performance monitoring unit 55 has identified an application that does not satisfy the communication performance requirements. This configuration makes it possible to immediately address an application in the in-vehicle network 20 that does not satisfy the desired communication performance requirements.

[0130] The present invention is not limited to the various embodiments described above, and includes various modifications. For example, the above-described embodiments have been specifically described to clearly explain the present invention, and are not necessarily limited to those having all of the described configurations. Furthermore, part of the configuration of one embodiment can be replaced with part of the configuration of another embodiment. Furthermore, the configuration of another embodiment can be added to the configuration of one embodiment. Furthermore, part of the configuration of each embodiment can be deleted, and part of another configuration can be added or replaced with part of another configuration.

[0131] The present invention is not limited to the above-described embodiment, and various modifications are possible without departing from the spirit of the present invention.

[0132] REFERENCE SIGNS LIST 1 Vehicle 20 In-vehicle network 21 Network information input device 22 Communication design device 23 Communication setting device 24 Application management device 50 Communication requirement storage unit 51 Schedule setting unit 52 Setting output unit 53 Network information collection unit 54 Schedule storage unit 55 Communication performance monitoring unit

Claims

1. A communication design device for a network to which a plurality of communication devices are connected and which communicate with each other in accordance with application requirements, comprising: a communication requirements memory unit which stores an allowable delay time indicating the length of the communication delay time allowable for each application and a packet length of communication data determined for each application; and a schedule setting unit which allocates a time slot for the communication for each application, wherein the schedule setting unit sets the period of the time slot based on the allowable delay time for each of the applications, and sets the length of the time slot based on the packet length for each of the applications.

2. A communication design device according to claim 1, wherein said schedule setting unit assigns said time slots of the same cycle to a plurality of said applications having the same said delay allowable time.

3. A communication design device according to claim 2, wherein the schedule setting unit sets the length of the time slot based on the packet lengths relating to a plurality of applications to which the time slots of the same period are assigned.

4. A communication design device as described in claim 3, wherein the schedule setting unit sets the length of the time slot based on the sum of the total value of the packet lengths relating to multiple applications to which the time slots of the same period are assigned, the total value of the switch delay time within the network, which is the time required for switch processing in the communication device, and the total value of the transmission delay time within the network, which is the time required for transmission of the communication.

5. A communication design device as described in claim 1, wherein the applications include a first group of applications that perform communication requiring time guarantee and a second group of applications that perform communication requiring bandwidth guarantee, and the schedule setting unit determines one or more of the time slots to be assigned to the first group of applications in accordance with the allowable delay time of each application belonging to the first group of applications, and after determining the time slots to be assigned to the first group of applications, determines one or more of the time slots to be assigned to the second group of applications.

6. A communication design device as described in claim 5, wherein one or more classes that guarantee a predetermined communication bandwidth are set for the time slots assigned to the second application group, and the schedule setting unit divides each application belonging to the second application group into one or more groups and assigns the class to each group according to the communication bandwidth.

7. A communication design device as described in claim 6, wherein the schedule setting unit sets the groups according to communication routes in the network, calculates the available bandwidth and number of available classes of each link included in the communication route for each group, and distributes the communication load related to the requests of the second group of applications to multiple communication routes when, for any link on the communication route, the total bandwidth of the communications of each application belonging to the same group exceeds the available bandwidth or the total number of classes of the communications of each application belonging to the same group exceeds the number of available classes.

8. A communication design device as described in claim 7, wherein the network is an in-vehicle network in which the multiple communication devices mounted on a vehicle communicate with each other, the multiple communication devices are arranged at least at the front and rear of the vehicle, and the schedule setting unit distributes the communication load by changing the communication path for at least a portion of the communications related to requests from the second application group from a communication path that passes between the communication devices arranged at the front of the vehicle to a communication path that passes between the communication devices arranged at the rear of the vehicle.

9. A communication design device as described in claim 1, further comprising: a network information collection unit which collects network information including connection relationships and operating states of the communication devices in the network; and a schedule storage unit which stores time slot information regarding the time slots set by the schedule setting unit, wherein the schedule setting unit re-sets the period or length of the time slot based on the time slot information stored in the schedule storage unit when at least one of the following conditions is satisfied: when a new application is added to the network, when the application is deleted from the network, when the allowable delay time or the packet length has changed, and when the network information collected by the network information collection unit has changed.

10. A communication design device as recited in claim 1, further comprising: a network information collecting unit that collects network information including connection relationships and operating states of said communication devices in said network; a communication performance monitoring unit that monitors, for each of said applications, the fulfillment status of communication performance requirements including the delay allowable time among the communication requirements of said applications, and identifies any application that does not satisfy the communication performance requirements; and a schedule storage unit that stores time slot information regarding the time slots set by said schedule setting unit, wherein said schedule setting unit re-sets the period or length of said time slot based on the time slot information stored in said schedule storage unit when at least one of the following conditions is satisfied: a new application is added to the network, an application is deleted from the network, the delay allowable time or the packet length has changed, the network information collected by said network information collecting unit has changed, and the communication performance monitoring unit has identified an application that does not satisfy the communication performance requirements.

11. A communication design device as claimed in claim 1, wherein the network is mounted on a vehicle, and the device receives as input information relating to communication requirements of the application relating to control of the vehicle, and outputs setting information relating to communication control of the network.

12. A communication design device as described in claim 1, which is mounted in a vehicle together with the network, and in which a plurality of the communication devices mounted in the vehicle communicate with each other in the network in accordance with requests from a plurality of the applications related to the control of the vehicle, and which reconfigures the communication schedule of the network within the vehicle.

13. A method of communication design for a network to which a plurality of communication devices are connected and which communicate with each other in accordance with application requests, comprising: storing in a computer an allowable delay time indicating the length of the communication delay time allowable for each application and a packet length of communication data determined for each application; and allocating a time slot for the communication for each application by the computer; and in allocating the time slot, setting a period of the time slot based on the allowable delay time for each of the plurality of applications; and setting the length of the time slot based on the packet length for each of the plurality of applications.

Images