Communication design device and communication design method

Abstract

A communication design device that performs communication design of a network to which a plurality of communication devices that communicate with each other in response to a request of an application are connected, the communication design device being provided with: a communication requirement storage unit that stores communication requirements; a storage unit that stores a delay permission time indicating the length of the delay time of the communication permitted by each of the applications, and a packet length of the communication data determined for each of the applications; and a schedule setting unit that allocates a time slot for the communication for each of the applications, the schedule setting unit setting a period of the time slot in accordance with the delay allowance time of the plurality of applications, and setting a length of the time slot in accordance with the packet length of the plurality of applications.

Description

Technical Field

[0001] The present invention relates to a device and method for performing communication design on a network. Background Art

[0002] Conventional communication networks, such as those comprised of multiple electronic control units (ECUs) installed in vehicles, carry out communications for multiple applications in parallel, with communication requirements such as delay tolerance varying for each application. In such communication networks, reliable communication requirements for all applications must be guaranteed, making communication design crucial to setting appropriate communication timing for each application.

[0003] As a technology for ensuring the real-time performance of communication data in a network, one example is Time-Sensitive Networking (TSN). TSN is defined as a communication method that extends standard Ethernet (registered trademark) to achieve real-time performance in Ethernet communications. The TSN standard includes a time synchronization method in the network (IEEE 802.1AS), a method for guaranteeing transmission bandwidth using a credit-based shaper (IEEE 802.1Qav), and a method for performing communication in each time slot pre-set for the synchronized time (IEEE 802.1Qbv).

[0004] In recent years, methods have been proposed that consider the communication requirements that vary by application as an optimization problem and achieve optimal communication design by solving this problem. For example, Patent Document 1 describes a wireless communication method that uses time slots commonly defined based on information about all devices included in the wireless communication system, enabling multiple wireless systems to use a single channel in a time-division manner. Furthermore, a counter value, expressed as an integer value in units of time slot length, is set for the amount of communication to be transmitted by each communication device, taking into account transmission timing and allowable delay. The amount of communication to be transmitted in each time slot is determined based on this counter value. This wireless communication method allows for a simple solution to the combinatorial optimization problem of determining when to transmit each time slot. Therefore, even in a confined space where multiple wireless communication devices are present, it is possible to appropriately control the timing of communication transmission.

[0005] Prior art literature

[0006] Patent Literature

[0007] Patent Document 1: Japanese Patent Application Laid-Open No. 2020-155857 Summary of the Invention

[0008] Problems to be solved by the invention

[0009] The method described in Patent Document 1 requires pre-definition of time slots without considering the communication requirements of each application. This makes it difficult to set an appropriate time slot width corresponding to the communication requirements that differ for each application, resulting in a problem in which an optimal communication design cannot be achieved.

[0010] Therefore, an object of the present invention is to provide a technology that can realize an optimal communication design for a network that performs communication in accordance with requests from various applications having different communication requirements.

[0011] Means for solving problems

[0012] The communication design device of the present invention performs communication design for a network, which is connected to a plurality of communication devices, and the plurality of communication devices communicate with each other according to the request of an application, wherein the communication design device comprises: a communication requirement storage unit, which stores a delay allowance time indicating the length of the delay time of the communication allowed for each of the applications, and a packet length of the communication data determined for each of the applications; and a scheduling setting unit, which allocates a time slot for the communication for each of the applications, the scheduling setting unit setting a period of the time slot according to the delay allowance time of the plurality of applications, and setting a length of the time slot according to the packet length of the plurality of applications.

[0013] The communication design method of the present invention is a method for performing communication design on a network, wherein the network is connected to a plurality of communication devices, and the plurality of communication devices communicate with each other according to the request of an application. In the communication design method, a delay allowance time indicating the length of the delay time of the communication allowed for each of the applications and a packet length of the communication data determined for each of the applications are stored in a computer, and the computer allocates a time slot for the communication to each of the applications. In the allocation of the time slot, the period of the time slot is set according to the delay allowance time of the plurality of applications, and the length of the time slot is set according to the packet length of the plurality of applications.

[0014] Effects of the Invention

[0015] According to the present invention, it is possible to provide a technology that can realize an optimal communication design for a network that performs communication in accordance with requests from various applications having different communication requirements. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 This is a diagram showing an example of a network in which the communication design apparatus of the present invention performs communication design.

[0017] Figure 2 This is a diagram showing a configuration example of each communication device in an in-vehicle network.

[0018] Figure 3FIG. 1 is a diagram showing a structure example of a system including a communication design device of a first embodiment of the present application.

[0019] Figure 4 FIG. 2 is a functional block diagram showing a structure of the communication design device of the first embodiment of the present application.

[0020] Figure 5 FIG. 3 is a diagram showing an example of communication scheduling of an in-vehicle network.

[0021] Figure 6 FIG. 4 is a diagram showing an example of a time guarantee communication requirement table.

[0022] Figure 7 FIG. 5 is a diagram showing an example of a bandwidth guarantee communication requirement table.

[0023] Figure 8 FIG. 6 is a flowchart explaining a setting method of communication scheduling in the communication design device of the first embodiment of the present application.

[0024] Figure 9 FIG. 7 is a flowchart showing a flow of a scheduling calculation process of time guarantee communication.

[0025] Figure 10 FIG. 8 is a diagram showing an example of a time slot allocated to a time guarantee application by the scheduling calculation process of time guarantee communication.

[0026] Figure 11 FIG. 9 is a diagram showing an example of a result of the scheduling calculation process of time guarantee communication.

[0027] Figure 12 FIG. 10 is a flowchart showing a flow of a communication path calculation process of bandwidth guarantee communication.

[0028] Figure 13 FIG. 11 is a diagram showing an example of link usage information.

[0029] Figure 14 FIG. 12 is a diagram showing an example of network design data.

[0030] Figure 15 FIG. 13 is a diagram showing a structure example of a system including a communication design device of a second embodiment of the present application.

[0031] Figure 16 FIG. 14 is a functional block diagram showing a structure of the communication design device of the second embodiment of the present application.

[0032] Figure 17 FIG. 15 is a flowchart showing a re-setting method of communication scheduling in the communication design device of the second embodiment of the present application.

[0033] Figure 18is a flowchart showing a flow of a scheduling recalculation process of time-guaranteed communication.

[0034] Figure 19 is a flowchart showing a flow of a communication path recalculation process of bandwidth-guaranteed communication.

[0035] Figure 20 is a functional block diagram showing a structure of a communication design device of a third embodiment of the present application. DETAILED DESCRIPTION

[0036] Hereinafter, a communication design device of the present application will be described with reference to the drawings.

[0037] (Network structure)

[0038] Figure 1 is a diagram showing a structure example of an in-vehicle network used in a vehicle, as an example of a network on which a communication design is performed by the communication design device of the present application. In Figure 1 , (a) shows a structure example of an in-vehicle network based on a domain architecture, and (b) shows a structure example of an in-vehicle network based on a zone architecture.

[0039] Figure 1 The in-vehicle networks 20 shown in (a) and (b) are mounted on a vehicle 1, and perform communication based on various applications utilized at a runtime of the vehicle 1. In Figure 1 the structure example of the domain architecture shown in (a), the in-vehicle network 20 is constituted by the gateway 2, a plurality of domain ECUs 3 combined by a domain, sensors 4, and actuators 5, a TCU (Telematics Control Unit) 7, which are connected to each other.

[0040] The domain ECUs 3 respectively execute prescribed applications, and transmit and receive various signals between the sensors 4 and the actuators 5 connected via signal lines 6, and perform communication with each other in accordance with a request of the application executed by each of the domain ECUs 3 via the gateway 2. The domain ECUs 3 are constituted, for example, by a domain ECU 3a that executes an application related to an ADAS (Advanced Driver Assistance System) of the vehicle 1, a domain ECU 3b that executes an application related to a travel control of the vehicle 1, a domain ECU 3c that executes an application related to an electrical installation of the vehicle 1, a domain ECU 3d that executes an application related to an infotainment device (navigation device, audio device, etc.) mounted on the vehicle 1, and the like. In addition, a domain ECU 3 that executes an application other than the above can be further included, and the domain ECUs 3a to 3d can be replaced.

[0041] The sensors 4a to 4d and the actuators 5a to 5d are connected to the domain ECUs 3a to 3d via signal lines 6a to 6d, respectively. The domain ECUs 3a to 3d are capable of controlling the actuators 5a to 5d, respectively, based on sensor signals received from the sensors 4a to 4d, and are capable of mutually transmitting and receiving communication data related to the sensor signals of the sensors 4a to 4d, communication data related to the control of the actuators 5a to 5d, and the like for the control of the actuators 5a to 5d, via the gateway 2.

[0042] The TCU 7 is a device that performs wireless communication with a prescribed communication object (for example, a vehicle regulation device that performs regulation of a plurality of vehicles including the vehicle 1, another vehicle existing in the surroundings of the vehicle 1). The TCU 7 is connected to the domain ECUs 3a to 3d via the gateway 2. By using this TCU 7, Figure 1 The in-vehicle network 20 of (a) is capable of transmitting communication data transmitted and received among the domain ECUs 3a to 3d to a communication object, or providing the domain ECUs 3a to 3d with communication data received from a communication object.

[0043] 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, the TCU 7 are capable of mutually communicating by way of the gateway 2.

[0044] In the structure example of the zone architecture shown in (b), Figure 1 In the structure example of the zone architecture shown in (b),

[0045] The zone ECUs 9 respectively execute prescribed applications, transmit and receive various signals between the sensors 4 and the actuators 5 arranged in each zone within the vehicle 1, and mutually communicate in accordance with the requests of the applications each of which is executed, via the central ECU 8, the shared bus 10. The zone ECUs 9 are configured, for example, to include zone ECUs 9a and 9b arranged on the right and left sides in front of the vehicle 1 and executing prescribed applications, zone ECUs 9c and 9d arranged on the right and left sides in the rear of the vehicle 1 and executing prescribed applications, and the like. Further, zone ECUs 9 arranged at other locations can also be included, and the zone ECUs 9a to 9d can also be replaced.

[0046] The sensors 4a to 4d and the actuators 5a to 5d are connected to the zone ECUs 9a to 9d via signal lines, communication buses, respectively. The zone ECUs 9a to 9d are capable of mutually transmitting and receiving communication data related to the sensor signals of the sensors 4a to 4d, communication data related to the control of the actuators 5a to 5d, and the like for the control of the actuators 5a to 5d, via the central ECU 8, the shared bus 10. Figure 1The domain ECUs 3a to 3d of (a) are each capable of controlling the actuators 5a to 5d based on the sensor signals received from the sensors 4a to 4d, and mutually transmit and receive communication data related to the sensor signals of the sensors 4a to 4d, communication data related to the control of the actuators 5a to 5d, and the like for the control of the actuators 5a to 5d via the central ECU 8, the shared bus 10.

[0047] The TCU 7 performs the same actions as (a). By using this TCU 7, Figure 1 the communication data transmitted and received between the central ECU 8 and the zone ECUs 9a to 9d, or the communication data received from the communication object to the central ECU 8 and the zone ECUs 9a to 9d. Figure 1 The vehicle-mounted network 20 of (b) is capable of transmitting the communication data transmitted and received between the central ECU 8 and the zone ECUs 9a to 9d to the communication object, or providing the communication data received from the communication object to the central ECU 8 and the zone ECUs 9a to 9d.

[0048] Figure 2 is a diagram showing a structure example of each communication device (domain ECU 3, zone ECU 9, gateway 2, central ECU 8) in the vehicle-mounted network 20 shown in Figure 1

[0049] Figure 2 (a) of (a) shows a configuration example of the domain ECU 3. As shown in Figure 2 (a), the domain ECU 3 is configured to have a CPU 11 and a memory 12. The CPU 11 performs a prescribed processing by using various data, programs stored in the memory 12, thereby executing an application corresponding to the function of the domain ECU 3. Upon a request of 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 the actuators 5.

[0050] Figure 2 (b) of (b) shows a structure example of the zone ECU 9. As shown in Figure 2 (b), the zone ECU 9 includes a CPU 11, a memory 12, and a network switch 13. The network switch 13 performs a communication control processing on the communication data transmitted and received between the other zone ECUs 9 and the central ECU 8. The CPU 11 performs a prescribed processing by using various data, programs stored in the memory 12, thereby executing an application corresponding to the function of the zone ECU 9. Upon a request of the application, network communication via the network switch 13 is performed between the CPU 11 and the other zone ECUs 9 and the central ECU 8, and various signals are transmitted and received between the CPU 11 and the sensors 4 and the actuators 5.

[0051] Figure 2 (c) of (c) shows a structure example of the gateway 2. As shown in Figure 2 ​As shown in (c) of FIG. 1, the gateway 2 includes a CPU 11, a memory 12, and a network switch 13. The CPU 11 performs prescribed processing by using various data and programs stored in the memory 12, and controls the operation of the network switch 13. The network switch 13 operates according to the control of the CPU 11, and performs a communication control process for communication data transmitted and received between the domain ECUs 3.

[0052] Figure 2 As shown in (d) of FIG. 1, the central ECU 8 includes a CPU 11, a memory 12, and a network switch 13. The CPU 11 performs prescribed processing by using various data and programs stored in the memory 12, and controls the operation of the network switch 13. The network switch 13 operates according to the control of the CPU 11, and performs a communication control process for communication data transmitted and received between the zone ECUs 9. Figure 2

[0053] [First Embodiment]

[0054] Next, the communication design device of the first embodiment of the present application will be described below with reference to Figures 3-14 In this embodiment, an example in which the communication design of the in-vehicle network 20 described in the first embodiment is performed in advance and the design result is reflected in the communication design device of the in-vehicle network 20 will be described. Figure 1

[0055] (System configuration)

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

[0057] The network information input device 21 inputs network information required when performing communication design of the in-vehicle network 20 to the communication design device 22. The network information input device 21 can receive an operation from a designer working at the design site 30, for example, set network information designated by the operation as a precondition for communication design of the in-vehicle network 20, and input the network information to the communication design device 22.

[0058] ​​The communication design device 22 automatically performs communication design of the in-vehicle network 20 based on the network information input from the network information input device 21. At this time, the setting conditions of the communication involved in each application are determined in a manner that accepts an operation from the designer to satisfy the communication requirements of each application designated by the operation. The result of the communication design of the communication design device 22 is 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.

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

[0060] In the in-vehicle network 20, the setting of each communication device is performed based on the network setting data 41 transmitted from the communication setting device 23. Thereby, the communication setting for the in-vehicle network 20 can be performed so that each communication device can communicate with each other as requested by the applications executed in each domain ECU 3 or each zone ECU 9.

[0061] (Configuration of the communication design device)

[0062] Figure 4 is a functional block diagram showing the configuration of the communication design device of the first embodiment of the present application. As shown in Figure 4 , the communication design device 22 is configured, for example, with each functional block of a communication requirement storage section 50, a schedule setting section 51, and a setting output section 52. These functional blocks in the communication design device 22 are realized, for example, by a computer executing a prescribed program.

[0063] The communication requirement storage section 50 stores communication requirement information related to the communication requirements of each application in the in-vehicle network 20. The communication requirement storage section 50 can be realized, for example, using various storage devices (HDD, SSD, flash memory, and the like) possessed by a computer. Further, details of the communication requirement information stored in the communication requirement storage section 50 will be described later.

[0064] The schedule setting section 51 sets the communication schedule of the in-vehicle network 20 for each application based on the communication requirement information stored in the communication requirement storage section 50. The schedule setting section 51 can set the communication schedule of the in-vehicle network 20 by allocating time slots of the communication of each application in a manner that satisfies the communication requirements that differ for each application. Further, details of the setting method of the communication schedule of the schedule setting section 51 will be described later.

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

[0066] (Communication Schedule)

[0067] Figure 5 is a diagram showing an example of the communication schedule of the in-vehicle network 20 set by the schedule setting section 51. The schedule setting section 51 sets the communication schedule of the in-vehicle network 20 by, for example, setting time slots 100, 101, and 102 at prescribed periods respectively, and allocating these time slots to the communication of each application. Note that the time slots can be implemented by IEEE 802.1Qbv of the TSN standard.

[0068] The time slot 100 is allocated to an application that performs communication that requires time guarantee with a short period, with the delay time being suppressed within a prescribed delay allowance time. In the in-vehicle network 20, the time slot 100 is secured at a certain period for communication performed at the request of the application, and communication data is transmitted and received between communication devices within the in-vehicle network 20 during the time slot 100. Thus, communication that satisfies the communication requirements of the application is performed.

[0069] The time slot 101 is allocated to an application that performs communication that requires time guarantee with a long period. In the in-vehicle network 20, the time slot 101 is secured at a certain period for communication performed at the request of the application, with a longer period than the time slot 100 described above, and communication data is transmitted and received between communication devices within the in-vehicle network 20 during the time slot 101. Thus, communication that satisfies the communication requirements of the application is performed.

[0070] The time slot 102 is allocated to each application that performs communication that does not require time guarantee. In the in-vehicle network 20, a period other than the time slots 100 and 101 described above is secured as the time slot 102 for communication performed at the request of the application, and communication data is transmitted and received between communication devices within the in-vehicle network 20 during the time slot 102. In the time slot 102, three classes that guarantee communication bandwidth and a class for best effort other than these are set corresponding to a plurality of communication ports possessed by the communication devices, and one of these is allocated according to the communication requirements of each application. Note that the guarantee of communication bandwidth can be implemented by IEEE 802.1Qav of the TSN standard. Thus, communication that satisfies the communication requirements of the application is performed.

[0071] In addition, Figure 5The communication schedule shown is an example, and other communication schedules are possible. For example, one, three, or more time-guaranteed time slots may be set, and the number of bandwidth-guaranteed classes set within time slot 102 may not be three. Furthermore, all time slots 102 may be allocated to the bandwidth-guaranteed class, or conversely, all time slots 102 may be allocated to the best-effort class. Furthermore, the communication schedule of the in-vehicle network 20 can be set using any time slot structure.

[0072] (Communication requirements information)

[0073] Figure 6 This diagram shows an example of a time-guaranteed communication requirement table indicating communication requirement information for an application that performs communication requiring time guarantee (hereinafter referred to as a “time-guaranteed application”) among the communication requirement information stored in the communication requirement storage unit 50 . Figure 6 The time-guaranteed communication requirement table 200 shown has records set for each type of communication data of each time-guaranteed application. Each record has data of a transmission source 201 , a destination 202 , a communication cycle 203 , a delay requirement 204 , and a packet length 205 .

[0074] Information indicating the communication device of the transmission source and destination of each communication data item is stored in the transmission source 201 and the destination 202, respectively. Information indicating the communication cycle of each communication data item is stored in the communication cycle 203. Information indicating the delay allowance for each communication data item is stored in the delay requirement 204. Information indicating the packet length (communication data volume) of each communication data item is stored in the packet length 205. This information indicates the communication requirements that each communication data item should meet for each time-guaranteed application.

[0075] Figure 7 The diagram shows an example of a bandwidth guaranteed communication requirement table that shows communication requirement information stored in the communication requirement storage unit 50 for applications that perform communications that do not require time guarantees but require a predetermined communication bandwidth (hereinafter referred to as "bandwidth guaranteed applications"). Figure 7 The bandwidth guaranteed communication requirement table 210 shown has records set for each type of communication data of each bandwidth guaranteed application, and each record has data of a transmission source 211 , a destination 212 , and a communication bandwidth 213 .

[0076] Information indicating the communication device of the source and destination of each communication data item is stored in the transmission source 211 and the destination 212, respectively. Information indicating the communication bandwidth of each communication data item is stored in the communication bandwidth 213. This information indicates the communication requirements that each communication data item should meet for each bandwidth-guaranteed application that requires regular reservation of a certain level of communication bandwidth due to the relatively large amount of communication data.

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

[0078] (How to set up the communication schedule)

[0079] Figure 8 This is a flowchart illustrating a method for setting a communication schedule in the communication design apparatus according to the first embodiment of the present invention. In the communication design apparatus 22 of this embodiment, the schedule setting unit 51 executes, for example, Figure 8 The process shown in the flowchart is performed to set the communication schedule of the in-vehicle network 20.

[0080] In step S100, the scheduling calculation process for time-guaranteed communication is performed. Figure 9 The process shown in the flowchart of Figure 6 Each time period specified in the communication requirement information illustrated in the example guarantees a time slot allocated to the application. Figure 9 The details of the processing are shown in the flowchart.

[0081] 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 during periods other than the time slot for time-guaranteed communication determined in step S100.

[0082] In step S102, a communication path calculation process for bandwidth guaranteed communication is executed. Figure 12 The process shown in the flowchart of the communication element is determined by Figure 7 The communication path and class of each bandwidth guaranteed application are specified by the communication requirement information shown in . Figure 12 The details of the processing are shown in the flowchart.

[0083] In step S103, the class to be used for best effort communication is determined. Here, in the time slot determined in the process of step S101, the remaining classes except the class used for bandwidth guaranteed communication are determined as the class to be used for best effort communication.

[0084] In step S104, the communication design result for the in-vehicle network 20 by the communication design device 22 is determined to satisfy the communication requirements of each application as indicated by the communication requirements information stored in the communication requirements storage unit 50. Here, a determination is made as to whether the delay time and communication bandwidth of each application, when communicating according to the communication schedule obtained in steps S100 to S103, satisfy the communication requirements of all applications. If the communication requirements of all applications are satisfied, the process proceeds to step S105; if the communication requirements of at least one application are not satisfied, the process proceeds to step S106.

[0085] In step S105, information indicating that the communication design device 22 has successfully designed the communication for the in-vehicle network 20 is output to the network information input device 21. The network information input device 21 receives this information and, in response, displays a predetermined message to the network information input device 21, thereby notifying the designer of the success of the communication design for the in-vehicle network 20. This encourages 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.

[0086] In step S106, information indicating that the communication design device 22 has failed to design the communication for the in-vehicle network 20 is output to the network information input device 21. The network information input device 21 receives this information and, in response, displays a predetermined message to the network information input device 21, thereby notifying the designer of the failure in designing the communication for the in-vehicle network 20. This can prompt the designer to reconsider the settings of the communication elements and the configuration of the in-vehicle network 20.

[0087] After executing the process of step S105 or S106, the communication design device 22 ends Figure 8 The processing is shown in the flowchart.

[0088] (Scheduling calculation processing for time-guaranteed communication)

[0089] Figure 9 It means in Figure 8 Flowchart of the flow of the schedule calculation process for time-guaranteed communication executed in step S100.

[0090] In steps S110 to S118, a loop process is performed for each delay element of the time-guaranteed communication. Figure 6In the communication requirement information shown in the time-guaranteed communication requirement table 200, communication data with the same value for delay requirement 204 are grouped together, thereby grouping the time-guaranteed applications according to each delay requirement. Furthermore, other information related to time-guaranteed communication, such as communication cycle 203, may also be used in the grouping. Then, by executing steps S110 to S118 for each group, the scheduling calculation process for time-guaranteed communication is performed. This allows multiple time-guaranteed applications with the same allowed delay time to be assigned time slots of the same cycle. Hereinafter, the group of time-guaranteed applications currently being processed is referred to as the "first processing target application group," and the details of the loop processing of steps S110 to S118 will be described.

[0091] After the loop process starts in step S110, the usage class of the first processing target application group is determined in the next step S111. Here, any one of the currently idle classes is selected and determined as the usage class of the first processing target application group.

[0092] In step S112, the total value of the packet length is calculated for all communication data flows of the first processing target application group with the same delay factor. Figure 6 The total value of the packet length of the communication data of the first processing target application group is calculated by summing up the values ​​of the packet length 205 of the records corresponding to the time-guaranteed applications of the first processing target application group in the communication requirement information represented by the time-guaranteed communication requirement table 200.

[0093] In step S113, the maximum number of hops in the in-vehicle network 20 in the communication of the first processing target application group is calculated based on the topology information of the in-vehicle network 20. Figure 6 In the communication requirement information represented by the time-guaranteed communication requirement table 200, the corresponding communication devices in the in-vehicle network 20 are identified based on the contents of the transmission source 201 and destination 202 in the records corresponding to each time-guaranteed application in the first processing target application group. Furthermore, the number of other communication devices that may be passed through during communication between these communication devices can be determined based on the topology information of the in-vehicle network 20, and the maximum number of these devices can be determined as the maximum hop count. The topology information of the in-vehicle network 20 is information indicating the connection relationships between the communication devices within the in-vehicle network 20, and is included in, for example, the network information input from the network information input device 21.

[0094] In step S114, the maximum delay time in the communication of the first processing target application group is calculated based on the maximum hop count calculated in step S113. Here, the delay time at the maximum hop count is calculated as the maximum delay time by multiplying the delay time per 1 hop set in advance by the maximum hop count calculated in step S113. In addition, the delay time calculated here includes the switching delay time (switching processing time, store-and-forward time, etc.) of the network switch 13, the transfer delay time of the communication data, and the like.

[0095] In step S115, the time slot length of the communication of the first processing target application group is calculated based on the total value of the packet lengths calculated in step S112 and the maximum delay time calculated in step S114. Here, the value obtained by adding the total value of the packet lengths to the maximum delay time is calculated as the time slot length of the communication of the first processing target application group. Thus, the length of the time slot based on which the same cycle is allocated is set based on the sum of the total value of the packet lengths involved in the plurality of time-guaranteed applications, the total value of the switching delay time required for the switching processing of the network switch 13 within the communication device in the in-vehicle network 20, and the total value of the transfer delay time required for the transfer of the communication in the in-vehicle network 20.

[0096] In step S116, the time slot of the communication of the first processing target application group is set for each of the communication cycles based on the time slot length calculated in step S115. Here, the end time of the time slot decided in the last cycle processing is set as the start time (offset) of the time slot based on the present cycle processing, and the time obtained by adding the time slot length calculated in step S115 to this time is set as the time slot based on the communication of the first processing target application group. Thus, the schedule setting section 51 of the present embodiment can set the cycle of the time slot for the plurality of time-guaranteed applications included in the first processing target application group in accordance with the delay allowance times of these time-guaranteed applications, and set the length of the time slot in accordance with the packet lengths of these time-guaranteed applications. As a result, the time slot of the communication performed by each of the time-guaranteed applications of the first processing target application group can be allocated.

[0097] In step S117, the routing for the first processing target application group is performed. Here, for example, the shortest path of the communication of the first processing target application group is determined based on the topology information of the in-vehicle network 20, and the routing of the shortest path is performed. In addition, the routing other than the shortest path can also be performed at this time to distribute the communication load in the entire in-vehicle network 20.

[0098] In step S118, the loop processing for the current first processing target application group is terminated. Then, for all groups formed by grouping applications requiring time guarantee according to each delay factor, it is determined whether the loop processing has been implemented. As a result, if there is a group that has not been loop processed, any one of the groups is set as the next first processing target application group and the next loop processing is started. On the other hand, if the loop processing has been implemented for all groups, the loop processing is terminated. Figure 9 The flowchart shows the scheduling calculation process of the time-guaranteed communication.

[0099] In the schedule calculation process for time-guaranteed communication, the schedule setting unit 51 performs the above-described process for each of the multiple time-guaranteed applications. Thus, the period of the time slot allocated to each time-guaranteed application's communication is set based on the delay tolerance of each of the multiple time-guaranteed applications, and the length of the time slot is set based on the packet length of the communication data of each of the multiple time-guaranteed applications.

[0100] Figure 10 1 is a diagram showing an example of time slots allocated to time-guaranteed applications by the scheduling calculation process for time-guaranteed communication described above. Figure 10 In the figure, it is shown that from a certain ECU (in Figure 10 ECU1 in the example) to another ECU ( Figure 10 ECU2 in the figure) is connected to the network switch 13 (in Figure 10 "Switch1" and "Switch3" in the figure) and a network switch 13 (in the figure) of another communication device located between them. Figure 10 In addition, the network switch 13 of each ECU performs time synchronization through the TSN function.

[0101] For example, for communication data 110, 111, and 112 based on various time-guaranteed applications, these communication data have the same delay requirements. Through the scheduling calculation process of the time-guaranteed communication, time slots 100a and 100b are allocated for each predetermined communication cycle. In these time slots 100a and 100b, each packet of communication data 110 to 112 is sent from ECU1 to ECU2. However, for example, Figure 10 If communication data is output from the time-guaranteed application currently running in ECU 1, such as packet 110c, which cannot reach ECU 2 within time slot 100a, the transmission of this communication data is temporarily suspended in ECU 1's network switch 13 (Switch 1). After that, when time 120 elapses from time slot 100a to the next time slot 110b, communication data 110-112 are resumed from ECU 1 to ECU 2.

[0102] In time slot 110b, communication data 110-112 output from the time-guaranteed application running in ECU 1 are aggregated into a series of packets in Switch 1 within ECU 1. After being transferred to the time-guaranteed application running in ECU 2 via Switch 2 and Switch 3, transmission delay 121a and exchange delay 122a in Switch 2 occur between the transmission timing of ECU 1 and the transmission timing of Switch 2. Similarly, transmission delay 121b and exchange delay 122b in Switch 3 are added between the transmission timing of Switch 2 and the reception timing of Switch 3. Furthermore, transmission delay 121c in ECU 2 and the total packet length 123 of communication data 110-112 are added between the reception timing of Switch 3 and the handover timing to the time-guaranteed application running in ECU 2.

[0103] If the length (slot width) of time slots 110a and 110b is τ i , then τ i It is represented by the following formula (1). In formula (1), τ Packets It represents the total value of the packet length of the time-guaranteed communication flow with the same delay requirement, which is equivalent to Figure 10 The packet length is 123. Proc and τ SF They represent the total value of internal processing delay and store-and-forward in each network switch 13 in the vehicle network 10, which is equivalent to Figure 10 The switching delay time 122a, 122b. Trans represents the total value of the transmission delay in each link in the in-vehicle network 10, which is equivalent to Figure 10 The transmission delay time 121a~121c.

[0104] τ i =τ Packets +τ Proc +τ Trans +τ SF …(1)

[0105] Furthermore, if the time in time slots 110a and 110b guarantees the maximum delay time of the communication flow (the time from the beginning of the transmission of the packet of communication data 110 to 112 in ECU 1 to the end of the reception of the packet of communication data 110 to 112 in ECU 2) is d E2E , then d E2E It is represented by the following formula (2). In formula (2), d Timeslot It represents the time from the end of the time slot of the previous cycle to the beginning of the time slot of the next cycle, which is equivalent toFigure 9 Time 120. In addition, C i Indicates the period of time-guaranteed communication.

[0106] d E2E =d Timeslot +τ SF +τ Trans +τ Packets +τ Proc

[0107] =C i -τ i +τ SF +τ Trans +τ Packets +τ Proc

[0108] =C i …(2)

[0109] As mentioned above, in the application, various delay times related to the transmission of communication data are added from the start of output to the end of transmission. Figure 11 In the scheduling calculation process of the time-guaranteed communication described in the flowchart of FIG. 1 , the time slots 100 a and 100 b can be set in consideration of these delay times.

[0110] Figure 11 This is a diagram showing an example of a scheduling calculation processing result for time-guaranteed communication. Figure 12 The schedule table 220 shown has records for each time slot setting obtained through the scheduling calculation process for time-guaranteed communication. Each record has data on a cycle 221, a reference time 222, and a time slot length 223. These data indicate the settings for each time slot for time-guaranteed communication.

[0111] (Communication Path Calculation Processing for Bandwidth-Guaranteed Communication)

[0112] Figure 8 It is shown in Figure 7 Flowchart of the flow of the communication path calculation process for bandwidth-guaranteed communication executed in step S102.

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

[0114] In steps S121 to S129, a loop process is performed for each communication flow that requires bandwidth guarantee. Figure 7The records of the illustrated bandwidth guarantee communication requirement table 210 determine one or more bandwidth guarantee applications common to the transmission source and the destination, and group the communication data of these bandwidth guarantee applications into a series of communication flows. For each communication flow set by grouping one or more bandwidth guarantee applications, the loop processing of steps S121 to S129 is executed. Hereinafter, the group of bandwidth guarantee applications corresponding to the application of the communication flow that is the object of the current loop processing among the bandwidth guarantee applications represented by the communication requirement information of the bandwidth guarantee communication requirement table 210 will be referred to as the "second processing object application group", and the contents of the loop processing of steps S121 to S129 will be described.

[0115] In the loop processing of steps S121 to S129, the loop processing of steps S122 to S125 is executed for each communication path available in the communication of the second processing object application group. Here, for example, in the communication requirement information represented by the bandwidth guarantee communication requirement table 210 Figure 13 In the communication requirement information represented by the bandwidth guarantee communication requirement table 210, the communication devices of the in-vehicle network 20 corresponding to the transmission source 211 and the destination 212 of the records corresponding to each bandwidth guarantee application belonging to the second processing object application group are determined from the contents thereof. Then, by listing all the communication paths of the in-vehicle network 20 connecting these communication devices, a path list is created, and the loop processing of steps S122 to S125 is executed for each communication path indicated by the path list. Hereinafter, the communication path that is the object of the current loop processing will be referred to as the "processing object path", and the contents of the loop processing of steps S122 to S125 will be described.

[0116] After starting the loop processing in step S122, in the next step S123, the available bandwidth and the available class number corresponding to each link on the processing object path are acquired. Here, for example, the available bandwidth and the available class number of each link on the processing object path can be obtained using the link usage information described below.

[0117] Figure 12 is a diagram showing an example of link usage information indicating the amount of usage bandwidth and the number of usage classes of each link used in the processing of step S123 of Figure 13 is a diagram showing an example of link usage information indicating the amount of usage bandwidth and the number of usage classes of each link used in the processing of step S123 of Figure 12 The link usage table 230 has a record set for each link in the in-vehicle network 20, and each record has data of the link 231, the usage bandwidth 232, and the usage class number 233. These data indicate the amount of bandwidth and the number of classes for each link allocated to the communication path set in the processing until the last time. In addition, the link usage table 230 is stored in the communication design device 22, and its contents are updated in step S127 described later.

[0118] Referring back to Figure 13In step S123, the available bandwidth and the number of available classes for each link on the processing target path can be obtained based on the link usage information as follows. That is, for each link on the processing target path, the available bandwidth and the number of available classes can be obtained by subtracting the available bandwidth calculated in step S120 from the available bandwidth. Figure 7 The values ​​of used bandwidth 232 in the illustrated link usage table 230 can be used to calculate the available bandwidth corresponding to each link on the processing target path. Furthermore, for each link on the processing target path, the number of available classes corresponding to each link on the processing target path can be calculated by subtracting the value of used class number 233 in the link usage table 230 from the preset number of classes.

[0119] In step S124, it is determined whether the available bandwidth and the number of available classes of each link of the processing target path calculated in step S123 meet the usage conditions of the communication path. Figure 13 The communication requirement information shown in the bandwidth-guaranteed communication requirement table 210 is used to calculate the total amount of communication bandwidth required for the communication flow of the second processing target application group (stream bandwidth) based on the value of the communication bandwidth 213 recorded for each bandwidth-guaranteed application belonging to the second processing target application group. If the available bandwidth of all links on the processing target path is greater than the stream bandwidth and the number of available classes is greater than 1, the communication path usage conditions are determined to be met, and the process proceeds to step S127, completing the loop of steps S122 to S125 for all communication paths. On the other hand, if the available bandwidth of any link on the processing target path is less than the stream bandwidth or the number of available classes is less than 1, the communication path usage conditions are determined to be unmet, and the process proceeds to step S125.

[0120] In step S125, the loop processing of steps S122 to S125 for the current processing target path is ended. Then, for all communication paths in the path list generated in step S122, it is determined whether the loop processing has been implemented. As a result, if there is a communication path that has not been implemented with the loop processing, any one of the communication paths is set as the next processing target path, and the next loop processing is started. In this way, the communication load related to the request of the second processing target application group is distributed to multiple communication paths by determining in step S124 that a communication path different from the communication path so far meets the use conditions of the communication path. On the other hand, if the loop processing has been implemented for all communication paths, the loop processing is ended and the process proceeds to step S126.

[0121] In step S126, a message indicating that the communication path calculation processing of the bandwidth guaranteed communication has failed is output. The message is notified to the designer, for example, by being displayed in the network information input device 21. Thereby, the designer can be prompted to reevaluate the structure of the in-vehicle network 20, the communication requirements.

[0122] In step S127, the values of the usage bandwidth 232 and the usage class number 233 of the records corresponding to the links on the processing target path that was the object of the previous loop processing in the link usage table 230 are updated. Specifically, the value of the usage bandwidth 232 and the value of the usage class number 233 of the records corresponding to the links on the processing target path that was the object of the previous loop processing in the link usage table 230 are each added by the value of the required bandwidth used in the determination processing of step S124 and 1. Thereby, the link usage table 230 can be updated to reflect the results of the setting of the communication path in the next step S128. Figure 8

[0123] In step S128, the communication path and the class that were determined in step S124 to have a usage bandwidth and a usage class number of each link that satisfy the usage condition are set as the communication path and the class to be used in the communication of each bandwidth guaranteed application belonging to the second processing target application group. Then, information indicating these setting contents is output as the processing result of step S102. Figure 12

[0124] After step S126 or S128 is executed, the loop processing of steps S121 to S129 for the current second processing target application group ends in step S129. Then, it is determined whether the loop processing has been performed for all the communication flows set in step S121. As a result, in the case where there is a communication flow for which the loop processing has not been performed, any one of the remaining communication flows is selected, the group of bandwidth guaranteed applications corresponding to the communication flow is set as the next second processing target application group, and the next loop processing is started. On the other hand, when the loop processing has been performed for all the communication flows, Figure 1 The communication path calculation processing of the bandwidth guaranteed communication shown in the flowchart ends.

[0125] In the communication path calculation processing of the bandwidth guaranteed communication, the above-described processing is performed by the schedule setting section 51 for each of the plurality of bandwidth guaranteed applications. Thereby, the plurality of bandwidth guaranteed applications are divided into one or more groups per communication flow, and the setting of the communication path and the allocation of the class are performed per group according to the bandwidth of the communication.

[0126] Further, in the above-described communication path calculation processing of the bandwidth guaranteed communication, the schedule setting section 51 can also decide the communication path in consideration of the configuration of the communication devices through which the communication flow passes within the in-vehicle network 20. For example, in the case where the in-vehicle network 20 is configured as a star network, the schedule setting section 51 can decide the communication path so that the communication flow passes through the hub device. Figure 14 ​​In the zone-based architecture-based in-vehicle network 20 shown in (b), at least a part of the communication involved in the request for the bandwidth guarantee application per communication flow packet can also be changed from the communication path via the communication devices, i.e., zone ECUs 9a, 9b, arranged in the front of the vehicle 1 to the communication path via the communication devices, i.e., zone ECUs 9c, 9d, arranged in the rear of the vehicle, thereby dispersing the load of the communication. In addition to this, an arbitrary communication path can also be set for each communication flow based on the bandwidth guarantee application, thereby dispersing the communication load within the in-vehicle network 20.

[0127] (network design data)

[0128] Figure 14 is a diagram showing an example of the network design data 40 output from the communication design device 22 to the communication setting device 23 in the case where the communication design of the in-vehicle network 20 is completed by the communication design device 22.

[0129] The network design data 40 is configured to include, for example, Figure 14 the schedule table 220 shown in (a) and Figure 8 the route table 240 shown in (b). The schedule table 220 shows the result of the schedule calculation processing of the time guarantee communication performed in step S100 of Figure 11 , and is the same as the example shown in Figure 8 . The route table 240 shows the result of the communication path calculation processing of the bandwidth guarantee communication performed in step S102 of Figure 12 , and has records set per kind of communication data of the bandwidth guarantee application performed within the in-vehicle network 20.

[0130] Each record of the route table 240 has data of a transmission source 241, a destination 242, and a communication path 243. In the transmission source 241 and the destination 242, information showing the communication devices of the transmission source and the destination of each communication data is stored, respectively. In the communication path 243, as information showing the communication path of each communication data, information of the communication path of each bandwidth guarantee application output in step S128 of Figures 15-19 is stored.

[0131] According to the first embodiment of the present application described above, the following effects are obtained.

[0132] (1) The communication design device 22 is a device that performs communication design for the in-vehicle network 20. The in-vehicle network 20 is connected to a plurality of communication devices that communicate with each other according to application requests. 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). This communication requirement information represents a delay allowance indicating the length of the communication delay time allowed for each time-guaranteed application, and a packet length of communication data determined for each time-guaranteed application; and a scheduling setting unit 51 that allocates communication time slots to each application. The scheduling setting unit 51 sets the time slot period based on the delay allowance of the plurality of time-guaranteed applications, and sets the time slot length based on the packet length of the plurality of time-guaranteed applications (steps S115 and S116). This allows for optimal communication design to be achieved for a network that communicates according to requests from various applications with different communication requirements.

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

[0134] (3) Furthermore, during the scheduling calculation process for time-guaranteed communication, the schedule setting unit 51 sets the length of the time slot based on the packet lengths of the multiple time-guaranteed applications assigned to the same periodic time slots (step S115). Specifically, the time slot length is set based on the sum of the packet lengths of the multiple time-guaranteed applications assigned to the same periodic time slots, the sum of the exchange delay time within the vehicle network 20, which is the time required for exchange processing in each communication device of the vehicle network 20, and the sum of the transmission delay time within the network, which is the time required for communication transmission. This allows the length of the time slot used for communication with the time-guaranteed application to be appropriately set.

[0135] (4) The applications executed within the in-vehicle network 20 include a first application group that performs communications requiring time guarantees and a second application group that performs communications requiring bandwidth guarantees. The scheduling setting unit 51 determines one or more time slots to be allocated to the first application group based on the delay allowable time of each time-guaranteed application belonging to the first application group (step S100). In addition, after determining the time slots to be allocated to the first application group, one or more time slots to be allocated to the second application group are determined (step S102). In this way, time slots that meet their respective communication requirements can be reliably allocated to each time-guaranteed application belonging to the first application group and each bandwidth-guaranteed application belonging to the second application group.

[0136] (5) In the time slot allocated to the second application group, one or more classes that guarantee a prescribed communication bandwidth are set. The scheduling setting section 51 classifies the bandwidth guarantee applications belonging to the second application group into one or more groups, and allocates classes according to the bandwidth of the communication for each group. Specifically, the scheduling setting section 51 sets a group of bandwidth guarantee applications whose transmission source and destination are the same according to the communication path in the in-vehicle network 20 (step S121), and calculates the available bandwidth and the available number of classes of each link included in the communication path for each group (step S123). Then, in any one of the links on the communication path, when the total bandwidth of the communication of each bandwidth guarantee application belonging to the same group exceeds the available bandwidth, or when the total number of classes of the communication of each bandwidth guarantee application belonging to the same group exceeds the available number of classes (step S124: No), the loop processing of steps S122 to S125 is executed for another communication path, so that the communication load related to the request of the second application group is dispersed to a plurality of communication paths. Therefore, bandwidth guarantee communication can be achieved throughout the in-vehicle network 20.

[0137] [Second Embodiment]

[0138] Next, the following describes Figure 1 The communication design device of the second embodiment of the present application is described. Also, in the present embodiment, regarding the in-vehicle network 20 described in the first embodiment, an example is described in which, in the case where the communication control needs to be changed due to the update of an application, the redesign of the time slot and the communication path is performed, and the design result is reflected to the communication design device of the in-vehicle network 20. Figure 15

[0139] (System Structure)

[0140] Figure 15 is a diagram showing a structure example of a system including the communication design device of the second embodiment of the present application. Figure 16 The system shown in the figure is a system used by being mounted on the vehicle 1, and is configured to include the in-vehicle network 20 and the communication design device 22 described in the first embodiment, and the application management device 24.

[0141] ​The application management device 24 receives update data transmitted from an OTA (Over The Air) server 32 provided on the cloud, and updates the application executed in the in-vehicle network 20 using the update data. In the present embodiment, the communication design device 22 judges whether or not the communication control needs to be changed due to the update of the application based on the update data output from the application management device 24, and performs redesign of the time slot and the communication path in the case where it is judged that the communication control needs to be changed, and outputs the result to the in-vehicle network 20. In the in-vehicle network 20, by reflecting the result of the redesign of the time slot and the communication path by the communication design device 22, it is possible to continue the communication between the communication devices even in the case where the communication control needs to be changed due to the update of the application.

[0142] (Structure of Communication Design Device)

[0143] Figure 16 is a functional block diagram showing the structure of the communication design device of the second embodiment of the present application. As shown in Figure 14 , the communication design device 22 is configured to have, for example, each functional block of a network information collection section 53 and a schedule storage section 54 in addition to the communication requirement storage section 50, the schedule setting section 51, and the setting output section 52 explained in the first embodiment. These functional blocks in the communication design device 22 are realized, for example, by a computer executing a prescribed program.

[0144] The network information collection section 53 collects network information including the connection relationship and the operation state of each communication device in the in-vehicle network 20, and updates the communication requirement information stored in the communication requirement storage section 50 as necessary based on the collected network information. For example, in the case where the recently collected network information has changed with respect to the network information collected in the past, the communication requirement information stored in the communication requirement storage section 50 is updated to reflect the change content.

[0145] In the present embodiment, the communication requirement information stored in the communication requirement storage section 50 is updated based on the content of the update data in the case where the update data is input from the application management device 24 in addition to the case where the network information has changed as described above. Specifically, in the case where a new application is added in the in-vehicle network 20, the case where an application is deleted, or the case where the delay allowance time or the packet length of the communication changes due to the update of the application, the communication requirement information is updated by inputting the update data from the application management device 24 to the communication requirement storage section 50.

[0146] The schedule storage section 54 stores the schedule of communication of each application of the in-vehicle network 20. That is, time slot information related to the time slot of the time guaranteed communication of the time guaranteed application, for example, information of the communication period, the timing, the time slot length, and the like, information related to the communication path of the bandwidth guaranteed communication of the bandwidth guaranteed application is stored in the schedule storage section 54. These information has, for example, the same data structure as the network design data 40 illustrated in the first embodiment. Figure 17

[0147] In the present embodiment, the schedule setting section 51 re-sets the communication schedule using the information stored in the schedule storage section 54 in a case where it is judged that the communication control needs to be changed due to the update of the application. Thereby, the time slot, the communication path corresponding to the update content of the application is re-designed and reflected to the communication control of the in-vehicle network 20.

[0148] (Communication schedule re-setting method)

[0149] Figure 17 is a flowchart illustrating a communication schedule re-setting method in the communication design device of the second embodiment of the present application. In the communication design device 22 of the present embodiment, the schedule setting section 51 executes the process illustrated in the flowchart of Figure 18 in response to the input of the update data from the application management device 24, thereby performing the re-setting of the communication schedule of the in-vehicle network 20.

[0150] In step S200, it is judged whether or not the time guaranteed communication needs to be re-designed. Here, for example, in a case where any one of the following (al) to (dl) is satisfied, it is judged that the time guaranteed communication needs to be re-designed and proceeds to step S201, and in a case where none of them is satisfied, it is judged that the time guaranteed communication does not need to be re-designed and proceeds to step S204. In addition, these conditions are an example, and other conditions can be used for the judgment of step S200. Or, the condition (bl) does not deteriorate the communication performance of the time guaranteed application which is not deleted, and thus it can be judged that the re-design of the time guaranteed communication is not needed.

[0151] (al) Addition of a time guaranteed application

[0152] (bl) Deletion of a time guaranteed application

[0153] (cl) Change of the communication allowable time or the packet length of a time guaranteed application

[0154] (dl) Change of network information

[0155] In step S201, the schedule re-calculation process of the time guaranteed communication is performed. Here, the schedule re-calculation process of the time guaranteed communication is performed by executing Figure 18 ​The process shown in the flowchart of re-determines the time slot allocated to each time guarantee application. Figure 8 The details of the processing are shown in the flowchart.

[0156] In step S202, the time slots for bandwidth guaranteed communication and best effort communication are re-determined. Here, the time slots for bandwidth guaranteed communication and best effort communication are re-determined except for the time slot for time guaranteed communication re-determined in step S201.

[0157] In step S203, a determination is made as to whether any link in the time slot re-determined in step S202 has bandwidth overflow for bandwidth-guaranteed communication. For example, the available bandwidth for each link in the re-determined time slot is calculated and compared with the bandwidth used for each link in the current communication schedule for the bandwidth guarantee application. If the available bandwidth for all links is 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. Information on the bandwidth used for each link in the current communication schedule for the bandwidth guarantee application is stored, for example, in the schedule storage unit 54.

[0158] In step S204, redesign of bandwidth guaranteed communication is set to “necessary.” Here, for example, by switching predetermined flag information related to redesign of bandwidth guaranteed communication from “invalid” to “valid,” the communication design device 22 executes the processing of step S206 described later.

[0159] In step S205, it is determined whether the bandwidth guaranteed communication needs to be redesigned. Here, for example, if the bandwidth guaranteed communication redesign is set to "necessary" in step S204, or if any of the following conditions (a2) to (d2) are met, it is determined that the bandwidth guaranteed communication redesign is necessary and the process proceeds to step S206. Otherwise, it is determined that the bandwidth guaranteed communication redesign is not necessary and the process ends. Figure 19 The process is shown in the flowchart of . Note that these conditions are merely examples, and other conditions may be used to determine step S205. Alternatively, condition (b2) does not degrade the communication performance of the bandwidth-guaranteed applications that have not been deleted, and therefore it can be determined that redesign of the bandwidth-guaranteed communication is unnecessary.

[0160] (a2) Addition of bandwidth guarantee applications

[0161] (b2) Deletion of bandwidth guarantee applications

[0162] (c2) Changes in communication bandwidth for bandwidth-guaranteed applications

[0163] (d2) Changes in Network Information

[0164] In step S206, the communication path recalculation process for bandwidth guaranteed communication is executed. Figure 19 The process shown in the flowchart of , re-determines the communication path and class allocation of each bandwidth guaranteed application. Figure 17 The details of the processing are shown in the flowchart.

[0165] After executing the process of step S206, the communication design device 22 ends Figure 18 The processing is shown in the flowchart.

[0166] (Schedule recalculation processing for time-guaranteed communication)

[0167] Figure 17 It means in Figure 18 Flowchart of the process of scheduling recalculation processing of time-guaranteed communication executed in step S201. Figure 9 In the flowchart of FIG. 1 , the same operation as described in the first embodiment is performed. Figure 9 The same steps are marked with the same step numbers in the schedule calculation process for time-guaranteed communication shown in the flowchart. Figure 9 The processing of common step numbers will be omitted below unless otherwise required.

[0168] In steps S110 to S118, the Figure 9 After the loop process starts in step S110, in the next step S210, the time slot information indicating the current communication schedule of the first processing target application group is obtained from the schedule storage unit 54.

[0169] In step S211, the current communication schedule indicated by the time slot information obtained in step S210 is compared with the update data input from the application management device 24 to determine whether the communication schedule of the first processing target application group has been changed. For example, if a new time-guaranteed application with different communication requirements from other time-guaranteed applications is added to the update data, and it is necessary to add a time slot for the communication of the time-guaranteed application, then the process proceeds to step S111. In this case, the same process as described in the first embodiment is performed on the first processing target application group. Figure 19 On the other hand, if there is no need to change the communication schedule, the process proceeds to step S118 to end the loop processing for the current first processing target application group.

[0170] In the schedule recalculation processing of the time guarantee communication, the above-described processing is performed by the schedule setting section 51 for each of the plurality of time guarantee applications. Thereby, the period of the time slot allocated to the communication of each time guarantee application is newly set on the vehicle 1 in accordance with the communication requirements of the updated time guarantee applications, and the length of the time slot is newly set on the vehicle 1 based on the packet lengths of the communication data involved in the plurality of time guarantee applications.

[0171] (Communication path recalculation processing of bandwidth guarantee communication)

[0172] Figure 17 is a flowchart showing the flow of the communication path recalculation processing of the bandwidth guarantee communication performed in step S206 of Figure 19

[0173] In step S220, it is determined whether the application update content indicated by the update data input from the application management device 24 is only a change in the time guarantee communication, or whether there is a change in the bandwidth guarantee communication. In the case where there is no change in the bandwidth guarantee communication, the process proceeds to step S221, and in the case where there is a change, it is determined that the communication path of the bandwidth guarantee communication needs to be recalculated, and the process proceeds to step S102.

[0174] In step S221, it is determined whether there is a link whose total bandwidth of the bandwidth guarantee communication exceeds the available bandwidth. In the case where there is a link in the in-vehicle network 20 whose available bandwidth decreases due to a change in the time guarantee communication and the available bandwidth after the decrease is below the total bandwidth of the bandwidth guarantee communication, it is determined that the communication path of the bandwidth guarantee communication needs to be recalculated, and the process proceeds to step S102. On the other hand, in the case where there is no such link, it is determined that the communication path of the bandwidth guarantee communication does not need to be recalculated, and the process ends. Figure 12

[0175] In the case where the process proceeds to step S102 from step S220 or S221, in step S102, the same communication path recalculation processing of the bandwidth guarantee communication as explained in the first embodiment is performed. That is, by performing the processing shown in the flowchart of Figure 19 Figure 20 After the process of step S102 is performed, the process shown in the flowchart of

[0176] In the communication path recalculation processing of the bandwidth guarantee communication, the above-described processing is performed by the schedule setting section 51 for each of the plurality of time guarantee applications. Thereby, the period of the time slot allocated to the communication of each time guarantee application is newly set on the vehicle 1 in accordance with the communication requirements of the updated time guarantee applications, and the length of the time slot is newly set on the vehicle 1 based on the packet lengths of the communication data involved in the plurality of time guarantee applications.

[0177] ​​​According to the second embodiment of the present application described above, the communication design device 22 further has a network information collecting section 53 that collects network information including connection relationships and action states of the communication devices in the in-vehicle network 20, and a schedule storage section 54 that stores time slot information related to the time slots set by the schedule setting section 51. The schedule setting section 51 re-sets the period or length of the time slots based on the time slot information stored in the schedule storage section 54 when at least one of the conditions that 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 delay allowable time or the packet length is changed, and the network information collected by the network information collecting section 53 is changed (step S200: YES), and sets the time slots (steps S115, S116). Thus, in the case where the communication control needs to be changed due to the update of the applications in the in-vehicle network 20, the change can be immediately coped with.

[0178] [Third Embodiment]

[0179] Next, the following describes Figure 1 The communication design device of the third embodiment of the present application is described. In this embodiment, an example of the communication design device that monitors the communication status of the in-vehicle network 20 described in the first embodiment, and in the case where there is an application that does not satisfy the desired communication performance requirement, re-designs the time slots and the communication paths, and reflects the design result to the in-vehicle network 20 is described. Figure 20

[0180] (Structure of Communication Design Device)

[0181] Figure 20 is a functional block diagram showing the structure of the communication design device of the third embodiment of the present application. As shown in Figure 17 , the communication design device 22 is configured, for example, with each functional block of the communication performance monitoring section 55 in addition to the communication requirement storage section 50, the schedule setting section 51, and the setting output section 52 described in the first embodiment, and the network information collecting section 53 and the schedule storage section 54 described in the second embodiment. These functional blocks in the communication design device 22 are realized, for example, by a computer executing a prescribed program.

[0182] The communication performance monitoring section 55 monitors the sufficient satisfaction status of the communication performance requirement including the delay allowable time among the communication requirements in each application executed by the in-vehicle network 20 for each application. Then, in the case where there is an application that does not satisfy the communication performance requirement, the application is determined, and the result is output to the schedule setting section 51.

[0183] ​In this embodiment, in addition to the case where the conditions described in the second embodiment are satisfied, the schedule setting unit 51 also resets the communication schedule of the in-vehicle network 20 when the communication performance monitoring unit 55 determines that the application does not satisfy the communication performance requirements. In this case, the schedule setting unit 51 executes the process described in the second embodiment, for example. ​ The process shown in the flowchart can reset the communication schedule of the in-vehicle network 20 in the same manner as in the second embodiment.

[0184] 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 the connection relationships and operating status of communication devices in the in-vehicle network 20; a communication performance monitoring unit 55 that monitors each application for the adequacy of communication performance requirements, including the delay tolerance, among the communication requirements of the application, and identifies any application that does not meet the communication performance requirements; and a schedule storage unit 54 that stores time slot information related to 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: the addition of a new time-guaranteed application to the in-vehicle network 20; the deletion of a time-guaranteed application from the in-vehicle network 20; the change in the delay tolerance or packet length; the change in the network information collected by the network information collection unit 53; and the identification of an application that does not meet the communication performance requirements by the communication performance monitoring unit 55. This allows for immediate action if an application in the in-vehicle network 20 does not meet the desired communication performance requirements.

[0185] Furthermore, the present invention is not limited to the various embodiments described above, but includes various variations. For example, the embodiments described above are specifically described to facilitate understanding of the present invention, and are not limited to having all of the structures described. Furthermore, a portion of the structure of a certain embodiment can be replaced with a portion of the structure of another embodiment. Furthermore, a portion of the structure of a certain embodiment can be added to a portion of another embodiment. Furthermore, a portion of the structure of each embodiment can be deleted, and a portion of another structure can be added or replaced with a portion of another structure.

[0186] The present invention is not limited to the above-described embodiment, and various modifications can be made without departing from the spirit of the present invention.

[0187] Description of Reference Numerals

[0188] 1 vehicle

[0189] 20 In-Vehicle Network

[0190] 21 Network information input device

[0191] 22 Communication Design Device

[0192] 23 Communication setting device

[0193] 24 Application Management Device

[0194] 50 Communication element storage unit

[0195] 51 Scheduling Setting Department

[0196] 52 Setting the output section

[0197] 53 Network Information Collection Department

[0198] 54 Scheduling Storage Department

[0199] 55 Communication Performance Monitoring Department

Claims

1. A communication design device for performing communication design for a network, wherein the network is connected to a plurality of communication devices, and the plurality of communication devices communicate with each other according to application requests, the communication design device comprising: a communication requirement storage unit that stores a delay allowance time indicating a length of a delay time of the communication allowed for each of the applications, and a communication data packet length determined for each of the applications; and a scheduling setting unit that allocates a time slot for the communication to each application; The scheduling setting unit performs: The period of the time slot is set according to the delay allowable time involved in the plurality of applications, The length of the time slot is set according to the packet lengths involved in the plurality of applications.

2. The communication design device according to claim 1, wherein: The schedule setting unit allocates the time slots of the same cycle to the plurality of applications having the same allowed delay time.

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

4. The communication design device according to claim 3, wherein: The scheduling setting unit sets the length of the time slot based on the total value of the packet lengths involved in the multiple applications assigned to the time slot of the same period, the total value of the time required for the switching processing in the communication device, i.e., the switching delay time within the network, and the total value of the time required for the transmission of the communication, i.e., the transmission delay time within the network. The communication design device according to claim 1 , wherein: The applications include a first application group that performs communications requiring time guarantees and a second application group that performs communications requiring bandwidth guarantees. The scheduling setting unit performs: determining one or more time slots to be allocated to the first application group based on the allowed delay time of each application belonging to the first application group; After determining the time slots allocated to the first application group, determining one or more time slots allocated to the second application group. The communication design device according to claim 5 , wherein: In the time slot allocated to the second application group, one or more classes are set to guarantee a predetermined communication bandwidth. The schedule setting unit divides the applications belonging to the second application group into one or more groups, and allocates the class to each of the groups according to the communication bandwidth.

7. The communication design device according to claim 6, wherein: The scheduling setting unit performs: setting the group according to a communication path in the network, Calculate the available bandwidth and the number of available classes of each link included in the communication path for each group; In any link on the communication path, when the total bandwidth of the communication of the applications belonging to the same group exceeds the available bandwidth, or the total number of classes of the communication of the applications belonging to the same group exceeds the number of available classes, the load of the communication involved in the request of the second application group is distributed to multiple communication paths.

8. The communication design device according to claim 7, wherein: The network is an in-vehicle network in which the plurality of communication devices mounted on a vehicle communicate with each other. The plurality of communication devices are arranged at least in front and rear of the vehicle, The scheduling setting unit changes at least a portion of the communication involved in the request of the second application group from the communication path between the communication devices configured in front of the vehicle to the communication path between the communication devices configured behind the vehicle, thereby distributing the communication load.

9. The communication design device according to claim 1, wherein: Also features: a network information collecting unit that collects network information including connection relationships and operation states of the communication devices in the network; and a schedule storage unit for storing time slot information related to the time slot set by the schedule setting unit, When at least one of the following conditions is met: a new application is added to the network; the application is deleted from the network; the allowed delay time or the packet length is changed; and the network information collected by the network information collection unit is changed, the scheduling setting unit resets the period or length of the time slot based on the time slot information stored in the scheduling storage unit.

10. The communication design device according to claim 1, wherein: Also features: a network information collecting unit for collecting network information including connection relationships and operation states of the communication devices in the network; a communication performance monitoring unit configured to monitor, for each of the applications, whether communication performance requirements, including the delay tolerance time, among the communication requirements in the applications are fully satisfied, and to identify, if any, applications that do not satisfy the communication performance requirements; as well as a schedule storage unit for storing time slot information related to the time slot set by the schedule setting unit, When at least one of the following conditions is met: a new application is added to the network; the application is deleted from the network; the allowed delay time or the packet length is changed; the network information collected by the network information collection unit is changed; and the communication performance monitoring unit determines that the application does not meet the communication performance requirements, the scheduling setting unit resets the period or length of the time slot based on the time slot information stored in the scheduling storage unit.

11. The communication design device according to claim 1, wherein: The network is mounted on a vehicle. The communication design device receives information related to communication requirements of the application related to control of the vehicle as input, and outputs setting information related to communication control of the network.

12. The communication design device according to claim 1, wherein: The communication design device is mounted on a vehicle together with the network. In the network, the plurality of communication devices mounted on the vehicle communicate with each other in response to requests from the plurality of applications related to control of the vehicle. A communication schedule of the network is reset within the vehicle.

13. A communication design method for designing communication of a network, wherein a plurality of communication devices are connected to the network and the plurality of communication devices communicate with each other according to a request of an application, wherein the communication design method includes: storing in a computer a delay allowance time indicating the length of the communication delay time allowed for each application and a packet length of communication data determined for each application, Allocating the communication time slot to each application by the computer, In the allocation of the time slots, The period of the time slot is set according to the delay allowable time involved in the plurality of applications, The length of the time slot is set according to the packet lengths involved in the plurality of applications.

Images