Network system and network management method

Abstract

To provide a network system and a network management method that enable placement of applications taking into account computing resources of each computing device existing on a network and communication resources between computing devices.SOLUTION: A network system includes: a communication path selection unit 25 that selects communication paths for an application when the application is placed on each computing device in a candidate list 90 of application placement destination computing devices, on the basis of topology information indicating a communication connection relationship between a plurality of computing devices 3,9, and creates a candidate list 110 of communication paths; a performance verification unit 26 that verifies, on the basis of communication performance information and communication requirements 64, whether the communication requirements 64 are satisfied for each communication path in the candidate list 110 of communication paths; and a setting applying unit 27 that places the application on a computing device corresponding to a communication path for which the communication requirements 64 are verified to be satisfied by the performance verification unit 26 among the computing devices in the candidate list 90 of application placement destination computing devices.SELECTED DRAWING: Figure 3

Description

[Technical field]

[0001] The present invention relates to a network system and a network management method for allocating applications to a plurality of computing devices on a network. [Background technology]

[0002] Autonomous driving and safe driving support technologies are advancing day by day and will continue to evolve in the future. Automobile manufacturers are considering applying these technological advances not only to new vehicles but also to vehicles that have already been sold. One technology for this purpose is OTA (Over-the-Air) update technology.

[0003] With OTA, new or updated in-vehicle applications (hereafter simply referred to as apps) are delivered to the vehicle via a wireless network from a server such as the cloud. The delivered apps are then deployed to the vehicle system and applied / executed.

[0004] A vehicle system is made up of multiple electronic control units (ECUs) connected via a network. Here, ECU is used as a general term for sensors such as cameras, actuators that operate the engine and steering, and devices that perform calculations for control. The ECU sends and receives data via the in-vehicle network, and obtains information for vehicle control by calculating the data using apps. Sending and receiving data places a load on the in-vehicle network, but the load on the in-vehicle network varies depending on the placement of the apps.

[0005] Here, when a new application is added by OTA, the vehicle system needs to select an ECU that will execute the new application. Patent Document 1 discloses a method for selecting an ECU that will execute an application when adding an application. In this method, an in-vehicle system including a plurality of ECUs in which an additional application acquired by an application acquisition unit can be installed includes a requirement specification unit, a resource specification unit, and a selection unit. The requirement specification unit specifies required resources that are resources required by the additional application. The resource specification unit specifies provided resources that are resources that each ECU can provide. The selection unit selects an ECU whose provided resources satisfy the required resources as the installation destination for the additional application. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] JP 2020-86522 A Summary of the Invention [Problem to be solved by the invention]

[0007] The invention described in Patent Document 1 can select the ECU in which an application is to be placed based on the ECU's computational resources, but it cannot place applications while taking into account communication resources between ECUs, such as the load status of the in-vehicle network.

[0008] The present invention has been made in consideration of the above-mentioned problems, and its object is to provide a network system and a network management method that enable the placement of applications taking into account the computing resources of each computing device on the network and the communication resources between the computing devices. [Means for solving the problem]

[0009] In order to achieve the above object, the present invention provides a network system for distributing an application to one of a plurality of computing devices present on a network so as to satisfy an execution requirement of the application, the network system including an application requirement storage unit for storing execution requirements and communication requirements of the application, an available resource information storage unit for storing available resource information of the plurality of computing devices, an application placement selection unit for selecting a computing device capable of executing the application from the plurality of computing devices based on the execution requirement and the available resource information, and creating a list of candidate computing devices for application placement, a topology information storage unit for storing topology information indicating a communication connection relationship of the plurality of computing devices, and a network configuration information storage unit for storing a network configuration information of the plurality of computing devices. the communication path selection unit selecting a communication path of the application when the application is placed on each computing device in the application placement destination computing device candidate list based on the topology information to create a communication path candidate list; a performance verification unit verifying whether or not the communication requirements are satisfied on each communication path in the communication path candidate list based on the communication performance information and the communication requirements; and a setting application unit deploying the application to a computing device in the application placement destination computing device candidate list that corresponds to a communication path for which it has been verified by the performance verification unit that the communication requirements are satisfied.

[0010] Further, the present invention provides a network management method for deploying an application to one of a plurality of computing devices present on a network so as to satisfy execution requirements of the application, the method comprising: an application requirement retaining step for retaining execution requirements and communication requirements of the application; a free resource information retaining step for retaining free resource information of the plurality of computing devices; an application placement selection step for selecting a computing device capable of executing the application from the plurality of computing devices based on the execution requirements and the free resource information, and creating a list of candidate computing devices where the application is to be placed; a topology information retaining step for retaining topology information indicating a communication connection relationship between the plurality of computing devices; a communication performance information retaining step for retaining communication performance information of each link of the network; a communication path selection step for selecting a communication path for the application when the application is placed on each computing device in the candidate computing device where the application is to be placed based on the topology information, and creating a communication path candidate list; a performance verification step for verifying whether the communication requirements are satisfied by each communication path in the communication path candidate list based on the communication performance information and the communication requirements; and a setting application step for deploying the application to a computing device in the candidate computing device where the application is to be placed that corresponds to a communication path for which it has been verified that the communication requirements are satisfied by the performance verification step, among the computing devices in the candidate computing device where the application is to be placed. Effect of the Invention

[0011] According to the present invention, when placing an application on one of multiple computing devices on a network, the execution performance and communication performance of the application can be ensured by taking into account the computing resources of each computing device and the communication resources between the computing devices, thereby enabling the application to operate stably. [Brief description of the drawings]

[0012] [Figure 1] FIG. 1 is a diagram of the electrical and electronic architecture of an in-vehicle device incorporating an in-vehicle network system according to the present invention; [Diagram 2] Hardware configuration diagram of domain ECU, zone ECU, central ECU, and gateway [Diagram 3] Functional block diagram of an in-vehicle network system according to the present invention. [Figure 4] ECU free resource information table held by free resource information holding unit [Diagram 5] Example of the configuration of OTA data received by the application requirements storage unit via the TCU [Figure 6] Application requirement table held by the application requirement holding unit [Figure 7] Topology information table held by the topology information holding unit [Figure 8] An excerpt from the communication performance information table stored in the communication performance information storage unit [Figure 9] Flowchart showing the operation of the application placement selection unit [Figure 10] A list of candidate ECUs for application placement, which is the output of the application placement selection section. [Figure 11] Flowchart showing the operation of the communication path selection unit [Figure 12] A flowchart showing an example of detailed processing of step S209 in FIG. [Figure 13] A flowchart showing an example of detailed processing of step S221 in FIG. [Figure 14] Example of the results of executing the process in Figure 13 on a network in a zone architecture [Figure 15] A list of application communication route candidates output from the communication route selection unit and input to the performance verification unit [Figure 16] Flowchart showing the operation of the performance verification unit [Figure 17] A flowchart showing an example of detailed processing of step S302 in FIG. [Figure 18] A flowchart showing an example of detailed processing of step S303 in FIG. [Figure 19] A flowchart showing an example of detailed processing of step S305 in FIG. [Figure 20] A communication path list output from the performance verification unit and input to the configuration application unit [Figure 21]Flowchart showing the operation of the setting application unit [Figure 22] Example of the configuration of the communication path setting table used by the setting application part [Diagram 23] Configuration diagram of the performance verification unit in the second embodiment [Figure 24] 17 is a flowchart showing the operation of step S305 in FIG. 16 among the operations of the performance verification unit in the second embodiment. [Diagram 25] A functional block diagram of an in-vehicle network system according to a third embodiment. [Figure 26] Application requirement table held by the application requirement holding unit in the fourth embodiment [Figure 27] Application requirement table held by the application requirement holding unit in the fourth embodiment [Figure 28] Application requirement table held by the application requirement holding unit in the fifth embodiment [Figure 29] Flowchart showing the operation of the performance verification unit DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. In each drawing, the same reference numerals are used to denote the same elements, and duplicated explanations will be omitted as appropriate. EXAMPLES

[0014] A first embodiment of the in-vehicle network system will be described below with reference to the drawings.

[0015] 1 is a diagram showing the electrical and electronic architecture of an in-vehicle device equipped with an in-vehicle network system according to the present invention. Here, two configurations are taken up as representative electrical and electronic architectures, but the application of the present invention is not limited to these.

[0016] FIG. 1(a) shows the logical configuration of an architecture called domain-specific architecture. This is a method in which ECUs (electronic control units) inside a vehicle 1 are classified into functional divisions called domains, and ECUs belonging to the same domain are systematically connected. A domain ECU 3 that governs each domain is placed. In addition, the domain ECUs 3 are connected to each other via a gateway 2 to communicate between domains. The domains include, for example, an Advanced Driver Assistance System (ADAS) domain that manages safe driving support, a Power Train / Chassis (PT / CH) domain that controls the vehicle's forward / rearward and left / right movements, a Body domain that controls electrical equipment such as power windows, and an Infotainment domain that controls navigation and audio. An ADAS ECU 3a, a PT / CH ECU 3b, a Body ECU 3c, and an Infotainment ECU 3d (hereinafter collectively referred to as 3) are placed for each domain. ECUs 4 and 5, such as sensors 4a to 4d (hereinafter collectively referred to as 4) and actuators 5a to 5d (hereinafter collectively referred to as 5), are connected to the domain ECU 3 via links 6a to 6d (hereinafter collectively referred to as 6) suitable for each domain, such as a Controller Area Network (CAN) or a Local Interconnect Network (LIN). A single link 6 may connect to multiple ECUs 4 and 5. Also connected to the gateway 2 is a Telematics Control Unit (TCU) 7, which communicates with servers outside the vehicle, clouds, etc. via a wireless network.

[0017] The performance and functional requirements of each domain ECU may differ. For example, ADAS ECUs and Infotainment ECUs use hardware with high processing performance to handle large volumes of data such as video. On the other hand, PT / CH ECUs use highly reliable hardware to ensure safe direct connection.

[0018] FIG. 1(b) is a diagram showing the physical configuration of an architecture called zone architecture. This is a method in which ECUs 4 and 5 are classified according to their spatial positions inside the vehicle 1, and are connected to zone ECUs 9a to 9d (hereinafter collectively referred to as 9) that control the positions. It is composed of one or more zone ECUs 9, a central ECU 8 that is connected to the zone ECU 9 and executes multiple applications across multiple domains, and sensors 4 and actuators 5 that are connected to the zone ECU 9. As the name suggests, the zone ECUs 9 are arranged corresponding to positions (zones) such as front, rear, left and right in the vehicle, and are connected to sensors 4 or actuators 5, or both, that are close to the installation positions. In addition, the zone ECUs 9 are connected to other zone ECUs 9 by shared links 10 that use a common communication method between domains. The common communication method is assumed to be a switching network using Ethernet (registered trademark). The TCU 7 is connected to the central ECU 8 or any zone ECU 9, but FIG. 1(b) shows an example of connection to the central ECU 8.

[0019] Fig. 2 shows the hardware configuration of the domain ECU 3, zone ECU 9, central ECU 8, and gateway 2. The thick lines in Fig. 2 represent a common communication method, which is a connection method between communication devices 2 in the zone architecture or domain architecture, and the thin lines represent other communication methods.

[0020] 2(a) shows the hardware configuration of the domain ECU 3. The domain ECU 3 has inside it a CPU (Central Processing Unit) 11 for processing information received from the sensors 4 and actuators 5 or the gateway 2, and a memory 12 for holding data used for calculations by the CPU 11. Links for connecting to the gateway 2 and links for connecting to the sensors 4 and actuators 5 extend from the CPU 11.

[0021] 2(b) shows the hardware configuration of the zone ECU 9. The zone ECU 9 is equipped with a network switch 13 that accommodates a shared link 10 for connecting to other zone ECUs 9 or for connecting to the sensor 4 or actuator 5. The zone ECU 9 also has a CPU 11 for processing information received from the sensor 4 and actuator 5 or the shared link 10, and is connected to the network switch 13. The CPU 11 is also connected to a memory 12. If the sensor 4 and actuator 5 are compatible with a common communication method, they may be directly connected to the network switch 13. If the sensor 4 and actuator 5 are not compatible with the common communication method, they can be converted to the common communication method after being connected to the CPU 11.

[0022] 2(c) shows a hardware configuration of the gateway 2 in the domain-specific architecture. The gateway 2 includes a CPU 11, a memory 12, and a network switch 13 for connection to the domain ECU 3.

[0023] 2(d) shows the hardware configuration of the central ECU 8 in the zone-specific architecture. The central ECU 8 has a configuration similar to that of the gateway 2, and includes a CPU 11, a memory 12, and a network switch 13 for connecting to the zone ECUs 9.

[0024] Fig. 3 is a functional block diagram of an in-vehicle network system according to the present invention. The functional blocks may be implemented as independent devices not shown in Fig. 1, or may be implemented as software and executed by any of the ECUs in Fig. 1. When implemented as software, it can be executed by any of the ECUs in Fig. 1 without impairing functionality, but typically, in order to manage the entire in-vehicle network, it is assumed that it will be implemented in a gateway in the case of a domain-specific architecture, or in a central ECU in the case of a zone architecture.

[0025] The present invention comprises functional blocks of an available resource information storage unit 20, an application requirement storage unit 21, a topology information storage unit 22, a communication performance information storage unit 23, an application placement selection unit 24, a communication path selection unit 25, a performance verification unit 26, and a setting application unit 27.

[0026] The free resource information holding unit 20 periodically collects and holds information on the resource status within each ECU, such as free CPU capacity and free memory capacity.

[0027] The application requirement storage unit 21 stores execution requirements for applications executed by each ECU in the vehicle. The application requirement storage unit 21 stores requirements for applications pre-installed at the time of shipping the vehicle, and the requirements for applications added by OTA are received via the TCU 7 together with OTA data. Specific examples of requirements will be described with reference to FIG. 6.

[0028] The topology information storage unit 22 stores topology information that indicates the connection relationships of the in-vehicle network.

[0029] The communication performance information holding unit 23 holds performance information of currently performed communication, that is, the communication resource status between ECUs, for each link in the in-vehicle network.

[0030] The application placement selection unit 24 determines candidate ECUs for placement of the application based on the resource status inside each ECU obtained from the free resource information storage unit 20 and execution requirement information related to the ECU's internal resources (computational resources) of the application obtained from the application requirement storage unit 21.

[0031] The communication path selection unit 25 determines candidate communication paths for communication by the application based on the candidate ECUs for placing the application determined by the application placement selection unit 24, the communication destination information of the application obtained from the application requirement storage unit 21, and the topology information of the in-vehicle network obtained from the topology information storage unit 22.

[0032] The performance verification unit 26 verifies the communication performance of the application when the communication path candidate is selected for the application communication path candidate determined by the communication path selection unit 25, based on the application communication requirements acquired from the application requirement storage unit 21 and the communication performance information acquired from the communication performance information storage unit 23. From the route candidates that satisfy the communication performance of the application as a result of the verification, one communication path to be actually used is selected.

[0033] The setting application unit 27 applies the communication path determined by the performance verification unit 26 to the in-vehicle network. To this end, the setting application unit 27 obtains data transmission / reception destination addresses of the application from the application requirement storage unit 21, and sets transfer rules in the network switch 13 inside the ECU on the path.

[0034] The following describes each functional block in detail.

[0035] 4 shows an intra-ECU free resource information table 30 held by the free resource information holding unit 20. The intra-ECU free resource information table 30 holds information in a computational resource column 32, a storage resource column 33, and a spec column 34 for an ECU column 31. The spec means characteristics of an ECU, such as high performance and high reliability.

[0036] 5 shows an example of the configuration of OTA data 40 received by the application requirement storage unit 21 via the TCU 7. The OTA data 40 includes a header 41 including an application ID, version information, and the like, application data 42 storing the code of the application body in a binary format or the like, and metadata 43 related to the application referenced in the present invention. The metadata 43 holds execution requirements 53, communication specifications 58, and communication requirements 64 similar to those in the application requirement table 50 shown in FIG. 6, corresponding to a communication ID 54 that is an identification number of communication in the application. When an application performs multiple communications, it has multiple sets of communication IDs, execution requirements 53, communication specifications 58, and communication requirements 64. The details of the execution requirements 53, communication specifications 58, and communication requirements 64 are the same as those in FIG. 6, and will be described together with FIG. 6.

[0037] 6 shows an application requirement table 50 held by the application requirement holding unit 21. The application requirement table 50 holds an application column 51 holding the ID of an application, a deployment flag 52 indicating that the application has been deployed in any ECU, an execution requirement 53 holding requirements related to ECU internal resources (computational resources), a communication specification 58 holding specifications for communication between ECUs, and a communication requirement 64 holding requirements related to communication resources between ECUs. The execution requirement 53 includes a computational resource column 55, a storage resource column 56, and a spec column 57. The communication specification 58 includes, as application requirements related to communication between ECUs, a communication direction column 59 indicating whether the application is sending or receiving, a communication partner column 60 identifying the communication partner of the application, a communication cycle column 61, a packet size column 62, and application identification information 63 which is information for identifying the application from a communication packet. The application identification information includes, for example, the CAN ID of CAN, source and destination MAC addresses in Ethernet, source and destination IP addresses in IP (Internet Protocol), and source and destination port numbers in TCP (Transmission Control Protocol) or UDP (User Datagram Protocol). The communication requirement 64 includes a communication bandwidth column 65, a communication delay column 66, a jitter column 67, and a loss rate column 68. When a single application performs multiple communications, the application uses multiple rows to represent the multiple communications, as in application A3. When an application does not perform communications, only the execution requirements can be set for the application, as in application A4.

[0038] 7 shows a topology information table 70 held by the topology information holding unit 22. The topology information table 70 has a link column 71 indicating each link connecting ECUs in an in-vehicle network, a type column 72 indicating whether the type of the link is a bus type (a form in which multiple ECUs are connected to one common communication path) or a mesh type (a form in which one ECU is connected one-to-one to another ECU), and a connection information column 73 holding the IDs of the ECUs connected to the link.

[0039] 8 is an excerpt of a communication performance information table 80 held by the communication performance information holding unit 23. The communication performance information table 80 has a link column 81, a communication direction 82, a total bandwidth column 83 indicating the total bandwidth of the link for each link and each communication direction, a used bandwidth column 84 indicating the bandwidth used by existing applications, a delay time column 85 indicating the maximum delay time, a jitter column 86, a loss rate column 87, and a buffer usage column 88.

[0040] FIG. 9 is a flowchart showing the operation of the application placement selection unit 24. This flowchart is started when the application requirement table 50 is updated due to the addition of an application by OTA. First, in step S100, the application requirement table 50 is obtained from the application requirement storage unit 21. Next, in S101, the following processing is looped for each application registered in the application requirement table 50. In step S102, the placement flag of the target application is checked, and if it has been placed (Yes), nothing is done and the process proceeds to the next application. If it has not been placed (No), steps S103 and after are executed. In step S103, it is checked whether the execution requirements of the target application have been registered in the application requirement table 50. If it has not been registered (No), in step S108, the ECU candidate list defined in advance is sorted in descending order of total resources, and the ECU is set as a candidate ECU for placement of the application, and the process proceeds to the next application. If it has been registered (Yes), the following processing is performed. In step S104, the ECU free resource information table 30 is obtained from the free resource information storage unit 20. In the next step S105, among the ECUs in ECU free resource information table 30, ECUs whose computational resources and memory resources are greater than the computational resources and memory resources in the application execution requirements and that satisfy the specifications required by the application are selected, thereby selecting ECUs that satisfy the execution requirements required by the application, and creating a list of candidate ECUs for placement. Then, in step S106, the ECU candidate list is sorted in descending order of free resources to determine the candidates for ECUs for placement of the application. In step S107, it is determined whether the loop for the application has ended, and if processing has been completed for all applications, this processing ends.

[0041] 10 shows an application placement ECU candidate list 90 which is the output of the application placement selection unit 24. The application placement ECU candidate list 90 holds placement ECU candidates 92 for each application sequence 91. The application placement ECU candidate list 90 becomes an input to the communication path selection unit 25 in the next step.

[0042] 11 is a flowchart showing the operation of the communication path selection unit 25. This flowchart is started in response to input of the application placement ECU candidate list 90 from the application placement selection unit 24. First, in step S200, the application placement ECU candidate list 90 is obtained from the application placement selection unit 24. In step S201, the topology information table 70 of the in-vehicle network is obtained from the topology information storage unit 22. In step S202, it is confirmed whether the topology information of the in-vehicle network is included in the topology information table 70, and if not (No), predefined default topology information is used in step S204. If the topology information is included in step S202 (Yes), the topology information in the topology information table 70 is used in step S203. In the next step S205, the following loop processing is performed for each application in the application column 91 of the application placement ECU candidate list 90. First, in step S206, communication partner information is obtained from the application requirement storage unit 21 for each communication data (packet) of the application. Here, communication partner information collectively refers to the data sender in received data and the data destination in transmitted data. In step S207, the communication partner information is checked, and if information about the communication partner is not included (No), it is determined that communication will not take place and the processing proceeds to the next application. If information about the communication partner is included in step S207 (Yes), the processing proceeds to step S208 and subsequent steps. In step S208, a loop is started for the placement ECU candidates 92 in the application placement ECU candidate list 90. In step S209, route candidates from the data sender to the data receiver are obtained by a process defined separately. When the process of S209 is completed for all placement ECU candidates, the loop for the placement ECU candidates is ended in S210.

[0043] When the processing has been completed for all applications in the application-installation-destination-ECU-candidate list 90, the loop ends in step S211, and the processing of the communication path selection unit 25 ends.

[0044] Fig. 12 is a flowchart showing an example of detailed processing of step S209 in Fig. 11. First, in step S220, a loop is started for each communication belonging to an application. In the following step S221, a route from the source ECU to the destination ECU is searched for by a process defined separately. Then, in step S222, if the destination ECU is reached, the searched route is added to a route candidate list. When processing has been completed for all communication data, the loop is ended in step S223, and this process is terminated.

[0045] Fig. 13 is a flowchart showing an example of detailed processing of step S221 in Fig. 12. Here, a path from the source ECU to the destination ECU is searched for by a breadth-first search, but other search algorithms such as a depth-first search may also be used. Fig. 14 shows an example of a search list 100 used in this search process. The search list 100 has a phase 101 indicating the stage of the search, communication path candidates 102 indicating route candidates that have already been searched from the source ECU to the destination ECU, and a state 103 indicating the state of the communication path candidates 102.

[0046] First, in step S230, the variable "phase" is set to 0, the source ECU is selected with a status of incomplete, and added to the first entry in the search list. In the following step S231, the phase is incremented by 1. Next, in step S232, from among the communication path candidates 102 whose status is incomplete in the search list of the previous phase, an ECU that is directly connected in the topology to the ECU at the end of the path candidates is extracted, and the ECU added to the end of the communication path candidates 102 is added to the search list 100 of the current phase.

[0047] In step S233, a loop is started for the search list 100 of the current phase created as described above. In step S234, the state of the communication path candidate 102 is checked. First, if the end of the communication path candidate 102 is the destination ECU (S234a), the state 103 of the communication path is set to "destination reached" in step S235, and added to the path candidate list, which is the output of the communication path selection unit 25, in step S236. Next, if the end of the communication path candidate 102 is a searched ECU in step S234 (S234b), that is, if the communication path candidate includes multiple identical ECUs, the state 103 of the communication path candidate is set to "searched and reached" in step S237. If otherwise in step S234 (S234c), the state 103 of the communication path candidate is set to incomplete in step S238. Then, if the processing is completed up to the end of the search list of the current phase, the loop is terminated in step S239.

[0048] Finally, in step S240, it is checked whether there is a communication path candidate 102 whose status is incomplete in the search list of the current phase, and if there is a communication path candidate 102 whose status is incomplete, the process returns to step S231 to continue. If there is no communication path candidate 102 whose status is incomplete, that is, if the search for the topology of the in-vehicle network is completed, this process ends.

[0049] Figure 14 shows an example of the results of executing the process in Figure 13 on a network of the zone architecture. For those whose status was incomplete in the previous phase, in the current phase, a list of communication path candidates is created by adding the next reachable ECU. Then, in phase 5, the status becomes destination reached (ECU C shown in underline) or searched reached (ECU A shown in italics), and the search is completed.

[0050] 15 shows a communication path candidate list 110 for an application, which is output from the communication path selection unit 25 and input to the performance verification unit 26. The communication path candidate list 110 for an application holds communication path candidates 112 for a sequence 111 of applications.

[0051] FIG. 16 is a flowchart showing the operation of the performance verification unit 26. First, in step S300, the communication route candidate list 110 of the application is received from the communication route selection unit 25. Next, in step S301, a loop is performed for the application listed in the communication route candidate list 110. Next, in step S302, communication requirement information of the application is obtained from the application requirement storage unit 21 in a procedure defined separately. Next, in step S303, communication performance information of each link on the in-vehicle network is obtained from the communication performance information storage unit 23 in a procedure defined separately. Next, in step S304, a loop is performed for the route candidates for the application listed in the communication route candidate list 110. Next, in step S305, the communication performance of the application when using the selected route is evaluated from the communication performance information of the route candidate and the communication requirements of the application in a procedure defined separately. This evaluation result is judged in step S306, and if the communication requirements of the application cannot be satisfied (No), the loop for the route candidate list is continued. If a communication path that can satisfy the communication requirements of the application exists in step S306 (Yes), the application placement is determined to be successful in step S310, and communication path information is output to the setting application unit 27. Then, in step S311, the information in the free resource information storage unit 20 and the communication performance information storage unit 23 is updated. If a communication path that can satisfy the communication requirements of the application does not exist and the loop ends in step S307, the application placement is determined to have failed in step S308. Finally, these processes are executed in step S309 until the loop for each application ends.

[0052] FIG. 17 is a flowchart showing an example of detailed processing of step S302 in FIG. 16. After this processing, processing is performed for a specific application. First, in step S320, communication requirements for each communication data of the application are obtained from the application requirement storage unit 21. Note that communication requirements are not obtained for applications that do not perform communication. Next, in step S321, it is checked whether the communication requirement data obtained includes communication requirements of the application, such as communication bandwidth and delay. If communication requirements are included (Yes), in step S322, the communication requirements of the application obtained from the application requirement storage unit 21 are used. If communication requirements are not included in step S321 (No), in step S323, predefined default communication requirements are used.

[0053] Fig. 18 is a flow chart showing an example of detailed processing of step S303 in Fig. 16. First, in step S330, communication performance information for each link on the in-vehicle network is acquired from the communication performance information storage unit 23. Next, in step S331, a loop is started for each link on the in-vehicle network. In step S332, it is checked whether or not any communication performance information is included in the communication performance information acquired for each link. If communication performance information is included (Yes), in step S333, the communication performance information acquired from the communication performance information storage unit 23 is used. If communication performance information is not included (No) in step S332, in step S335, it is assumed that no communication is taking place on the link. Once processing has been completed for all links, the loop ends in step S334.

[0054] FIG. 19 is a flowchart showing an example of detailed processing of step S305 in FIG. 16. Here, four values, communication bandwidth, delay, jitter, and packet loss rate, are calculated by numerical calculation as communication performance on the link for each application. Since the four values ​​can be calculated independently, the following steps can be executed either consecutively or in parallel. First, in step S340, a loop is started for each link constituting a route candidate. Steps S341 to S344 can be executed independently. In step S341, the communication bandwidth of the application is added to the bandwidth used on the link to calculate the communication bandwidth when the application is added. In step S342, the delay when the application is added is calculated by adding the packet length of the application to the delay on the link. In step S343, since the jitter is defined by the maximum packet length transmitted on the link, the jitter on the link is compared with the packet length of the application, and if the packet length of the application is greater than the jitter on the link, the jitter is updated to the packet length of the application. In step S344, since the packet loss rate occurs due to overflow of the transmission buffer on the link, the buffer usage on the link plus the packet length of the application is set as SUM, and if SUM is greater than the buffer size, the packet loss rate is calculated by the formula (SUM-buffer size) / SUM. In step S345, the loop is terminated for each link that constitutes the route candidate.

[0055] 20 shows a communication path list 120 output from the performance verification unit 26 and input to the setting application unit 27. The communication path list 120 holds a communication path 122 selected by the performance verification unit 26 for each application sequence 121.

[0056] FIG. 21 is a flowchart showing the operation of the setting application unit 27. First, in step S400, the included applications are extracted from the communication path list 120 received from the performance verification unit 26 to obtain an application list. Next, in step S401, the identification information of the applications included in the obtained application list is obtained from the application requirement holding unit 21. Next, in step S402, the communication path information is reconstructed, and a communication path setting table 130 is generated in which the identification information of the application through which the communication data passes and the next destination ECU of the communication data are associated with each other for each ECU. An example of the configuration of the communication path setting table 130 will be described with reference to FIG. 22. Next, in step S403, the process of step S404 is looped for each ECU in the communication path setting table 130. In step S404, the application identification information and the next destination ECU are set for the ECU. In step S405, the loop for the ECU in the communication path setting table 130 is ended. Finally, the applications included in the application list are arranged in the arrangement destination ECU. The destination ECU is the ECU that is at the beginning of the transmission data or the end of the reception data on the communication path of the application.

[0057] 22 shows an example of the configuration of the communication path setting table 130 used inside the setting application unit 27. The communication path setting table 130 holds, for an ECU column 131, application identification information 132 of an application through which communication data passes and a next destination ECU 133. Note that the destination of data received by an application in an ECU where the application is placed is expressed as a CPU.

[0058] With the above operations, the in-vehicle network system can place new apps in the ECU when they are added via OTA, taking into consideration the computational and storage resources in the ECU and the communication resources between ECUs. In addition, the same method can be used to place apps when updating existing apps via OTA.

[0059] (summary) In this embodiment, a network system in which an application is allocated to one of a plurality of computing devices 3, 9 present on a network so as to satisfy an execution requirement 53 of the application, includes an application requirement holding unit 21 which holds the execution requirement 53 and a communication requirement 64 of the application, an available resource information holding unit 20 which holds available resource information of the plurality of computing devices 3, 9, an application placement selection unit 24 which selects a computing device capable of executing the application from the plurality of computing devices 3, 9 based on the execution requirement 53 and the available resource information, and creates an application placement destination computing device candidate list 90, a topology information holding unit 22 which holds topology information indicating a communication connection relationship of the plurality of computing devices 3, 9, and a network system for storing the application. the communication path selection unit 25 which selects a communication path of the application when the application is placed on each computing device in the application placement destination computing device candidate list 90 based on the topology information, and creates a communication path candidate list 110; a performance verification unit 26 which verifies whether or not the communication requirement 64 is satisfied on each communication path in the communication path candidate list 110 based on the communication performance information and the communication requirement 64; and a setting application unit 27 which places the application on a computing device corresponding to the communication path verified by the performance verification unit 26 to satisfy the communication requirement 64 among the computing devices in the application placement destination computing device candidate list 90.

[0060] In addition, in this embodiment, a network management method for distributing an application to one of a plurality of computing devices 3, 9 present on a network so as to satisfy an execution requirement 53 of the application includes an application requirement holding step for holding the execution requirement 53 and a communication requirement 64 of the application, an available resource information holding step for holding available resource information of the plurality of computing devices 3, 9, an application placement selection step for selecting a computing device capable of executing the application from the plurality of computing devices 3, 9 based on the execution requirement 53 and the available resource information, and creating an application placement destination computing device candidate list 90, a topology information holding step for holding topology information indicating a communication connection relationship of the plurality of computing devices 3, 9, and the communication path selection step of selecting a communication path for the application when the application is placed on each computing device in the application placement destination computing device candidate list 90 based on the topology information to create a communication path candidate list 110; a performance verification step of verifying whether or not the communication requirement 64 is satisfied on each communication path in the communication path candidate list 110 based on the communication performance information and the communication requirement 64; and a setting application step of placing the application on a computing device corresponding to the communication path verified by the performance verification step to satisfy the communication requirement 64 among the computing devices in the application placement destination computing device candidate list 90.

[0061] According to this embodiment configured as described above, when placing an application on one of a plurality of computing devices 3, 9 existing on a network, the execution performance and communication performance of the application can be ensured by taking into consideration the computing resources of each computing device 3, 9 and the communication resources between the computing devices, thereby enabling the application to operate stably.

[0062] In addition, the communication requirement 64 and the communication performance information in this embodiment include one or more of the communication band, communication delay, communication jitter, and packet loss rate of the application. This makes it possible to define the communication requirement 64 and the communication performance information of the application.

[0063] Furthermore, the performance verification unit 26 in this embodiment verifies whether or not the communication requirements 64 are satisfied for each communication path in the communication path candidate list 110 by performing a numerical calculation based on the communication performance information and the communication requirements 64. This makes it possible to simply verify whether or not the communication requirements 64 are satisfied for each communication path in the communication path candidate list 110.

[0064] Furthermore, the performance verification unit 26 in this embodiment verifies whether or not the communication requirements 64 are satisfied for each communication path in the communication path candidate list 110 by performing a simulation based on the communication performance information and the communication requirements 64. It becomes possible to verify with high accuracy whether or not the communication requirements 64 are satisfied for each communication path in the communication path candidate list 110.

[0065] In this embodiment, the metadata 43 input to the network together with the application when the application is deployed includes execution requirements 53 including one or more of computational resources, storage resources, and specifications, communication specifications 58 including one or more of communication direction, communication partner, communication cycle, communication data size, and communication identification information, and communication requirements 64 including one or more of communication bandwidth, communication delay, communication jitter, and packet loss rate. This makes it possible to define the execution requirements 53, communication specifications 58, and communication requirements 64 of the application.

[0066] Moreover, the network in this embodiment is an in-vehicle network mounted on a vehicle, and the multiple arithmetic devices 3, 9 are multiple in-vehicle electronic control devices 3, 9 mounted on the vehicle. This makes it possible to stably operate a newly placed application on the in-vehicle network.

[0067] The in-vehicle device in this embodiment also includes the network system, which allows a newly installed application to stably operate in the in-vehicle device.

[0068] Furthermore, the communication requirements 64 in this embodiment include items related to sensor data output from the sensors 4 mounted on the vehicle, control data for controlling the vehicle, and intermediate data obtained during the process of deriving the control data from the sensor data. This makes it possible to define the communication requirements 64 according to the required performance of the vehicle-mounted device. EXAMPLES

[0069] In the first embodiment, the communication performance is estimated by numerical calculation. This method requires a small amount of calculation and is simple, but the accuracy of the estimation is low. Therefore, in the second embodiment, a method of estimating the communication performance by network simulation is shown as an alternative method.

[0070] The main configuration and operation flow of this embodiment are similar to those of the first embodiment, and only the differences from the first embodiment will be described below.

[0071] FIG. 23 is a configuration diagram of the performance verification unit 26 in the second embodiment. The performance verification unit 26 in this embodiment can be configured in two ways. FIG. 23(a) is a configuration diagram when a simulation is performed inside the vehicle. The performance verification unit 26 has a simulation unit 28 therein, which is used to perform performance verification by simulation. FIG. 23(b) is a configuration diagram when a simulation is performed outside the vehicle. Here, outside the vehicle means a computing resource other than the vehicle itself, such as a cloud, Multi-access Edge Computing (MEC), a roadside unit, or another vehicle. The performance verification unit 26 communicates with the simulation unit 28 installed outside the vehicle by wireless communication or the like, transmits necessary settings to the simulation unit 28, instructs the simulation unit 28 to execute a simulation, and receives the results from the simulation unit 28.

[0072] Fig. 24 is a flow chart showing the operation of step S305 in Fig. 16 among the operations of the performance verification unit 26 in the second embodiment. First, in step S500, a simulation setting is created. Next, in step S501, the simulation unit 28 is operated to execute a simulation. Finally, in step S502, a performance evaluation result is obtained for each section (link) of the route candidate from the simulation result. Here, the performance evaluation result includes the communication bandwidth, delay, jitter, packet loss rate, etc.

[0073] As described above, the present embodiment of the invention enables more accurate performance evaluation, and enables an increase in the number of accommodated applications and an improvement in the stability of application operation.

[0074] (summary) The network system performance verification unit 26 in this embodiment verifies whether or not the communication requirements 64 are satisfied by each communication path in the communication path candidate list 110 by performing a simulation based on the communication performance information and the communication requirements 64 .

[0075] According to the present embodiment configured as described above, it becomes possible to verify with high accuracy whether or not the communication requirement 64 is satisfied for each communication path in the communication path candidate list 110.

[0076] In addition, in the performance verification step of the network management method in this embodiment, whether or not each communication path in the communication path candidate list 110 satisfies the communication requirement 64 is verified by a simulation based on the communication performance information and the communication requirement 64, using a computer inside the vehicle. This makes it possible to perform a simulation even in an environment in which the network system cannot communicate with the outside.

[0077] Furthermore, in the performance verification step of the network management method in this embodiment, whether or not the communication requirements 64 are satisfied for each communication path in the communication path candidate list 110 is verified by a simulation based on the communication performance information and the communication requirements 64, using a computer outside the vehicle. This makes it possible to improve the accuracy of the simulation since resources for performing the simulation are not limited. EXAMPLES

[0078] In the first and second embodiments, the topology of the in-vehicle network is assumed to be fixed. However, the topology of the in-vehicle network may change due to the addition of a new device to the CAN or a communication interruption caused by a hardware abnormality, etc. Therefore, in the third embodiment, an in-vehicle network system capable of tracking such topology changes is shown.

[0079] Fig. 25 is a functional block diagram of an in-vehicle network system according to the third embodiment. Compared to Fig. 3, a topology change monitor 29 is added.

[0080] The topology change monitoring unit 29 monitors the state of the in-vehicle network by "bus failure" or "error state" in the case of CAN, and by using a method such as LLDP (Link Level Discovery Protocol) in the case of Ethernet. Here, the state of the in-vehicle network means whether or not the links on the in-vehicle network are in a state in which communication is possible normally. If the state is normal, no operation is performed. If an abnormality is detected, the information of the link is deleted from the topology information table 70 of the topology information storage unit 22 or marked as being in an abnormal state, and the link is not to be used. After that, the applications, including the applications already deployed, are relocated. In other words, the communication path selection unit 25, the performance verification unit 26, and the setting application unit 27 are operated, and application placement and communication paths are set up that avoid the link in the abnormal state.

[0081] (summary) The network system in this embodiment further includes a topology change monitor 29 that detects a change in the topology of the network and notifies the topology information holder 22 of the change.

[0082] According to the present embodiment configured as described above, even if the topology of the network changes, it is possible to allocate the application to the computing devices 3 and 9 so as to satisfy the execution requirement 53 and the communication requirement 64. EXAMPLES

[0083] In the first and second embodiments, when multiple applications are added by OTA, the order in which the applications are added is not taken into consideration. As a result, the application added first may consume resources within the ECU or communication resources between ECUs, making it impossible to add applications added later. Therefore, when the priorities of the applications differ, the high-priority application is not added.

[0084] Therefore, in the fourth embodiment, a device that performs application placement taking into consideration the priority of the applications is provided.

[0085] Fig. 26 shows an application requirement table 50 held by the application requirement holding unit 21 in the fourth embodiment. The difference from the first to third embodiments is that a priority column 69 is added to the communication specifications 58. In Fig. 26, the priority is set in eight stages from 0 to 7, with 0 being the lowest priority and 7 being the highest priority. Note that the execution requirements 53 and communication requirements 64 are the same as those in the first and third embodiments, and therefore descriptions of the individual columns are omitted.

[0086] Fig. 27 is a flowchart showing the operation of the application placement selection unit 24 in the fourth embodiment. The same processes as those in the flowchart (Fig. 9) in the first embodiment are given the same numbers. The only difference from the first to third embodiments is that the loop process of step S101 is changed to step S600. In step S600, a loop related to applications is performed in descending order of priority in the application requirement table 50 in this embodiment. As a result, the ECU placement and communication path are determined earlier for applications with higher priority.

[0087] (summary) In this embodiment, the application requirement holding unit 21 holds a priority for each application, and the application placement selection unit 24 creates an application placement destination computing device candidate list 90 in descending order of priority of the applications.

[0088] According to the present embodiment configured as above, it is possible to arrange applications in the computing devices 3 and 9 in descending order of priority. EXAMPLES

[0089] In the first to fourth embodiments, each communication requirement is treated with equal priority, but depending on the application, the degree to which the requirements must be satisfied may differ between communication requirements. Therefore, in the fifth embodiment, a configuration is shown in which communication requirements that should be particularly satisfied can be specified for each application.

[0090] Fig. 28 shows an application requirement table 50 held by the application requirement holding unit 21 in the fifth embodiment. The difference from the first to fourth embodiments is that priority columns 69a to 69d for each item of the communication requirement are added. In Fig. 28, priority is set in eight stages from 0 to 7, with 0 being the lowest priority and 7 being the highest priority. Using the priority for each item of the communication requirement, applications can be arranged to satisfy communication requirements that should be particularly satisfied for each application.

[0091] Fig. 29 is a flowchart showing the operation of the performance verification unit 26. The same processes as those in the flowchart (Fig. 16) of the first embodiment are given the same numbers. The difference from the first embodiment is that step S306 is changed to step S700, and that instead of immediately determining that the application placement has failed in step S308 after step S307 is completed, the lowest priority item is removed from the communication requirements in steps S700 and S701 and application placement is then attempted again.

[0092] In step S700, it is determined whether the application communication performance evaluation result indicates that the application communication performance satisfies the communication requirements with a priority level greater than 0. If it satisfies the requirements (Yes), the application placement is deemed successful and steps S310 and onward are executed. If it does not satisfy the requirements (No), the loop for the route candidate list is terminated in step S307.

[0093] In step S701, the priority of each communication requirement of the application is checked from application requirement table 50. If the priority value of two or more communication requirements is greater than 0, it is determined that the communication requirement with the lowest priority greater than 0 can be excluded. If it is determined that it can be excluded in step S701 (Yes), in step S702, the priority of the communication requirement determined to be excludable in step S700 is overwritten with 0. If it is determined that it cannot be excluded in step S701 (No), the process proceeds to step S308, and the application deployment is deemed to have failed.

[0094] As a result, it is possible to specify communication requirements that should be particularly satisfied, and to realize an application placement that satisfies the requirements.

[0095] (summary) In this embodiment, the application requirement storage unit 21 stores a priority for each item of the application's communication requirements 64, and when one or more items of the communication requirements 64 are not satisfied, the performance verification unit 26 excludes the item with the lowest priority from the communication requirements 64 and re-verifies whether the communication requirements 64 are satisfied.

[0096] According to the present embodiment configured as described above, by excluding items with low priority from the communication requirements 64 of the applications, it becomes possible to allocate more applications to the computing devices 3 and 9.

[0097] Although the embodiments of the present invention have been described above in detail, the present invention is not limited to the above-mentioned embodiments, and various modifications are included. For example, the above-mentioned embodiments have been described in detail to easily explain the present invention, and the present invention is not necessarily limited to those having all of the configurations described. In addition, it is possible to add a part of the configuration of one embodiment to the configuration of another embodiment, and it is also possible to delete a part of the configuration of one embodiment, or to replace it with a part of another embodiment. [Explanation of symbols]

[0098] 1...vehicle, 2...gateway, 3, 3a to 3d...domain ECU (arithmetic unit, on-board electronic control unit), 4, 4a to 4d...sensor, 5, 5a to 5d...actuator, 6, 6a to 6d...link, 7...TCU, 8...central ECU (arithmetic unit, on-board electronic control unit), 9, 9a to 9d...zone ECU (arithmetic unit, on-board electronic control unit), 10...shared link, 11...CPU, 12...memory, 13...network switch, 20...free resource information storage unit, 21...application requirement storage unit, 22...topology information storage unit, 23...communication Performance information storage unit, 24... application placement selection unit, 25... communication path selection unit, 26... performance verification unit, 27... setting application unit, 28... simulation unit, 29... topology change monitoring unit, 30... ECU free resource information table, 31... ECU column, 32... computing resource column, 33... memory resource column, 34... spec column, 40... OTA data, 41... header, 42... application data, 43... metadata, 50... application requirement table, 51... application column, 52... deployment flag, 53... execution requirement, 54... communication ID, 55... computing resource column, 56...Memory resource column, 57...Spec column, 58...Communication specification, 59...Communication direction column, 60...Communication partner column, 61...Communication cycle column, 62...Packet size column, 63...Application identification information, 64...Communication requirements, 65...Communication bandwidth column, 66...Communication delay column, 67...Jitter column, 68...Discard rate column, 69,69a~69d...Priority column, 70...Topology information table, 71...Link column, 72...Type column, 73...Connection information column, 80...Communication performance information table, 81...Link column, 82...Communication direction, 83...Total bandwidth column, 84...Bandwidth column, 85...Delay time column, 8 6...jitter column, 87...discard rate column, 88...buffer usage column, 90...list of candidate ECUs for application placement (list of candidate computing devices for application placement), 91...application column, 92...destination ECU candidates, 100...search list, 101...phase, 102...candidate communication path, 103...state, 110...candidate communication path list, 111...application column, 112...candidate communication path, 120...communication path list, 121...application column, 122...communication path, 130...communication path setting table, 131...ECU column, 132...application identification information, 133...destination ECU.

Claims

1. A network system that allocates an application to any one of a plurality of computing devices on a network so as to satisfy an execution requirement of the application, an application requirement storage unit that stores execution requirements and communication requirements of the application; an available resource information storage unit that stores available resource information of the plurality of arithmetic devices; an application placement selection unit that selects a computing device capable of executing the application from among the plurality of computing devices based on the execution requirements and the available resource information, and creates a list of candidate computing devices where the application is placed; A topology information storage unit that stores topology information indicating a communication connection relationship of the plurality of arithmetic devices; a communication performance information storage unit that stores communication performance information of each link of the network; a communication path selection unit that selects a communication path for the application when the application is placed on each computing device in the application placement destination computing device candidate list based on the topology information and creates a communication path candidate list; a performance verification unit that verifies whether or not each communication path in the communication path candidate list satisfies the communication requirements based on the communication performance information and the communication requirements; a setting application unit that deploys the application to a computing device corresponding to a communication path verified by the performance verification unit to satisfy the communication requirements, among the computing devices in the application deployment destination computing device candidate list. A network system comprising:

2. 2. The network system according to claim 1, The communication requirements and the communication performance information include at least one of a communication band, a communication delay, a communication jitter, and a packet loss rate of the application. A network system comprising:

3. 2. The network system according to claim 1, The performance verification unit verifies whether or not the communication requirements are satisfied by each communication path in the communication path candidate list by performing a numerical calculation based on the communication performance information and the communication requirements. A network system comprising:

4. 2. The network system according to claim 1, The performance verification unit verifies whether or not the communication requirements are satisfied by each communication path in the communication path candidate list by performing a simulation based on the communication performance information and the communication requirements. A network system comprising:

5. 2. The network system according to claim 1, The network may further include a topology change monitor that detects a change in the topology of the network and notifies the topology information storage unit of the change. A network system comprising:

6. 2. The network system according to claim 1, the application requirement storage unit stores a priority for each of the applications; The application placement selection unit creates the application placement destination computing device candidate list in descending order of priority of the applications. A network system comprising:

7. 2. The network system according to claim 1, the application requirement storage unit stores a priority for each item of the communication requirements; When one or more of the communication requirements are not satisfied, the performance verification unit removes the lowest priority item from the communication requirements and verifies again whether the communication requirements are satisfied. A network system comprising:

8. 2. The network system according to claim 1, The metadata input to the network together with the app when the app is deployed includes: The execution requirements include one or more of computational resources, memory resources, and specifications; and A communication specification including at least one of a communication direction, a communication partner, a communication cycle, a communication data size, and communication identification information; The communication requirements include at least one of a communication band, a communication delay, a communication jitter, and a packet loss rate. A network system comprising:

9. 2. The network system according to claim 1, The network is an in-vehicle network installed in a vehicle, The plurality of arithmetic units are a plurality of on-board electronic control units mounted on the vehicle. A network system comprising:

10. The network system according to claim 9 is provided.

13. An in-vehicle device comprising:

11. 10. The network system according to claim 9, The communication requirements include items related to sensor data output from a sensor mounted on the vehicle, control data for controlling the vehicle, and intermediate data obtained during a calculation to obtain the control data from the sensor data. A network system comprising:

12. 1. A network management method for allocating an application to one of a plurality of computing devices present on a network so as to satisfy an execution requirement of the application, comprising: an application requirement storage step of storing execution requirements and communication requirements of the application; a free resource information holding step of holding free resource information of the plurality of arithmetic devices; an application placement selection step of selecting a computing device capable of executing the application from among the plurality of computing devices based on the execution requirements and the available resource information, and creating a list of candidate computing devices for application placement; A topology information storage step of storing topology information indicating a communication connection relationship of the plurality of arithmetic devices; a communication performance information holding step of holding communication performance information of each link of the network; a communication path selection step of selecting a communication path for the application when the application is placed on each computing device in the application placement destination computing device candidate list based on the topology information, and creating a communication path candidate list; a performance verification step of verifying whether or not each communication path in the communication path candidate list satisfies the communication requirements based on the communication performance information and the communication requirements; and a setting application step of distributing the application to a computing device corresponding to a communication path verified to satisfy the communication requirements by the performance verification step, among the computing devices in the application placement computing device candidate list. A network management method comprising:

13. 13. The network management method according to claim 12, The network is an in-vehicle network installed in a vehicle, The plurality of arithmetic units are a plurality of on-board electronic control units mounted on the vehicle. A network management method comprising:

14. 14. The network management method according to claim 13, In the performance verification step, whether or not the communication requirements are satisfied by each communication path in the communication path candidate list is verified by a simulation based on the communication performance information and the communication requirements using a computer in the vehicle. A network management method comprising:

15. 14. The network management method according to claim 13, In the performance verification step, whether or not the communication requirements are satisfied for each communication path in the communication path candidate list is verified by a simulation based on the communication performance information and the communication requirements using a computer outside the vehicle. A network management method comprising:

Images