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 rapidly and will continue to evolve in the future. Automakers are not only applying these technological advances to new vehicles, but are also considering applying them to vehicles already on the market. One technology for this 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's 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 apps.

[0005] When a new application is added via OTA, the vehicle system needs to select an ECU that will run the new application. Patent Document 1 discloses a method for selecting an ECU that will run an application when adding an application. This method involves an in-vehicle system having multiple ECUs on which an additional application acquired by an application acquisition unit can be installed, the system comprising a requirement specification unit, a resource specification unit, and a selection unit. The requirement specification unit specifies required resources, which are resources required by the additional application. The resource specification unit specifies provided resources, which 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] Japanese Patent Publication No. 2020-86522 Summary of the Invention [Problem to be solved by the invention]

[0007] The invention described in Patent Document 1 can select the ECU where an application is to be placed based on the ECU's computing 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 purpose is to provide a network system and a network management method that enable application deployment taking into account the computing resources of each computing device on the network and the communication resources between computing devices. [Means for solving the problem]

[0009] In order to achieve the above object, the present invention provides a network system that deploys an application to one of a plurality of computing devices present on a network so as to satisfy execution requirements of the application, the network system including: an application requirement storage unit that stores execution requirements and communication requirements of the application; a free resource information storage unit that stores free resource information of the plurality of computing devices; an application deployment 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 free resource information and creates a list of candidate computing devices where the application is to be deployed; a topology information storage unit that stores topology information indicating communication connection relationships of the plurality of computing 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 deployed to each computing device in the candidate computing device list where the application is to be deployed based on the topology information and creates a list of candidate communication paths; a performance verification unit that verifies whether the communication requirements are satisfied by each communication path in the candidate communication path list based on the communication performance information and the communication requirements; and a setting application unit that deploys the application to one of the computing devices in the candidate computing device list where the communication path has been verified by the performance verification unit to satisfy the communication requirements. a topology change monitoring unit that detects a change in the topology of the network and monitors whether the links on the network are in a state where communication is possible normally, and when an abnormality is detected in the link, the topology information storage unit does not use information about the link in which the abnormality is detected; of When an abnormality is detected in the link, the communication path selection unit, the performance verification unit, and the setting application unit set an application placement and a communication path that avoids the link in which the abnormality is detected, and perform a re-placement of the application, including the application that has already been placed. . [Effects 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 consideration the computing resources of each computing device and the communication resources between the computing devices, thereby enabling the application to operate stably. [Brief explanation of the drawings]

[0012] [Figure 1] 1 is a diagram showing the electrical and electronic architecture of an in-vehicle device incorporating an in-vehicle network system according to the present invention; [Figure 2] Hardware configuration diagram of domain ECU, zone ECU, central ECU, and gateway [Figure 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 [Figure 5] Example of the OTA data structure 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 in step S209 in FIG. [Figure 13] A flowchart showing an example of detailed processing of step S221 in FIG. 12. [Figure 14] Example of the results of executing the process in Figure 13 on a network with 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] 16. A flowchart showing an example of detailed processing in step S302 in FIG. [Figure 18] 16. A flowchart showing an example of detailed processing in step S303 in FIG. [Figure 19] 16. 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 unit [Figure 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. [Figure 25] 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 INVENTION

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

[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. Two configurations are shown here as typical electrical and electronic architectures, but the application of the present invention is not limited to these.

[0016] Figure 1(a) shows the logical configuration of an architecture called a domain-specific architecture. This is a method of classifying ECUs (electronic control units) inside a vehicle 1 into functional divisions called domains, and systematically connecting ECUs belonging to the same domain. Each domain has a domain ECU 3 that oversees that domain. To enable communication between domains, the domain ECUs 3 are interconnected via a gateway 2. Examples of domains include an Advanced Driver Assistance System (ADAS) domain that manages safe driving assistance, a Power Train / Chassis (PT / CH) domain that controls the vehicle's longitudinal and lateral movement, a Body domain that controls electrical equipment such as power windows, and an Infotainment domain that controls navigation and audio. Each domain is equipped with an ADAS ECU 3a, a PT / CH ECU 3b, a Body ECU 3c, and an Infotainment ECU 3d (hereinafter collectively referred to as "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 to the domain ECU 3 via links 6a to 6d (hereinafter collectively referred to as 6) appropriate for each domain, such as a CAN (Controller Area Network) or a LIN (Local Interconnect Network). Multiple ECUs 4 and 5 may be connected to a single link 6. In addition, a TCU (Telematics Control Unit) 7, which communicates with external servers, clouds, etc., via a wireless network, is connected to the gateway 2.

[0017] The performance and functional requirements of domain ECUs may differ depending on the domain. 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 connections.

[0018] Figure 1(b) shows the physical configuration of an architecture called zone architecture. This architecture classifies ECUs 4 and 5 according to their spatial location within the vehicle 1 and connects them to zone ECUs 9a-9d (collectively referred to as "9") that oversee these locations. The architecture consists of one or more zone ECUs 9, a central ECU 8 connected to the zone ECUs 9 and running multiple applications across multiple domains, and sensors 4 and actuators 5 connected to the zone ECUs 9. As the name suggests, these zone ECUs 9 are positioned in positions (zones) within the vehicle, such as the front, rear, left, and right, and are connected to sensors 4, actuators 5, or both, that are located nearby. Furthermore, zone ECUs 9 are connected to other zone ECUs 9 via shared links 10, which use a common communication protocol between domains. This common communication protocol 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; however, Figure 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 the common communication method, which is the 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 storing data used for calculations by the CPU 11. Links for connecting to the gateway 2 and 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 sensors 4 and actuators 5. The zone ECU 9 also has a CPU 11 for processing information received from the sensors 4 and actuators 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 sensors 4 and actuators 5 support a common communication method, they may be directly connected to the network switch 13. If the sensors 4 and actuators 5 do not support a common communication method, they can be connected to the CPU 11 and then converted to the common communication method.

[0022] 2(c) shows the 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 connecting 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, memory 12, and a network switch 13 for connecting to the zone ECUs 9.

[0024] Figure 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 Figure 1, or may be implemented as software and executed by any of the ECUs in Figure 1. When implemented as software, they can be executed by any of the ECUs in Figure 1 without impairing functionality, but typically, to manage the entire in-vehicle network, they are expected to 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 via 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 application placement based on the resource status inside each ECU obtained from the free resource information storage unit 20 and execution requirement information regarding the application's ECU internal resources (computational resources) obtained from the application requirement storage unit 21.

[0031] The communication path selection unit 25 determines candidate communication paths for communication performed by the application based on the candidate ECUs for placement of 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 route candidate is selected for the application communication route candidate determined by the communication route 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. As a result of the verification, one communication route to be actually used is selected from the route candidates that satisfy the communication performance of the application.

[0033] The setting application unit 27 applies the communication path determined by the performance verification unit 26 to the in-vehicle network. To do this, it acquires 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 an ECU column 31, a computational resource column 32, a storage resource column 33, and a spec column 34. The spec means the characteristics of an ECU, such as high performance and high reliability.

[0036] 5 shows an example of the structure of OTA data 40 received by application requirement storage unit 21 via TCU 7. OTA data 40 includes a header 41 including the application ID, version information, etc., application data 42 storing the application's code in binary format, etc., and metadata 43 related to the application referenced in the present invention. Metadata 43 stores execution requirements 53, communication specifications 58, and communication requirements 64 similar to those in application requirement table 50 shown in FIG. 6, corresponding to a communication ID 54 that is an identification number for communication in the application. If 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 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] FIG. 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 an application ID, a deployment flag 52 indicating whether the application has been deployed to an ECU, execution requirements 53 holding requirements related to ECU internal resources (computational resources), communication specifications 58 holding specifications for inter-ECU communication, and communication requirements 64 holding requirements related to inter-ECU communication resources. The execution requirements 53 include a computational resource column 55, a storage resource column 56, and a specification column 57. The communication specifications 58 also include, as application requirements related to inter-ECU communication, a communication direction column 59 indicating whether the application is sending or receiving, a communication partner column 60 specifying 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. Examples of application identification information include the CAN ID for CAN, source and destination MAC addresses for Ethernet, source and destination IP addresses for IP (Internet Protocol), and source and destination port numbers for TCP (Transmission Control Protocol) or UDP (User Datagram Protocol). The communication requirements 64 include a communication bandwidth column 65, a communication delay column 66, a jitter column 67, and a loss rate column 68. If a single application performs multiple communications, the application uses multiple rows to represent the multiple communications, as in application A3. If 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 representing each link connecting ECUs in an in-vehicle network, a type column 72 describing 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 shows an excerpt from a communication performance information table 80 stored in the communication performance information storage unit 23. The communication performance information table 80 has a link column 81, a communication direction 82, and for each link and communication direction, a total bandwidth column 83 indicating the total bandwidth of the link, 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 illustrating the operation of the application placement selection unit 24. This flowchart starts when the application requirement table 50 is updated due to the addition of an application via 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 moves to the processing of the next application. If it has not been placed (No), steps S103 and subsequent steps 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 predefined ECU candidate list is sorted in descending order of total resources, and the ECUs are selected as candidates for placement of the application, and the process moves to the processing of the next application. If it has been registered (Yes), the following processing is performed. In step S104, the intra-ECU free resource information table 30 is obtained from the free resource information storage unit 20. In the next step S105, ECUs that satisfy the execution requirements of the application are selected from ECUs in ECU free resource information table 30, with computational and storage resources greater than those in the application's execution requirements and that satisfy the specifications required by the application, thereby 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 candidate 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 process ends.

[0041] 10 shows an application placement ECU candidate list 90 that is output by 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 is input to the next communication path selection unit 25.

[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 acquired from the application placement selection unit 24. In step S201, the topology information table 70 of the in-vehicle network is acquired from the topology information storage unit 22. In step S202, it is confirmed whether topology information of the in-vehicle network is included in the topology information table 70, and if not (No), pre-defined default topology information is used in step S204. If 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 application's communication data (packet). 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 processing proceeds to the next application. If information about the communication partner is included in step S207 (Yes), 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 receiver are obtained by a separately defined process. When the process of S209 has been completed for all placement ECU candidates, in S210 the loop for the placement ECU candidates is ended.

[0043] When the processing has been completed for all applications in the application-placement-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 using a separately defined process. 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 using 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 its status set to 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 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 status of the communication path candidate 102 is checked. First, if the last item in the communication path candidate 102 is the destination ECU (S234a), in step S235, the communication path status 103 is set to "destination reached," and in step S236, it is added to the route candidate list output by the communication path selection unit 25. Next, in step S234, if the last item in the communication path candidate 102 is a searched ECU (S234b), that is, if the communication path candidate includes multiple identical ECUs, in step S237, the status 103 of the communication path candidate is set to "searched and reached." If the result is otherwise in step S234 (S234c), in step S238, the status 103 of the communication path candidate is set to "incomplete." Then, when processing has been completed up to the end of the search list of the current phase, the loop ends in step S239.

[0048] Finally, in step S240, it is checked whether there are any communication path candidates 102 whose status is incomplete in the search list of the current phase, and if there are any communication path candidates 102 whose status is incomplete, the process returns to step S231 to continue. If there are no communication path candidates 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 with a 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 either "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 for 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 for the application is obtained from the application requirement storage unit 21 using a procedure defined separately. Next, in step S303, communication performance information for each link on the in-vehicle network is obtained from the communication performance information storage unit 23 using 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 based on the communication performance information of the route candidate and the communication requirements of the application using a procedure defined separately. The result of this evaluation is determined in step S306, and if the communication requirements of the application cannot be met (No), the loop for the route candidate list continues. If a communication path that satisfies the communication requirements of the application exists in step S306 (Yes), the application placement is deemed 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 satisfies the communication requirements of the application does not exist and the loop ends in step S307, the application placement is deemed unsuccessful in step S308. Finally, these processes are executed until the loop for each application ends in step S309.

[0052] FIG. 17 is a flowchart showing an example of detailed processing of step S302 in FIG. 16. After this processing, processing related to a specific application is performed. 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 obtained communication requirement data 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), predefined default communication requirements are used in step S323.

[0053] 18 is a flowchart 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 obtained 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 determined whether or not any communication performance information is included in the communication performance information obtained for each link. If communication performance information is included (Yes), in step S333, the communication performance information obtained from the communication performance information storage unit 23 is used. If communication performance information is not included (No) in step S332, it is assumed in step S335 that no communication is taking place on that 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 the communication performance on the link for each application. Because these four values ​​can be calculated independently, the following steps can be executed either sequentially 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 when the application is added is calculated by adding the communication bandwidth of the application to the bandwidth used on the link. 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 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. 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 is caused by overflow of the transmission buffer on the link, the value obtained by adding the packet length of the application to the buffer usage on the link is set as SUM, and if SUM is greater than the buffer size, the packet loss rate is calculated using 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 that is 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 illustrating 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, identification information of applications included in the obtained application list is obtained from the application requirement storage unit 21. Next, in step S402, the communication path information is reconfigured to generate a communication path setting table 130 that associates, for each ECU, the identification information of applications through which communication data passes with the next destination ECU of the communication data. 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 processing 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 ECUs in the communication path setting table 130 is terminated. Finally, the applications included in the application list are deployed to the deployment destination ECUs. The destination ECU is the ECU at the beginning of the transmitted data or the end of the received 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 the application through which communication data passes and a next destination ECU 133. Note that the destination of data received by an application in the ECU where the application is placed is represented as a CPU.

[0058] The above operations enable the in-vehicle network system to allocate new apps to ECUs when adding them via OTA, taking into consideration the computational and storage resources within the ECU and the communication resources between ECUs. The same method can also be used to allocate 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 that holds the execution requirement 53 and communication requirement 64 of the application, a free resource information holding unit 20 that holds free resource information of the plurality of computing devices 3, 9, an application allocation selection unit 24 that 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 free resource information, and creates an application allocation destination computing device candidate list 90, a topology information holding unit 22 that holds topology information indicating the communication connection relationship of the plurality of computing devices 3, 9, and a network system in which the application is allocated to one of a plurality of computing devices 3, 9. a communication path selection unit 25 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 90 based on the topology information, and creates a communication path candidate list 110; a performance verification unit 26 that verifies whether the communication requirement 64 is satisfied for 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 that deploys the application on a computing device in the application placement destination computing device candidate list 90 that corresponds to a communication path for which the performance verification unit 26 has verified that the communication requirement 64 is satisfied.

[0060] Furthermore, in this embodiment, a network management method for deploying 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 communication requirement 64 of the application, a free resource information holding step for holding free 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 free resource information, and creating an application placement destination computing device candidate list 90, a topology information holding step for holding topology information indicating communication connection relationships 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 the communication requirement 64 is satisfied for 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 in the application placement destination computing device candidate list 90 that corresponds to a communication path for which it has been verified that the communication requirement 64 is satisfied by the performance verification step.

[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] Furthermore, 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, which makes it possible to define the communication requirements 64 and 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 numerical calculations 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] Furthermore, in this embodiment, 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] Furthermore, the network in this embodiment is an in-vehicle network mounted on a vehicle, and the multiple arithmetic units 3, 9 are multiple in-vehicle electronic control units 3, 9 mounted on the vehicle. This makes it possible to stably operate a newly deployed 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 operate stably 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 calculations to obtain the control data from the sensor data. This makes it possible to define the communication requirements 64 according to the required performance of the on-vehicle device. [Example]

[0069] In the first embodiment, 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, an alternative method is shown, in which communication performance is estimated by network simulation.

[0070] The main configuration and operation flow of this embodiment are the same as those of the first embodiment, and only the differences from the first embodiment will be explained 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 main ways. FIG. 23(a) is a configuration diagram when a simulation is performed inside the vehicle. The performance verification unit 26 has an internal simulation unit 28, which is used to perform performance verification through simulation. FIG. 23(b) is a configuration diagram when a simulation is performed outside the vehicle. Here, "outside the vehicle" refers to a computing resource other than the vehicle itself, such as the cloud, Multi-access Edge Computing (MEC), a roadside device, or another vehicle. The performance verification unit 26 communicates with the simulation unit 28 installed outside the vehicle via wireless communication or the like, sends necessary settings to the simulation unit 28, instructs the simulation unit 28 to perform a simulation, and receives the results from the simulation unit 28.

[0072] Figure 24 is a flowchart showing the operation of step S305 in Figure 16, among the operations of the performance verification unit 26 in the second embodiment. First, in step S500, simulation settings are created. Next, in step S501, the simulation unit 28 is operated and a simulation is performed. Finally, in step S502, performance evaluation results are obtained for each section (link) of the route candidate from the simulation results. Here, the performance evaluation results include communication bandwidth, delay, jitter, packet loss rate, etc.

[0073] As described above, the invention according to this embodiment enables more accurate performance evaluation, and makes it possible to increase the number of accommodated applications and improve the stability of application operation.

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

[0075] According to the present embodiment configured as described above, it is 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] 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 using a computer inside the vehicle based on the communication performance information and the communication requirements 64. This makes it possible to perform a simulation even in an environment where 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 does not limit the resources for performing the simulation, making it possible to improve the accuracy of the simulation. [Example]

[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 can 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 that can follow such topology changes is shown.

[0079] 25 is a functional block diagram of an in-vehicle network system according to the third embodiment, in which a topology change monitoring unit 29 is added in comparison with FIG.

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

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

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

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

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

[0085] Fig. 26 shows an 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. In Fig. 26, priority is set in eight levels 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 of the first embodiment (FIG. 9) are assigned the same numbers. The only difference from the first to third embodiments is that the loop processing of step S101 is changed to step S600. In step S600, the loop related to the 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 first 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 described above, it is possible to allocate applications to the arithmetic units 3 and 9 in descending order of priority. [Example]

[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 must be satisfied in particular 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 communication requirements have been 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 communication requirements, applications can be placed so as 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 of the first embodiment 1 (Fig. 16) are assigned the same numbers. The differences from the first embodiment are that step S306 is changed to step S700, and that instead of determining that application deployment has failed immediately in step S308 after step S307 is completed, the lowest priority item is excluded from the communication requirements in steps S700 and S701, and application deployment is then attempted again.

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

[0093] In step S701, the priority of each communication requirement of the application is checked from the application requirement table 50. If the priority of two or more communication requirements is greater than 0, it is determined that the lowest priority of the communication requirements greater than 0 can be excluded. If it is determined in step S701 that it can be excluded (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 in step S701 that it cannot be excluded (No), the process proceeds to step S308, and the application deployment is deemed to have failed.

[0094] As described above, it is possible to specify communication requirements that should be particularly satisfied, and to realize application placement that satisfies those requirements.

[0095] (summary) In this embodiment, the application requirement storage unit 21 stores the priority for each item of the application's communication requirements 64, and if there are one or more items among the communication requirements 64 that 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 arithmetic devices 3 and 9.

[0097] Although the embodiments of the present invention have been described in detail above, the present invention is not limited to the above-described embodiments and includes various modifications. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to those including all of the described configurations. Furthermore, it is possible to add part of the configuration of one embodiment to the configuration of another embodiment, or to delete part of the configuration of one embodiment or replace it with 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... computational resource column, 33... storage resource column, 34... spec column, 40... OTA data, 41... header, 42... application data, 43... metadata, 50... application requirement table, 51... application column, 52... deployment completion flag, 53... execution requirement, 54... communication ID, 55... computational resource column, 56...Memory resource column, 57...Spec column, 58...Communication specifications, 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...placement ECU candidates, 100...search list, 101...phase, 102...communication path candidates, 103...state, 110...communication path candidate list, 111...application column, 112...communication path candidates, 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 one of a plurality of computing devices on a network so as to satisfy execution requirements of the application, an application requirement storage unit that stores execution requirements and communication requirements of the application; a free resource information storage unit that stores free resource information of the plurality of arithmetic units; 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 to be placed; a topology information storage unit that stores topology information indicating a communication connection relationship between the plurality of arithmetic units; 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 deployed on each of the computing devices in the application deployment destination computing device candidate list based on the topology information and creates a communication path candidate list; a performance verification unit that verifies whether 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 that has been verified by the performance verification unit to satisfy the communication requirements, among the computing devices in the list of candidate computing devices where the application is to be deployed; a topology change monitoring unit that detects a change in the topology of the network and monitors whether the links on the network are in a state where communication is possible normally, and when an abnormality is detected in the link, causes the topology information storage unit not to use information about the link in which the abnormality is detected; Equipped with When an abnormality is detected in the link, the communication path selection unit, the performance verification unit, and the setting application unit set an application placement and communication path that avoids the link where the abnormality was detected, and re-places the applications, including the applications that have already been placed.

2. 2. The network system according to claim 1, The communication requirements and the communication performance information include at least one of a communication bandwidth, 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 the communication requirements are satisfied for 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 the communication requirements are satisfied by each communication path in the communication path candidate list through 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 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:

6. 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 excludes the lowest priority item from the communication requirements and verifies again whether the communication requirements are satisfied. A network system comprising:

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

8. 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:

9. The network system according to claim 8 is provided. An in-vehicle device comprising:

10. 9. The network system according to claim 8, The communication requirements include items related to sensor data output from sensors 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:

Images