Network system and network management method

Abstract

The purpose of the present invention is to provide a network system and a network management method capable of performing application configuration in which computing resources of computing devices existing on a network and communication resources between the computing devices are considered. To this end, the present invention is provided with: a communication path selection unit (25) that, on the basis of topology configuration information indicating the communication connection relationship between a plurality of computing devices (3, 9), selects a communication path for an application program when the application program is arranged in each of the computing devices in an application program arrangement target computing device candidate list (90), and generates a communication path candidate list (110); a performance verification unit (26) that verifies, on the basis of the communication performance information and the communication requirement (64), whether each communication path in the communication path candidate list (110) can satisfy the communication requirement (64); and a setting application unit (27) that arranges the application program in a computing device corresponding to the communication path that has been verified by the performance verification unit (26) to satisfy the communication requirement (64) among the computing devices in the application program arrangement target computing device candidate list (90).

Description

Technical Field

[0001] The present invention relates to a network system and a network management method for configuring application programs for a plurality of computing devices existing on a network. Background Art

[0002] Automated driving and safe driving assistance technologies are advancing and will continue to evolve in the future. Automobile manufacturers are studying how to apply these technological advances not only to new vehicles, but also to vehicles that have already been sold. Technologies for this purpose include OTA (Over-the-Air) update technology.

[0003] In OTA, new or updated in-vehicle applications (hereinafter referred to as applications) are released from a server such as the cloud to the vehicle via a wireless network. The released applications are deployed to the vehicle system and applied and executed on the vehicle side.

[0004] The vehicle system is a structure that connects multiple electronic control units (ECUs) via a network. Here, ECU is used as a general term for sensors such as cameras, actuators that operate engines and steering, and devices that perform calculations for control. The ECU sends and receives data via the vehicle network, and uses applications to calculate the data to obtain information for vehicle control. The vehicle network is loaded by sending and receiving data, but the load status of the vehicle network varies depending on the configuration status of the application.

[0005] Here, when a new application is added using OTA, the vehicle system needs to select an ECU that executes the new application. Patent document 1 discloses a method for selecting an ECU that executes an application when an application is added. An in-vehicle system having multiple ECUs capable of installing additional applications acquired by an application acquisition unit comprises a requirement determination unit, a resource determination unit, and a selection unit. The requirement determination unit determines the resources required by the additional application, i.e., the required resources. The resource determination unit determines the resources that each ECU can provide, i.e., the provided resources. The selection unit selects an ECU whose provided resources meet the required resources as the installation target of the additional application.

[0006] Prior art literature

[0007] Patent Literature

[0008] Patent Document 1: Japanese Patent Application Publication No. 2020-86522 Summary of the invention

[0009] Problems to be solved by the invention

[0010] In the invention described in Patent Document 1, the ECU to which the application is to be deployed can be selected based on the computational resources of the ECU, but application deployment cannot be performed in consideration of communication resources between ECUs, such as the load status of the in-vehicle network.

[0011] The present invention has been made in view of the above problems, and an object of the present invention is to provide a network system and a network management method capable of configuring applications in consideration of computing resources of each computing device existing on the network and communication resources between computing devices.

[0012] Technical solutions to solve problems

[0013] In order to achieve the above-mentioned purpose, the present invention is a network system that configures an application to any one of a plurality of computing devices existing on a network in a manner that satisfies the execution requirements of the application, and comprises: an application requirement storage unit that stores the execution requirements and communication requirements of the application; an idle resource information storage unit that stores idle resource information of the plurality of computing devices; an application configuration selection unit that selects a computing device capable of executing the application from the plurality of computing devices based on the execution requirements and the idle resource information, and generates a candidate list of target computing devices for application configuration; a topology information storage unit that stores topology information representing the communication connection relationship between the plurality of computing devices; and a topology information storage unit that stores the topology information of the communication connection relationship between the plurality of computing devices. a communication performance information storage unit for storing the communication performance information of each link of the network; a communication path selection unit, which generates a communication path candidate list by selecting, based on the topology information, the communication path of the application when the application is configured in each computing device in the application configuration target computing device candidate list; a performance verification unit, which verifies whether the communication requirements can be met by each communication path in the communication path candidate list based on the communication performance information and the communication requirements; and a setting application unit, which configures the application in the computing device in the application configuration target computing device candidate list that corresponds to the communication path that has been verified by the performance verification unit to meet the communication requirements.

[0014] In addition, the present invention is a network management method for configuring an application to any one of a plurality of computing devices existing on a network in a manner that satisfies the execution requirements of the application, comprising: an application requirement saving step for saving the execution requirements and communication requirements of the application; an idle resource information saving step for saving idle resource information of the plurality of computing devices; an application configuration 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 idle resource information, and generating a candidate list of target computing devices for application configuration; a topology information saving step for saving topology information representing the communication connection relationship of the plurality of computing devices; and a network configuration 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 idle resource information. The step of storing the communication performance information of each link of the network; the step of selecting a communication path, based on the topology information, selecting the communication path of the application when the application is configured in each computing device in the candidate list of target computing devices for the application to generate a candidate list of communication paths; the step of verifying whether the communication requirements can be met by each communication path in the candidate list of communication paths based on the communication performance information and the communication requirements; and the step of setting an application, configuring the application in the computing device in the candidate list of target computing devices for the application to which the communication path corresponding to the communication path verified to meet the communication requirements in the performance verification step.

[0015] Effects of the Invention

[0016] According to the present invention, when an application is configured to any one of a plurality of computing devices existing 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 run stably. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 It is a diagram of the electrical and electronic architecture of an in-vehicle device equipped with the in-vehicle network system of the present invention.

[0018] Figure 2 It is the hardware structure diagram of domain ECU, regional ECU, central ECU and gateway.

[0019] Figure 3 It is a functional block diagram of the vehicle network system of the present invention.

[0020] Figure 4 Indicates the ECU internal free resource information table stored in the free resource information storage unit.

[0021] Figure 5 This figure shows an example of the structure of OTA data received by the application requirement storage unit via the TCU.

[0022] Figure 6 This shows the application requirement table stored in the application requirement storage unit.

[0023] Figure 7 Indicates the topology information table stored in the topology information storage unit.

[0024] Figure 8 Indicates the summary of the communication performance information table stored in the communication performance information storage unit.

[0025] Fig. 9 This is a flowchart showing the operation of the application configuration selection unit.

[0026] Fig.10 This shows the output of the application configuration selection unit, that is, the application configuration target ECU candidate list.

[0027] Fig.11 This is a flowchart showing the operation of the communication path selection unit.

[0028] Fig.12 Yes means Fig.11 Flowchart of an example of detailed processing of step S209 in FIG.

[0029] Fig.13 Yes means Fig.12 Flowchart of an example of detailed processing of step S221.

[0030] Fig.14 Represents network execution for regional architecture Fig.13 An example of the result of the processing.

[0031] Fig.15 The communication path candidate list of the application program output from the communication path selection unit and input to the performance verification unit is shown.

[0032] Fig.16 This is a flowchart showing the operation of the performance verification unit.

[0033] Fig.17 Yes means Fig.16 Flowchart of an example of detailed processing of step S302 in .

[0034] Fig.18 Yes means Fig.16 Flowchart of an example of detailed processing of step S303 in .

[0035] Fig.19 Yes means Fig.16 Flowchart of an example of detailed processing of step S305.

[0036] Fig. 20This shows the communication path list output from the performance verification unit and input to the setting application unit.

[0037] Fig.21 This is a flowchart showing the operation of the setting application unit.

[0038] Fig. 22 A configuration example of a communication path setting table used in the setting application section is shown.

[0039] Fig.23 It is a structural diagram of the performance verification unit in the second embodiment.

[0040] Fig.24 The operation of the performance verification unit in the second embodiment is shown in FIG. Fig.16 Flowchart of the action of step S305 in FIG.

[0041] Fig.25 It is a functional block diagram of the in-vehicle network system in the third embodiment.

[0042] Fig.26 FIG. 2 shows an application requirement table stored in the application requirement storage unit in the fourth embodiment.

[0043] Fig. 27 FIG. 2 shows an application requirement table stored in the application requirement storage unit in the fourth embodiment.

[0044] Fig.28 FIG. 2 shows an application requirement table stored in the application requirement storage unit in the fifth embodiment.

[0045] Fig.29 This is a flowchart showing the operation of the performance verification unit. DETAILED DESCRIPTION

[0046] Hereinafter, embodiments of the present invention will be described using the drawings. In each of the drawings, the same reference numerals are given to the same elements, and duplicate descriptions are omitted as appropriate.

[0047] Example 1

[0048] Hereinafter, a first embodiment of the in-vehicle network system will be described using the drawings.

[0049] Figure 1 2 is a diagram showing an electrical and electronic architecture of an in-vehicle device equipped with the in-vehicle network system of the present invention. Here, two structures are cited as representative electrical and electronic architectures, but the application targets of the present invention are not limited to these.

[0050] Figure 1(a) is a diagram showing the logical structure of an architecture called a domain architecture. This is a method of classifying the ECUs (on-board electronic control units) inside the vehicle 1 into functional categories called domains and systematically connecting the ECUs belonging to the same domain. For each domain, a domain ECU 3 is set to uniformly control the domain. In addition, in order to communicate between domains, the domain ECUs 3 are connected to each other via a gateway 2. For example, the domain includes an ADAS (Advanced Driver Assistance System) domain responsible for safe driving assistance, a PT / CH (Power Train / Chassis) domain that controls the front and rear directions and left and right directions of the vehicle, a BODY domain that controls electronic equipment such as power windows, and an Infotainment domain that controls navigation and audio. For each domain, 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 set. In the domain ECU 3, 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 via links 6a to 6d (hereinafter collectively referred to as 6) suitable for each domain, such as CAN (Controller Area Network) and LIN (Local Interconnect Network). There are cases where multiple ECUs 4 and 5 are connected to a single link 6. In addition, the gateway 2 is connected to a TCU (Telematics Control Unit) 7 that communicates with a server and cloud outside the vehicle via a wireless network.

[0051] The functional requirements of domain ECU performance may differ for each domain. For example, ADAS ECU and infotainment ECU use high-performance hardware to process large amounts of data such as video. On the other hand, PT / CH ECU uses high-reliability hardware because it is directly related to safety.

[0052] Figure 1(b) is a diagram showing the physical structure of an architecture called a regional architecture. This is a method of classifying ECUs 4 and 5 according to spatial positions inside the vehicle 1 and connecting them to regional ECUs 9a to 9d (hereinafter collectively referred to as 9) that uniformly control the positions. It is composed of one or more regional ECUs 9, a central ECU 8 connected to the regional ECUs 9 and executing multiple applications across multiple domains, and sensors 4 and actuators 5 connected to the regional ECUs 9. As the name suggests, the regional ECUs 9 are configured to correspond to positions (regions) such as the front, back, left, and right in the vehicle, and are connected to sensors 4 or actuators 5 or both of them that are close to their installation positions. In addition, the regional ECUs 9 are connected to other regional ECUs 9 via a shared link 10 that uses a common communication method between domains. It is assumed that the common communication method is a switching network composed of Ethernet (registered trademark). TCU 7 is connected to the central ECU 8 or any regional ECU 9, Figure 1 (b) shows an example of connection with the central ECU 8.

[0053] Figure 2 It is the hardware structure of the domain ECU 3 , the regional ECU 9 , the central ECU 8 and the gateway 2 . Figure 2 The thick line in the figure represents the connection method between the communication devices 2 in the regional architecture or the domain architecture, that is, the common communication method, and the thin line represents other communication methods.

[0054] Figure 2 (a) is the hardware structure of the domain ECU 3. The domain ECU 3 has a CPU (Central Processing Unit) 11 for processing information received from the sensor 4 and the actuator 5 or the gateway 2 and a memory 12 for storing data used for calculations by the CPU 11. The link for connecting to the gateway 2 and the link for connecting to the sensor 4 and the actuator 5 are led out from the CPU 11.

[0055] Figure 2 (b) is the hardware structure of the regional ECU 9. The regional ECU 9 has a network switch 13 that accommodates a shared link 10 for connecting to other regional ECUs 9 or connecting to the sensor 4 and the actuator 5. In addition, the regional ECU 9 has a CPU 11 for processing information received from the sensor 4 and the actuator 5, or the shared link 10, and is connected to the network switch 13. In addition, the CPU 11 is also connected to the memory 12. If the sensor 4 and the actuator 5 support a common communication method, they can also be directly connected to the network switch 13. If the sensor 4 and the actuator 5 do not support a common communication method, they can be connected to the CPU 11 first and then switched to the common communication method.

[0056] Figure 2(c) is a hardware structure of the gateway 2 in the domain architecture. The gateway 2 has a network switch 13 connected to the CPU 11 , the memory 12 , and the domain ECU 3 .

[0057] Figure 2 (d) is a hardware structure of the central ECU 8 in the regional architecture. The central ECU 8 has a substantially similar structure to the gateway 2 , and includes a network switch 13 for connecting to the CPU 11 , the memory 12 , and the regional ECU 9 .

[0058] Figure 3 is a functional block diagram of the vehicle network system of the present invention. In addition, the functional block diagram can be used as Figure 1 The independent device implementation not shown in the figure can also be implemented as software. Figure 1 When implemented as software, it can be executed by any ECU in Figure 1 Any ECU in the vehicle can execute without compromising functionality, but typically, in order to manage the entire vehicle network, it is assumed that it is installed in the gateway if it is a domain architecture and in the central ECU if it is a regional architecture.

[0059] The present invention is composed of functional modules including a free 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 configuration selection unit 24, a communication path selection unit 25, a performance verification unit 26, and a setting application unit 27.

[0060] The free resource information storage unit 20 regularly collects and stores the resource status inside each ECU, for example, information on the free capacity of the CPU and the free capacity of the memory.

[0061] The application program requirement storage unit 21 stores the execution requirements of the application programs executed in each ECU of the vehicle. The requirements of the application programs pre-installed when the vehicle is shipped in the application program requirement storage unit 21 are stored at the factory, and the requirements of the application programs added by OTA are received together with the OTA data via the TCU 7. For a specific example of the requirements, use Figure 6 illustrate.

[0062] The topology information storage unit 22 stores topology information indicating the connection relationship of the in-vehicle network.

[0063] The communication performance information storage unit 23 stores performance information of currently performed communication, that is, the communication resource status between ECUs, for each link in the vehicle-mounted network.

[0064] The application placement selection unit 24 determines the application placement target ECU candidates based on the resource status in each ECU acquired from the free resource information storage unit 20 and the execution requirement information on the application's ECU internal resources (computation resources) acquired from the application requirement storage unit 21 .

[0065] The communication path selection unit 25 determines communication path candidates for communication performed by the application based on the application configuration target ECU candidates determined by the application configuration selection unit 24, the application communication target information obtained from the application requirement storage unit 21, and the topology information of the vehicle network obtained from the topology information storage unit 22.

[0066] The performance verification unit 26 verifies the communication performance of the application when the communication path candidate is selected, based on the communication requirements of the application acquired from the application requirement storage unit 21 and the communication performance information acquired from the communication performance information storage unit 23. From the path candidates for which the application satisfies the communication performance as a result of the verification, one communication path to be actually used is selected.

[0067] The setting application unit 27 applies the communication path determined by the performance verification unit 26 to the vehicle network. To do this, the application data transmission and reception destination address etc. are acquired from the application requirement storage unit 21, and a transmission rule is set for the network switch 13 inside the ECU on the path.

[0068] The following describes the details of each functional module.

[0069] Figure 4 The ECU free resource information table 30 is stored in the free resource information storage unit 20. The ECU free resource information table 30 stores information in a calculation resource column 32, a storage resource column 33, and a specification column 34 in an ECU column 31. The specification indicates characteristics of the ECU, such as high performance and high reliability.

[0070] Figure 5 The OTA data 40 is a structural example of the OTA data 40 received by the application element storage unit 21 via the TCU 7. The OTA data 40 includes a header 41 including the application ID, version information, etc., application data 42 storing the code of the application body in binary form, etc., and metadata 43 about the application referred to in the present invention. The metadata 43 is stored in correspondence with the communication ID 54, which is the identification number of the communication in the application. Figure 6The same execution requirement 53, communication specification 58 and communication requirement 64 as the application requirement table 50 described in FIG. 10A. When an application performs multiple communications, there are 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 as follows: Figure 6 Same as Figure 6 Explain together.

[0071] Figure 6 The application requirement table 50 is stored in the application requirement storage unit 21. The application requirement table 50 stores, in an application column 51 storing the ID of the application, a configuration flag 52 indicating that the application has been configured in a certain ECU, an execution requirement 53 storing the requirements regarding the internal resources (computing resources) of the ECU, a communication specification 58 storing the specifications of the communication between ECUs, and a communication requirement 64 storing the requirements regarding the communication resources between ECUs. The execution requirement 53 includes a computing resource column 55, a storage resource column 56, and a specification column 57. In addition, the communication specification 58 includes a communication direction column 59 indicating the transmission or reception from the application's point of view, which is a requirement for the application regarding the communication between ECUs, a communication object column 60 that specifies the communication object of the application, a communication cycle column 61, a packet size column 62, and application identification information 63, which is information used to specify the application based on the communication packet. Application identification information includes, for example, CAN ID of CAN, source / destination MAC addresses in Ethernet, source / destination IP addresses in IP (Internet Protocol), source / destination port numbers in TCP (Transmission Control Protocol) or UDP (User Datagram Protocol), etc. Communication requirements 64 include a communication bandwidth column 65, a communication delay column 66, a jitter column 67, and a loss rate column 68. In addition, when a single application performs multiple communications, the application uses multiple rows to express the multiple communications, such as application A3. In addition, when the application does not perform communication, the application can only set the execution requirements, such as application A4.

[0072] Figure 7 The topology information table 70 stored in the topology information storage unit 22 is shown. The topology information table 70 includes a link column 71 indicating each link connecting ECUs in the vehicle network, a type column 72 recording whether the link is a bus type (a method in which multiple ECUs are connected to a common communication path) or a mesh type (a method in which one ECU is connected to other ECUs one-to-one), and a connection information column 73 storing the ID of the ECU connected to the link.

[0073] Figure 8 A part of the communication performance information table 80 stored in the communication performance information storage unit 23 is extracted. The communication performance information table 80 has a communication direction 82 in a link column 81, and has a total bandwidth column 83 indicating the total bandwidth of the link, a used bandwidth column 84 indicating the bandwidth currently used by the existing application, 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 for each link and the communication direction.

[0074] Fig. 9 This is a flowchart showing the operation of the application configuration selection unit 24. This flowchart starts with the update of the application requirement table 50 caused by 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. Then, in S101, the following processing is looped for each application registered in the application requirement table 50. In step S102, the configured flag of the target application is investigated. If it is configured (yes), no processing is performed and the processing of the next application is transferred. If it is not configured (no), the processing after step S103 is performed. In step S103, whether the execution requirements of the target application are registered in the application requirement table 50 is investigated. If it is not registered (no), in step S108, the pre-defined ECU candidate list is sorted in order from large to small in total resources, and the configuration target ECU candidate of the application is used as the application, and the processing of the next application is transferred. If it is registered (yes), the following processing is performed. In step S104, the idle resource information table 30 in the ECU is obtained from the idle resource information storage unit 20. In the subsequent step S105, an ECU in the idle resource information table 30 in the ECU is selected, and the computing resources and storage resources are greater than the computing resources and storage resources in the execution requirements of the application, and the ECU that meets the specifications required by the application is selected, thereby selecting the ECU that meets the execution requirements required by the application, and generating a configuration target ECU candidate list. Then, in step S106, the ECU candidate list is sorted in order from large to small in terms of idle resources as configuration target ECU candidates for the application. In step S107, the end of the application cycle is judged, and the present process is terminated when all applications have been processed.

[0075] Fig.10 The output of the application configuration selection unit 24 is the application configuration target ECU candidate list 90. The application configuration target ECU candidate list 90 stores configuration target ECU candidates 92 for each application column 91. The application configuration target ECU candidate list 90 is an input to the next communication path selection unit 25.

[0076] Fig.11This is a flowchart showing the actions of the communication path selection unit 25. This flowchart starts with the input of the application configuration target ECU candidate list 90 from the application configuration selection unit 24. First, in step S200, the application configuration target ECU candidate list 90 is obtained from the application configuration selection unit 24. In step S201, the topology information table 70 of the vehicle network is obtained from the topology information storage unit 22. In step S202, it is confirmed whether the topology information of the vehicle network is included in the topology information table 70. If it is not included (No), the pre-defined default topology information is used in step S204. In step S202, if the topology information is included (Yes), the topology information of the topology information table 70 is used in step S203.

[0077] In the subsequent step S205, the following loop processing is performed on each application in the application column 91 of the application configuration target ECU candidate list 90. First, in step S206, the communication object information of each application's communication data (packet) is obtained from the application requirement storage unit 21. Here, the communication object information is a general term for the data source in the received data and the data destination in the sent data. In step S207, the above communication object information is investigated. If the information about the communication object is not included (No), it is determined that no communication is performed, and the processing is transferred to the next application. If the information about the communication object is included in step S207 (Yes), proceed to step S208 and beyond.

[0078] In step S208, a loop for configuring the target ECU candidates 92 of the application configuration target ECU candidate list 90 is started. In step S209, a path candidate from the data transmission source to the receiving target is obtained by a separately defined process. When the process of S209 is completed for all the configuration target ECU candidates, the loop for configuring the target ECU candidates is ended in S210.

[0079] When the processing is completed for all the application programs in the application placement target ECU candidate list 90 , the loop ends in step S211 , and the processing of the communication path selection unit 25 ends.

[0080] Fig.12 Yes means Fig.11Flowchart of an example of detailed processing of step S209 in FIG. First, in step S220, a loop is started for each communication belonging to the application. In the subsequent step S221, a path from the source ECU to the destination ECU is searched by a separately defined process. Then, in step S222, when the destination ECU is reached, the searched path is added to the path candidate list. When the processing of all communication data is completed, the loop is terminated in step S223, and this process is terminated.

[0081] Fig.13 Yes means Fig.12 Here, the path from the source ECU to the target ECU is searched using a breadth-first search, but other search algorithms such as a depth-first search can also be used. Fig.14 The search list 100 used in the present search process is shown as an example. The search list 100 includes a stage 101 indicating a search stage, a communication path candidate 102 indicating a searched path candidate from a transmission source ECU to a reception destination ECU, and a state 103 indicating a state of the communication path candidate 102 .

[0082] First, in step S230, the variable "stage" is set to 0, the state is set to unfinished, and the source ECU is selected and added to the first entry of the search list. In the subsequent step S231, the stage is increased by 1. Then, in step S232, the ECU directly connected to the ECU at the end of the path candidate in the communication path candidate 102 whose state is unfinished in the search list of the previous stage is extracted, and added to the end of the communication path candidate 102, and added to the search list of the current stage.

[0083] In step S233, a loop is started for the search list 100 of the current stage generated as described above. In step S234, the state of the communication path candidate 102 is checked. First, when the end of the communication path candidate 102 is the receiving target ECU (S234a), the state 103 of the communication path is set to "reached the receiving target" in step S235, and added to the output of the communication path selection unit 25, that is, the path candidate list in step S236. Next, when the end of the communication path candidate 102 is the searched ECU in step S234 (S234b), that is, when the communication path candidates include a plurality of the same ECU, the state 103 of the communication path candidate is set to "reached searched" in step S237. In step S234, in other cases (S234c), the state 103 of the communication path candidate is set to incomplete in step S238. Then, when the processing is completed until the end of the search list of the current stage, the loop ends in step S239.

[0084] Finally, in step S240, it is confirmed whether there is an incomplete communication path candidate 102 in the search list of the current stage. If there is an incomplete communication path candidate 102, the process returns to step S231 to continue. If there is no incomplete communication path candidate 102, that is, if the search for the topology structure of the vehicle network is completed, the process ends.

[0085] Fig.14 Represents network execution for regional architecture Fig.13 An example of the result of the processing. A list of communication path candidates is generated with the addition of the ECUs that can be reached next in the current stage for the items whose status is incomplete in the previous stage. Then, in stage 5, the status becomes the case of reaching the receiving target (the position of ECU C indicated by underline) or reaching the searched (the position of ECU A indicated by italics), and the search is completed.

[0086] Fig.15 The communication path candidate list 110 of the application is output from the communication path selection unit 25 and input to the performance verification unit 26. The communication path candidate list 110 of the application stores communication path candidates 112 corresponding to the application list 111.

[0087] Fig.161 is a flowchart showing the operation of the performance verification unit 26. First, in step S300, the communication path candidate list 110 of the application is received from the communication path selection unit 25. Then, in step S301, the application recorded in the communication path candidate list 110 is looped. Then, in step S302, the communication requirement information of the application is obtained from the application requirement storage unit 21 using a separately defined process. Then, in step S303, the communication performance information of each link in the vehicle network is obtained from the communication performance information storage unit 23 using a separately defined process. Then, in step S304, the path candidates corresponding to the application recorded in the communication path candidate list 110 are looped. Then, in step S305, the communication performance of the application when using the selected path is evaluated based on the communication performance information of the path candidates and the communication requirements of the application using a separately defined process. In step S306, the evaluation result is judged, and if the communication requirements of the application are not satisfied (No), the loop on the path candidate list is continued. If there is a communication path that satisfies the communication requirements of the application in step S306 (yes), the configuration of the application is deemed to be successful in step S310, and the communication path information is output to the setting application unit 27. Then, in step S311, the information of the free resource information storage unit 20 and the communication performance information storage unit 23 is updated. If there is no communication path that satisfies the communication requirements of the application and the loop ends in step S307, the configuration of the application is deemed to have failed in step S308. Finally, in step S309, these processes are performed until the loop of each application ends.

[0088] Fig.17 Yes means Fig.16 Flowchart of an example of detailed processing of step S302 in . This processing is about processing of a specific application. First, in step S320, communication requirements are obtained for each communication data of the application from the application requirement storage unit 21. In addition, communication requirements are not obtained for applications that do not communicate. Then, in step S321, it is investigated whether the acquired communication requirement data includes communication requirements of the application such as communication bandwidth and delay. If the communication requirements are included (yes), the communication requirements of the application acquired from the application requirement storage unit 21 are used in step S322. If the communication requirements are not included in step S321 (no), the pre-defined default communication requirements are used in step S323.

[0089] Fig.18 Yes means Fig.16Flowchart of an example of detailed processing of step S303 in . First, in step S330, the communication performance information in each link in the vehicle network is obtained from the communication performance information storage unit 23. Then, in step S331, a loop is started for each link in the vehicle network. In step S332, it is investigated whether the acquired communication performance information of each link includes certain communication performance information. In the case where the communication performance information is included (yes), the communication performance information obtained from the communication performance information storage unit 23 is used in step S333. In the case where the communication performance information is not included in step S332 (no), it is assumed in step S335 that no communication is performed in the link. If the processing is completed for all links, the loop ends in step S334.

[0090] Fig.19 Yes means Fig.16 A flowchart of an example of detailed processing of step S305 in FIG. Here, four values, namely, communication bandwidth, delay, jitter, and packet loss rate, which are the communication performance in the link, are obtained by numerical calculation for each application. Because the above four values ​​can be calculated independently, the following steps are allowed to be executed continuously or in parallel. First, in step S340, a loop is started for each link that constitutes a path candidate. Steps S341 to S344 can be executed independently. In step S341, the communication bandwidth of the application is added to the bandwidth used in the link, thereby obtaining the communication bandwidth when the application is added. In step S342, the packet size of the application is added to the delay in the link, thereby obtaining the delay when the application is added. In step S343, because the jitter is determined by the maximum value of the packet size sent in the link, the jitter in the link is compared with the packet size of the application. When the packet size of the application is larger than the jitter in the link, the jitter is updated to the packet size of the application. In step S344, since the packet loss rate is caused by the overflow of the transmission buffer in the link, the value obtained by adding the buffer usage in the link to the packet size of the application is taken as SUM. When SUM is larger than the buffer size, the packet loss rate is calculated using the formula (SUM-buffer size) / SUM. In step S345, the loop ends for each link constituting the path candidate.

[0091] Fig. 20 The communication path list 120 is output from the performance verification unit 26 and input to the setting application unit 27. The communication path list 120 stores a communication path 122 selected by the performance verification unit 26 for each application column 121.

[0092] Fig.211 is a flowchart showing the operation of setting the application unit 27. First, in step S400, the application included in the communication path list 120 received from the performance verification unit 26 is extracted to obtain an application list. Then, in step S401, the identification information of the application included in the above-obtained application list is obtained from the application requirement storage unit 21. Then, in step S402, the communication path information is reconstructed, and a communication path setting table 130 is generated for each ECU, which associates the identification information of the application through which the communication data passes with the next transmission target ECU of the communication data. Fig. 22 The structure example of the communication path setting table 130 is described. Then, 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 transmission target ECU are set for the ECU. In step S405, the loop about the ECUs in the communication path setting table 130 ends. Finally, for the applications included in the application list, they are configured to the configuration target ECU. The configuration target ECU is the ECU located at the beginning of the transmission data or the end of the reception data in the communication path of the application.

[0093] Fig. 22 This is a configuration example of a communication path setting table 130 used inside the setting application unit 27. The communication path setting table 130 stores application identification information 132 of the application through which communication data passes and the next transmission target ECU 133 in an ECU column 131. In addition, for data received by the application in the configuration target ECU of the application, the transmission target is expressed as a CPU.

[0094] Through the above actions, the in-vehicle network system can configure the application to the ECU by adding a new application via OTA, taking into account the computing / storage resources within the ECU and the communication resources between the ECUs. In addition, the same method can be used to configure the application when updating existing applications via OTA.

[0095] (Summarize)

[0096] In this embodiment, a network system for configuring the above-mentioned application to any one of the multiple computing devices 3, 9 existing on the network in a manner that satisfies the execution requirement 53 of the application includes: an application requirement storage unit 21 that stores the execution requirement 53 and communication requirement 64 of the above-mentioned application; an idle resource information storage unit 20 that stores idle resource information of the multiple computing devices 3, 9; an application configuration selection unit 24, which selects a computing device that can execute the above-mentioned application from the multiple computing devices 3, 9 based on the execution requirement 53 and the idle resource information, and generates a candidate list 90 of the target computing device for application configuration; a topology structure information storage unit 22 that stores topology structure information representing the communication connection relationship of the multiple computing devices 3, 9; and a topology structure information storage unit 22 that stores topology structure information representing the communication connection relationship of the multiple computing devices 3, 9. a communication performance information storage unit 23 for storing communication performance information of each link of the network; a communication path selection unit 25, which generates a communication path candidate list 110 by selecting, based on the above-mentioned topological structure information, the communication path of the above-mentioned application when the above-mentioned application is configured in each computing device in the application configuration target computing device candidate list 90; a performance verification unit 26, which verifies whether each communication path in the communication path candidate list 110 can satisfy the communication requirement 64 based on the communication performance information and the communication requirement 64; and a setting application unit 27, which configures the above-mentioned application in the computing device in the application configuration target computing device candidate list 90 that corresponds to the communication path that is verified by the performance verification unit 26 to satisfy the communication requirement 64.

[0097] In addition, in this embodiment, the network management method for configuring the above-mentioned application to any one of the multiple computing devices 3 and 9 existing on the network in a manner that satisfies the execution requirements 53 of the application includes: an application requirement saving step for saving the execution requirements 53 and the communication requirements 64 of the above-mentioned application; an idle resource information saving step for saving the idle resource information of the multiple computing devices 3 and 9; an application configuration selection step for selecting a computing device capable of executing the above-mentioned application from the multiple computing devices 3 and 9 based on the execution requirements 53 and the idle resource information, and generating a candidate list 90 of the target computing device for application configuration; a topology information saving step for saving the topology information representing the communication connection relationship of the multiple computing devices 3 and 9; A communication performance information saving step for saving the communication performance information of each link of the above-mentioned network; a communication path selection step for selecting, based on the above-mentioned topological structure information, the communication path of the above-mentioned application when the above-mentioned application is configured in each computing device in the application configuration target computing device candidate list 90, to generate a communication path candidate list 110; a performance verification step for verifying, based on the communication performance information and the communication requirement 64, whether each communication path in the communication path candidate list 110 can satisfy the communication requirement 64; and an application setting step for configuring the above-mentioned application in the computing device in the application configuration target computing device candidate list 90, which corresponds to the communication path that has been verified to satisfy the communication requirement 64 by the above-mentioned performance verification step.

[0098] According to the present embodiment constructed as described above, when configuring an application for any one of the multiple computing devices 3, 9 existing on the network, the execution performance and communication performance of the application can be ensured by considering the computing resources of each computing device 3, 9 and the communication resources between the computing devices, so that the application can run stably.

[0099] In addition, the communication requirements 64 and communication performance information in this embodiment include one or more of the communication bandwidth, communication delay, communication jitter, and packet loss rate of the application program. Thus, the communication requirements 64 and communication performance information of the application program can be defined.

[0100] In addition, the performance verification unit 26 in this embodiment verifies whether each communication path in the communication path candidate list 110 satisfies the communication requirement 64 by performing numerical calculations based on the communication performance information and the communication requirement 64. This makes it possible to easily verify whether each communication path in the communication path candidate list 110 satisfies the communication requirement 64.

[0101] In addition, the performance verification unit 26 in this embodiment verifies whether each communication path in the communication path candidate list 110 satisfies the communication requirement 64 by performing simulation based on the communication performance information and the communication requirement 64. Whether each communication path in the communication path candidate list 110 satisfies the communication requirement 64 can be verified with high accuracy.

[0102] In addition, in this embodiment, the metadata 43 input to the network together with the application when configuring the application includes: execution requirements 53 including one or more of computing resources, storage resources, and specifications; communication specifications 58 including one or more of communication direction, communication object, 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. In this way, the execution requirements 53, communication specifications 58, and communication requirements 64 of the application can be defined.

[0103] In addition, the network in this embodiment is an in-vehicle network installed in a vehicle, and the plurality of computing devices 3 and 9 are a plurality of in-vehicle electronic control devices 3 and 9 installed in the vehicle. Thus, a newly deployed application can be stably operated in the in-vehicle network.

[0104] In addition, the vehicle-mounted device in this embodiment has the above-mentioned network system, so that a newly deployed application can be stably operated in the vehicle-mounted device.

[0105] In addition, the communication requirements 64 in this embodiment include items related to the following data: sensor data output from the sensor 4 mounted on the vehicle, control data for controlling the vehicle, and intermediate data obtained in the calculation process of obtaining the control data from the sensor data. In this way, the communication requirements 64 corresponding to the required performance of the vehicle-mounted device can be defined.

[0106] Example 2

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

[0108] The main structure and operation flow of this embodiment are the same as those of the first embodiment. Only the differences from the first embodiment are described below.

[0109] Fig.23 2 is a diagram showing the structure of the performance verification unit 26 in the second embodiment. The performance verification unit 26 in this embodiment can generally adopt two structures. Fig.23(a) is a block diagram of a case where a simulation is performed in a vehicle. The performance verification unit 26 has a simulation unit 28 therein, and uses the simulation unit 28 to perform performance verification by simulation. Fig.23 (b) is a structural diagram for the case where simulation is performed outside the vehicle. Here, outside the vehicle refers to computing resources outside the vehicle, such as the cloud, multi-access edge computing (MEC), roadside units, or other vehicles. The performance verification unit 26 communicates with the simulation unit 28 set outside the vehicle by wireless communication, etc., sends the necessary settings to the simulation unit 28, instructs the simulation unit 28 to perform simulation, and receives the results from the simulation unit 28.

[0110] Fig.24 The operation of the performance verification unit 26 in the second embodiment is shown in FIG. Fig.16 Flow chart of the action of step S305 in step S500. First, generate simulation settings in step S500. Then, in step S501, make the simulation unit 28 operate and perform simulation. Finally, in step S502, obtain performance evaluation results from the simulation results according to the intervals (links) of the path candidates. The performance evaluation results here include communication bandwidth, delay, jitter, packet loss rate, etc.

[0111] As described above, according to the invention of this embodiment, a more accurate performance evaluation can be performed, the number of applications that can be accommodated can be increased, and the stability of application operation can be improved.

[0112] (Summarize)

[0113] The performance verification unit 26 of the network system in this embodiment verifies whether the communication requirements 64 can be satisfied using each communication path in the communication path candidate list 110 by performing simulation based on the communication performance information and the communication requirements 64 .

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

[0115] In addition, in the performance verification step of the network management method in this embodiment, a simulation based on the communication performance information and the communication requirements 64 is performed using a computer inside the vehicle to verify whether each communication path in the communication path candidate list 110 satisfies the communication requirements 64. Thus, simulation can be performed even in an environment where the network system cannot communicate with the outside.

[0116] In addition, in the performance verification step of the network management method in this embodiment, a simulation based on the communication performance information and the communication requirements 64 is performed using a computer outside the vehicle to verify whether each communication path in the communication path candidate list 110 can satisfy the communication requirements 64. As a result, the resources for performing the simulation are not limited, so the accuracy of the simulation can be improved.

[0117] Example 3

[0118] In the first and second embodiments, the topology of the vehicle network is assumed to be fixed. On the other hand, the topology of the vehicle network may change due to the addition of new devices to CAN or communication disconnection caused by hardware abnormalities. Therefore, the third embodiment shows an in-vehicle network system that can follow such topology changes.

[0119] Fig.25 FIG. 1 is a functional block diagram of the vehicle network system in the third embodiment. Figure 3 A topology change monitoring unit 29 is added.

[0120] The topology change monitoring unit 29 monitors the status of the vehicle network by using "bus failure" or "error status" in CAN and LLDP (Link Level Discovery Protocol) in Ethernet. The status of the vehicle network here refers to whether the link in the vehicle network is in a state where normal communication is possible. If it is in a normal state, no action is taken. When an abnormality is detected, the information about the link is deleted from the topology information table 70 of the topology information storage unit 22 or marked as an abnormal state and set to not be used. Afterwards, the application is reconfigured, including the configured application. That is, the communication path selection unit 25, the performance verification unit 26, and the setting application unit 27 are activated to set the application configuration and communication path to avoid the link that has become an abnormal state.

[0121] (Summarize)

[0122] The network system in this embodiment further includes a topology change monitoring unit 29 that detects a change in the network topology and notifies the topology information storage unit 22 of the change.

[0123] According to the present embodiment configured as described above, even when the network topology changes, the application program can be deployed in the computing devices 3 and 9 so as to satisfy the execution requirement 53 and the communication requirement 64 .

[0124] Example 4

[0125] In the first and second embodiments, when multiple applications are added via OTA, the order of adding applications is not considered. Therefore, there is a situation where the application added first consumes the resources inside the ECU and the communication resources between ECUs, and the application added later cannot be added. Therefore, when the priorities of the applications are different, the high-priority application is not added.

[0126] Therefore, in the fourth embodiment, a device for performing application configuration in consideration of the priority among applications is shown.

[0127] Fig.26 This is the application requirement table 50 stored in the application requirement storage 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 specification 58. Fig.26 8 levels of priority are set in 0 to 7, with 0 being the lowest priority and 7 being the highest priority. In addition, the execution requirement 53 and the communication requirement 64 are the same as those in the first and third embodiments, and thus description of the individual columns is omitted.

[0128] Fig. 27 4 is a flowchart showing the operation of the application configuration selection unit 24 in the fourth embodiment. Fig. 9 )The same processing is assigned the same number. The only difference from Embodiments 1 to 3 is that the loop processing of step S101 is changed to step S600. In step S600, the loop about the application is performed in the order of the priority of the application requirement table 50 in this embodiment from high to low. Therefore, the higher the priority of the application, the earlier the ECU configuration and communication path are determined.

[0129] (Summarize)

[0130] In this embodiment, the application requirement storage unit 21 stores the priority level for each application, and the application placement selection unit 24 generates the application placement destination computing device candidate list 90 in descending order of the application with the highest priority level.

[0131] According to the present embodiment configured as described above, the application programs can be arranged in the computing devices 3 and 9 in descending order of priority.

[0132] Example 5

[0133] In the first to fourth embodiments, each item of the communication requirements is considered to have the same priority, but the degree to which the communication requirements must be satisfied varies depending on the application. Therefore, the fifth embodiment shows a structure that allows the communication requirements to be specifically satisfied for each application to be specified.

[0134] Fig.28This is the application requirement table 50 stored in the application requirement storage unit 21 in the fifth embodiment. The difference from the first to fourth embodiments is that priority lists 69a to 69d corresponding to the respective items of the communication requirements are added. Fig.28 The priority is set in 8 levels from 0 to 7, with 0 being the lowest priority and 7 being the highest priority. Using the priority corresponding to each item of the communication requirement, it is possible to configure the application to meet the communication requirements that are particularly required for each application.

[0135] Fig.29 26. Fig.16 )The same processing is assigned the same number. The difference from the first embodiment is that step S306 is changed to step S700, and after step S307 is completed, it is not immediately regarded as a failure of application configuration in step S308, but the application configuration is retried after excluding the lowest priority item from the communication requirements in steps S700 and S701.

[0136] In step S700, it is determined whether the result of the application communication performance evaluation is that the application communication performance meets the communication requirements with a priority greater than 0. If it is satisfied (yes), the application configuration is deemed to be successful and the steps after step S310 are executed. If it is not satisfied (no), the loop on the path candidate list is terminated in step S307.

[0137] In step S701, the priority of each communication element of the application is checked from the application element table 50. When the priority of two or more communication elements is a value greater than 0, it is determined that the lowest priority of the communication elements with a priority greater than 0 can be excluded. When it is determined in step S701 that it can be excluded (yes), in step S702, the priority of the communication element determined in step S700 to be excluded is overwritten to 0. When it is determined in step S701 that it cannot be excluded (no), the process proceeds to step S308 and the application configuration is deemed to have failed.

[0138] As described above, it is possible to specify a requirement that is particularly to be satisfied among the communication requirements, and implement an application configuration that satisfies the requirement.

[0139] (Summarize)

[0140] In this embodiment, the application requirement storage unit 21 stores the priority of each item of the communication requirement 64 of the application. When there are more than one unsatisfied items in the communication requirement 64, the performance verification unit 26 excludes the item with the lowest priority from the communication requirement 64 and re-verifies whether the communication requirement 64 can be satisfied.

[0141] According to the present embodiment configured as described above, by excluding items with low priority from the communication requirements 64 of the application, more applications can be arranged in the computing devices 3 and 9.

[0142] The embodiments of the present invention are described in detail above, but the present invention is not limited to the above embodiments, and includes various modified examples. For example, the above embodiments are described in detail to explain the present invention in an easy-to-understand manner, and the present invention is not limited to all the structures described. In addition, a part of the structure of another embodiment can be added to the structure of a certain embodiment, a part of the structure of a certain embodiment can also be deleted, or replaced with a part of another embodiment.

[0143] Description of Reference Numerals

[0144] 1…Vehicle, 2…Gateway, 3, 3a~3d…Domain ECU (computing device, onboard electronic control unit), 4, 4a~4d…Sensor, 5, 5a~5d…Actuator, 6, 6a~6d…Link, 7…TCU, 8…Central ECU (computing device, onboard electronic control unit), 9, 9a~9d…Regional ECU (computing device, onboard 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 configuration selection section, 25…Communication path selection section, 26…Performance verification section, 27…Setting application section, 28…Simulation section, 29…Topology change monitoring section, 30…ECU internal free resource information table, 31…ECU column, 32…Computing resource column, 33…Storage resource column, 34…Specification column, 40…OTA data, 41…Header, 42…Application data, 43…Metadata, 50…Application requirement table, 51…Application column, 52…Configured flag, 53…Execution requirement, 54…Communication ID, 55…Computing resource column, 56…Storage resource column, 57…Specification column, 58…Communication specification, 59…Communication direction column, 60…Communication object 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…Loss rate column, 69, 69a to 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, 86…Jitter column, 87…Loss rate column, 88…Cache usage column, 90…Application configuration target ECU candidate list (application configuration target computing device candidate list), 91…Application column, 92…Configuration target ECU candidate, 100…Search list, 101…Phase, 102…Communication path candidate, 103…Status, 110…Communication path candidate list, 111…Application column, 112…Communication path candidate, 120…Communication path list, 121…Application column, 122…Communication path, 130…Communication path setting table, 131…ECU column, 132…Application identification information, 133…Transmission target ECU.

Claims

1. A network system for deploying an application program to any one of a plurality of computing devices on a network in a manner that satisfies execution requirements of the application program, the network system comprising: An application program element storage unit storing execution elements and communication elements of the application program; An idle resource information storage unit for storing idle resource information of the plurality of computing devices; an application configuration selection unit, which selects 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 generates a candidate list of target computing devices for application configuration; A topology information storage unit storing topology information indicating a communication connection relationship between the plurality of computing devices; A communication performance information storage unit storing communication performance information of each link of the network; a communication path selection unit for generating a communication path candidate list by selecting a communication path for the application when the application is configured in each computing device in the application configuration target computing device candidate list based on the topology information; a performance verification unit that verifies, based on the communication performance information and the communication requirements, whether each communication path in the communication path candidate list can satisfy the communication requirements; and The application setting unit configures the application in a computing device corresponding to a communication path verified by the performance verification unit to satisfy the communication requirement, among computing devices in the candidate list of computing devices to be configured as the application.

2. The network system according to claim 1, characterized in that: The communication requirements and the communication performance information include one or more of a communication bandwidth, a communication delay, a communication jitter, and a packet loss rate of the application.

3. The network system according to claim 1, wherein: The performance verification unit verifies whether the communication requirements can be satisfied by each communication path in the communication path candidate list by performing numerical calculation based on the communication performance information and the communication requirements.

4. The network system according to claim 1, wherein: The performance verification unit verifies whether the communication requirements can be satisfied using each communication path in the communication path candidate list by performing a simulation based on the communication performance information and the communication requirements.

5. The network system according to claim 1, wherein: The device further comprises a topology change monitoring unit for detecting a change in the topology of the network and notifying the topology information storage unit of the change.

6. The network system according to claim 1, wherein: The application requirement storage unit stores the priority of each application. The application placement selection unit generates the application placement target computing device candidate list in order from the application with the highest priority.

7. The network system according to claim 1, wherein: The application requirement storage unit stores the priority of each item of the communication requirement. When there are at least one unsatisfied item in the communication requirements, the performance verification unit excludes the item with the lowest priority from the communication requirements and re-verifies whether the communication requirements can be satisfied.

8. The network system according to claim 1, wherein: The metadata that is input to the network along with the application when configuring the application includes: An execution requirement that includes one or more of computing resources, storage resources, and specifications; Communication specifications including one or more of communication direction, communication object, communication cycle, communication data size, and communication identification information; and Communication requirements include one or more of communication bandwidth, communication delay, communication jitter, and packet loss rate.

9. The network system according to claim 1, wherein: The network is an in-vehicle network installed in a vehicle. The plurality of computing devices are a plurality of vehicle-mounted electronic control devices mounted on the vehicle.

10. A vehicle-mounted device, characterized in that: A network system according to claim 9.

11. The network system according to claim 9, characterized in that: The communication element includes items related to sensor data output from a sensor mounted on the vehicle, control data for controlling the vehicle, and intermediate data obtained in a calculation process of obtaining the control data from the sensor data.

12. A network management method for configuring an application program to any one of a plurality of computing devices existing on a network in a manner that satisfies execution requirements of the application program, the network management method comprising: An application program element storage step of storing execution elements and communication elements of the application program; An idle resource information saving step of saving the idle resource information of the plurality of computing devices; an application configuration selection step, selecting a computing device capable of executing the application from the plurality of computing devices based on the execution requirements and the idle resource information, and generating a candidate list of target computing devices for application configuration; A topology information storing step of storing topology information indicating the communication connection relationship of the plurality of computing devices; A communication performance information storing step of storing communication performance information of each link of the network; a communication path selection step, based on the topology information, selecting a communication path for the application when the application is configured in each computing device in the candidate list of the application configuration target computing device, to generate a communication path candidate list; a performance verification step of verifying whether each communication path in the communication path candidate list can satisfy the communication requirement based on the communication performance information and the communication requirement; and The application setting step configures the application in a computing device in the candidate list of the application configuration target computing devices corresponding to the communication path that has been verified in the performance verification step to satisfy the communication requirements.

13. The network management method according to claim 12, characterized in that: The network is an in-vehicle network installed in a vehicle. The plurality of computing devices are a plurality of vehicle-mounted electronic control devices mounted on the vehicle.

14. The network management method according to claim 13, characterized in that: In the performance verification step, it is verified whether the communication requirements can be satisfied using each communication path in the communication path candidate list by performing a simulation based on the communication performance information and the communication requirements using a computer inside the vehicle.

15. The network management method according to claim 13, characterized in that: In the performance verification step, it is verified whether the communication requirements can be satisfied using each communication path in the communication path candidate list by performing a simulation based on the communication performance information and the communication requirements using a computer outside the vehicle.

Images