NETWORK SYSTEM, VEHICLE INDOOR DEVICE, AND NETWORK MANAGEMENT PROCEDURES

Abstract

An object of the present invention is to provide a network system and a network management method capable of placing an app in consideration of arithmetic resources of the respective arithmetic devices existing in a network and communication resources between the arithmetic devices. For this purpose, the present invention comprises a communication path selection unit 25, which, when placing an app in each arithmetic device, selects a communication path for an app from an app placement target arithmetic device candidate list 90, based on topology information that specifies a communication link relationship of the majority of the arithmetic devices 3 and 9, and creates a communication path candidate list 110; and a performance determination unit 26, which determineswhether a communication requirement 64 is met in each communication path in the communication path candidate list 110 based on the communication performance information and the communication requirements 64, and an app placement unit 27 that places the app in an arithmetic device corresponding to the communication path that has the communication requirements 64, the fulfillment of which was determined by the performance determination unit 26 among the arithmetic devices in the app placement target arithmetic device candidate list 90.

Description

Technical area

[0001] The present invention relates to a network system and a network management method for placing an app in a plurality of arithmetic devices present in a network. Technical background

[0002] Automated driving and technologies to assist safe driving are advancing daily and will continue to evolve in the future. Automakers are considering these technological advances being applied not only to new vehicles but also to existing vehicles. One technology used to achieve this is over-the-air (OTA) update technology.

[0003] With OTA, a new or updated in-vehicle application (hereinafter referred to simply as an app) is distributed from a server, such as a cloud, to a vehicle via a wireless network. On the vehicle side, the distributed app is developed, deployed, and executed within a vehicle system.

[0004] The vehicle system is configured with a plurality of electronic control units (ECUs) connected through a network. The ECU is used here as a generic term for a sensor such as a camera, an actuator that operates a motor, a steering system, and the like, and a device that performs calculations for control. The ECU sends and receives data via the in-vehicle network and compares the data with the app to obtain information for controlling the vehicle. The transmission and reception of data places a load on the in-vehicle network, and the load state of the in-vehicle network varies depending on the location of the app.

[0005] In this case, where a new app is added via OTA, the vehicle system needs to select an ECU that executes the new app. PTL 1 discloses a method for selecting an ECU that executes an app when the app is added. The in-vehicle system having the plurality of ECUs capable of installing additional apps fetched by an app fetching unit includes a request determination unit, a resource determination unit, and a selection unit. The request determination unit determines a request resource, which is a resource requested by the additional app. The resource determination unit determines a provision resource, which is a resource that can be provided by any ECU. The selection unit selects the ECU in which the provision resource satisfies the request resource, as the installation destination of the additional app. List of publicationsPatent literature

[0006] PTL 1: JP 2020-86522 A Summary of the inventionTechnical problem

[0007] In the invention described in PTL 1, the control unit that is an app placement target can be selected based on the arithmetic resource of the control unit, but the app placement cannot be performed in consideration of a communication resource between the control units, such as the load situation of the in-vehicle network.

[0008] The present invention has been made in view of the above-mentioned problems, and an object of the present invention is to provide a network system and a network management method capable of placing apps in consideration of the arithmetic resources of the respective arithmetic devices existing in a network and the communication resources between the arithmetic devices. Solution to the problem

[0009] To solve the above problem, the present invention provides a network system in which an app is placed in any one of a plurality of arithmetic devices present in a network to meet execution requirements of the app, the network system comprising an app request storage unit that stores the execution requirements and communication requirements of the app, a resource availability information storage unit that stores resource availability information about the plurality of arithmetic devices, an app placement selection unit that selects an arithmetic device capable of executing the app from the plurality of arithmetic devices based on the execution requirements and the resource availability information and creates an app placement target arithmetic device candidate list, a topology information storage unit that stores topology information,which indicate a communication connection relationship of the plurality of arithmetic devices, a communication performance information storage unit that stores communication performance information about network connections, a communication path selection unit that selects a communication path of the app in a case where the app is placed in each arithmetic device in the app placement target arithmetic device candidate list, and creates a communication path candidate list based on the topology information, a performance determination unit that determines whether the communication requirements are met in each communication path in the communication path candidate list based on the communication performance information and the communication requirements, and an app setting unit that places the app in an arithmetic device corresponding to a communication path,whose communication requirements have been determined to be met by the performance determination unit among the arithmetic devices in the app placement target arithmetic device candidate list.

[0010] Furthermore, the present invention provides a network management method for placing an app in any one of a plurality of arithmetic devices present in a network to meet execution requirements of the app, the network management method comprising maintaining the execution requirements and a communication requirement of the app, maintaining resource availability information about the plurality of arithmetic devices, selecting an arithmetic device capable of executing the app from the plurality of arithmetic devices based on the execution requirements and the resource availability information, and creating an app placement target arithmetic device candidate list that stores topology information indicating a communication connection relationship of the plurality of arithmetic devices, maintaining communication performance information about network connections,Selecting a communication path of the app in a case where the app is placed in each arithmetic device in the app placement target arithmetic device candidate list, and creating a communication path candidate list based on the topology information, checking whether the communication requirements are met in each communication path in the communication path candidate list based on the communication performance information and the communication requirements, and placing the app in an arithmetic device corresponding to a communication path for which the communication requirements were determined to be met when determining the performance among the arithmetic devices in the app placement target arithmetic device candidate list. Advantageous effects of the invention

[0011] According to the present invention, when an app is placed in any of the multiple arithmetic devices present in the network, the execution performance and communication performance of the app can be ensured by considering the arithmetic resources of the arithmetic devices and the communication resources between the arithmetic devices. This allows the app to run stably. Brief description of the drawings [ Fig. 1] Fig. 1 is a diagram of an electrical and electronic architecture of an in-vehicle device having an in-vehicle network system of the present invention. [ Fig. 2] Fig. Figure 2 is a hardware configuration diagram of a domain control unit (ECU), a zone ECU, a central ECU, and a gateway. [ Fig. 3] Fig. 3 is a functional block diagram of an in-vehicle network system of the present invention. [ Fig. 4] Fig. 4 is an ECU-inside resource availability information table stored by a resource availability information storage unit. [ Fig. 5] Fig. 5 shows a configuration example of over-the-air (OTA) data received from an app request storage unit via a telematics control unit (TCU). [ Fig. 6] Fig. 6 is an app request table stored by the app request storage unit. [ Fig. 7] Fig. 7 is a topology information table stored by a topology information storage unit. [ Fig. 8] Fig. 8 is an excerpt of a communication performance information table stored by a communication performance information storage unit. [ Fig. 9] Fig. 9 is a flowchart showing an operation of an app placement selecting unit. [ Fig. 10] Fig. 10 is an app placement target ECU candidate list output from the app placement selecting unit. [ Fig. 11] Fig. 11 is a flowchart showing an operation of a communication path selecting unit. [ Fig. 12] Fig. 12 is a flowchart showing an example of the detailed processing in step S209 in Fig. 11 shows. [ Fig. 13] Fig. 13 is a flowchart showing an example of detailed processing in step S221 in Fig. 12 shows. [ Fig. 14] Fig. 14 shows an example of results of executing the processing of Fig. 13 on a network of a zone architecture. [ Fig. 15] Fig. 15 is an app communication path candidate list output from the communication path selecting unit and input to a performance judging unit. [ Fig. 16] Fig. Figure 16 is a flowchart showing an activity of a performance assessment unit. [ Fig. 17] Fig. 17 is a flowchart showing an example of the detailed processing in step S302 in Fig. 16 shows. [ Fig. 18] Fig. 18 is a flowchart showing an example of the detailed processing in step S303 in Fig. 16 shows. [ Fig. 19] Fig. 19 is a flowchart showing an example of the detailed processing in step S305 in Fig. 16 shows. [ Fig. 20] Fig. 20 is a communication path list output from the performance determination unit and input to an app setting unit. [ Fig. 21] Fig. 21 is a flowchart showing an operation of the app setting unit. [ Fig. 22] Fig. 22 shows a configuration example of a communication path setting table used by the app setting unit. [ Fig. 23} Fig. 23 is a configuration diagram of the performance determination unit according to a second embodiment. [ Fig. 24] Fig. 24 is a flowchart showing an operation in step S305 in Fig. 16 shows activities of the performance determination unit in the second embodiment. [ Fig. 25] Fig. 25 is a functional block diagram of an in-vehicle network system according to a third embodiment. [ Fig. 26] Fig. 26 is an app request table stored by the app request storage unit according to a fourth embodiment. [ Fig. 27] Fig. 27 is an app request table stored by the app request storage unit according to the fourth embodiment. [ Fig. 28] Fig. 28 is an app request table stored by the app request storage unit according to a fifth embodiment. [ Fig. 29] Fig. Figure 29 is a flowchart showing an activity of a performance assessment unit. Description of the embodiments

[0012] Embodiments of the present invention will be described below with reference to the drawings. It should be noted that in each drawing, the same elements are designated by the same reference numerals, and redundant descriptions will be omitted where appropriate. [First embodiment]

[0013] An in-vehicle network system according to the first embodiment will be described below with reference to the drawings.

[0014] Fig. Figure 1 is a diagram of an electrical and electronic architecture of an in-vehicle device including an in-vehicle network system of the present invention. Two configurations are shown here as representative electrical and electronic architectures, but the application of the present invention is not limited thereto.

[0015] Fig. Figure 1(a) is a diagram illustrating a logical configuration of an architecture referred to as a domain-based architecture. This is a system in which in-vehicle electronic control units (ECUs) within a vehicle 1 are divided into functional categories called domains, and ECUs belonging to a domain are systematically connected. For each domain, a domain ECU 3 is placed to control each domain. Furthermore, the domain ECUs 3 are interconnected via a gateway 2 to enable communication between the domains. The domains include, for example, an ADAS (Advanced Driver Assistance System) domain that manages safe driving assistance, a PT / CH (Power Train / Chassis) domain that controls the movements of a vehicle in a front-to-rear direction and a left-to-right direction, a BODY domain that controls electrical devices such as the front and rear seats, and acontrols a power window, and an infotainment domain that controls navigation and audio. An ADAS control unit 3a, a PT / CH control unit 3b, a BODY control unit 3c, and an infotainment control unit 3d (hereinafter referred to collectively as 3) are each installed in the domains. Control units 4 and 5, such as sensors 4a to 4d (hereinafter also collectively referred to as 4) and actuators 5a to 5d (hereinafter also collectively referred to as 5), are each connected to the domain ECUs 3 through connections 6a to 6d (hereinafter also collectively referred to as 6), each suitable for the domains, such as a Controller Area Network (CAN) and a Local Interconnect Network (LIN). Multiple control units 4 and 5 can be connected to a single connection 6.Furthermore, a telematics control unit (TCU) 7, which communicates with a server, a cloud or the like outside the vehicle via a wireless network, is connected to the gateway 2.

[0016] The performance and functional requirements of domain ECUs can vary depending on the domain. For example, the ADAS ECU and the infotainment ECU, which process large amounts of data such as video, use hardware with high processing power. On the other hand, the PT / CH ECU, which is directly connected to safety, uses highly reliable hardware.

[0017] Fig. 1(b) is a diagram showing the physical configuration of an architecture referred to as a zone architecture. This is a system in which the control units 4 and 5 are classified according to spatial positions within the vehicle 1 and connected to the zone ECUs 9a to 9d (hereinafter also collectively referred to as 9) that control the positions. The zone architecture includes one or more zone ECUs 9, a center ECU 8 connected to the zone ECUs 9 and executing a plurality of apps across the plurality of domains, the sensors 4 and the actuators 5 respectively connected to the zone ECUs 9, and the like. As the name suggests, the zone ECUs 9 are each arranged at corresponding positions (zones) such as the front, rear, left, and right within the vehicle and are each connected to the sensors 4, the actuators 5, or both near the installation positions.Furthermore, the zone ECU 9 is connected to another zone ECU 9 via a common connection 10, which uses a common communication scheme between the domains. A switching network based on Ethernet (registered trademark) is assumed as the common communication scheme. Although the TCU 7 is connected to the central ECU 8 or any zone ECU 9, FIG. Fig. 1(b) an example in which the TCU 7 is connected to the central ECU 8.

[0018] Fig. 2 shows the hardware configurations of the domain ECU 3, the zone ECU 9, the central ECU 8 and the gateway 2. A thick line in Fig. 2 represents the common communication scheme, which is a connection scheme between communication devices 2 in the zone architecture or the domain architecture, and a thin line represents another communication scheme.

[0019] Fig. Figure 2(a) shows the hardware configuration of the domain ECU 3. The domain ECU 3 includes a central processing unit (CPU) 11, which processes the information received from the sensor 4 and the actuator 5 or the gateway 2, and a memory 12, which stores the data used by the CPU 11 to perform calculations. The CPU 11 has a connection to the gateway 2 and a connection to the sensor 4 and the actuator 5, and the connections are extended by the CPU 11.

[0020] Fig. Figure 2(b) shows the hardware configuration of the zone ECU 9. The zone ECU 9 has a network switch 13 for receiving a common link 10 for connecting to another zone ECU 9 or for connecting to the sensor 4 or the actuator 5. The zone ECU 9 further has a CPU 11 for processing the information received from the sensor 4 and the actuator 5 or the common link 10 and is connected to the network switch 13. The CPU 11 is also connected to the memory 12. If the sensor 4 and the actuator 5 support the common communication scheme, they can be directly connected to the network switch 13. If the sensor 4 and the actuator 5 do not support the common communication scheme, they are connected to the CPU 11, and the scheme can be converted to the common communication scheme.

[0021] Fig. Figure 2(c) shows a hardware configuration of gateway 2 in the domain-based architecture. Gateway 2 includes CPU 11, memory 12, and network switch 13 for connecting to domain ECUs 3.

[0022] Fig. Figure 2(d) shows the hardware configuration of the central ECU 8 in the zone-based architecture. The central ECU 8 has a configuration essentially the same as that of the gateway 2 and includes the CPU 11, the memory 12, and the network switch 13 for connecting to the zone ECUs 9.

[0023] Fig. Figure 3 is a functional block diagram of the in-vehicle network system of the present invention. Note that the functional blocks are designed as independent, Fig. 1 not shown devices can be implemented or implemented as software and controlled by any control unit in Fig. 1. In the case of implementation as software, the software can be used without affecting any function in any control unit in Fig. 1, but typically it is assumed that the software is implemented in the gateway in the case of the domain-based architecture and in the central ECU in the case of the zone architecture to manage the entire in-vehicle network.

[0024] The present invention includes functional blocks of a resource availability information storage unit 20, an app request storage unit 21, a topology information storage unit 22, a communication performance information storage unit 23, an app placement selection unit 24, a communication path selection unit 25, a performance determination unit 26, and an app setting unit 27.

[0025] The resource availability information storage unit 20 periodically collects and stores the resource status in each control device, such as information about an available CPU memory space and an available memory space.

[0026] The app request storage unit 21 stores execution requests for an app executed by each control unit in the vehicle. In the app request storage unit 21, the requests for apps pre-installed at the time of delivery of the vehicle are stored at the time of delivery, and the requests for apps added over-the-air (OTA) are received along with OTA data via the TCU 7. A concrete example of the requests will be explained with reference to Fig. 6 described.

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

[0028] The communication performance information storage unit 23 stores performance information about the currently performed communication, ie, a communication resource status between the control units for each connection in the in-vehicle network.

[0029] The app placement selection unit 24 determines a placement target ECU candidate of the app based on each ECU internal resource status retrieved from the resource availability information storage unit 20 and the execution request information about the ECU internal resource (arithmetic resource) of the app retrieved from the app request storage unit 21.

[0030] The communication path selection unit 25 determines communication path candidates for the communication performed by the app based on the app placement target ECU candidates determined by the app placement selection unit 24, the app communication target information retrieved from the app request storage unit 21, and the topology information about the in-vehicle network retrieved from the topology information storage unit 22.

[0031] The performance determination unit 26 checks the communication performance of the app against the communication path candidates of the app determined by the communication path selection unit 25 in a case where the communication path candidate is selected based on the communication requirements of the app retrieved from the app requirement storage unit 21 and the communication performance information retrieved from the communication performance information storage unit 23. As a result of the determination, the app selects a communication path to actually use from the path candidates that satisfy the communication performance.

[0032] The app setting unit 27 applies the communication path determined by the performance determination unit 26 to the in-vehicle network. For this purpose, an app data sending or receiving destination address, or similar, is retrieved from the app request storage unit 21 and a transmission rule is set for the path in the network switch 13 within the control unit.

[0033] Details of each functional block are described below.

[0034] Fig. 4 shows an ECU-internal resource availability information table 30 stored by the resource availability information storage unit 20. The ECU-internal resource availability information table 30 stores information about a computational resource column 32, a storage resource column 33, and a designation column 34 with respect to an ECU column 31. Designation represents characteristics of a control unit, such as high performance or high reliability.

[0035] Fig. 5 shows a configuration example of OTA data 40 received by the app request storage unit 21 via the TCU 7. The OTA data 40 includes a header 41 with an app ID and version information, app data 42 in which a code of an app body is stored in a binary format or the like, and metadata 43 about an app in the sense of the present invention. The metadata 43 stores execution requests 53, communication specifications 58, and communication requests 64 similar to those in Fig. 6 in conjunction with a communication ID 54, which is an identification number of the communication in the app. In a case where the app performs a plurality of communications, the metadata has a plurality of sets of the communication ID, the execution requests 53, the communication specifications 58, and the communication requests 64. Details of the execution requests 53, the communication specifications 58, and the communication requests 64 are similar to those in Fig. 6 and are therefore discussed with reference to Fig. 6 described.

[0036] Fig. 6 shows the app request table 50 stored by the app request storage unit 21. The app request table 50 stores a placement completion flag 52 indicating that an app has been placed in any ECU, the execution requests 53 containing a request for the ECU internal resource (arithmetic resource), the communication specifications 58 containing the specifications of communication between the ECUs, and the communication requests 64 containing the request for the communication resource between the ECUs, in conjunction with the app column 51 that stores each app ID. The execution requests 53 include a calculation resource column 55, a storage resource column 56, and a specification column 57.The communication specifications 58 further include a communication direction column 59, which indicates transmission or reception when viewing the app, a communication partner column 60 for specifying a communication partner of the app, a communication cycle column 61, a packet size column 62, and app identification information 63, which is information for specifying an app based on a communication packet, as app requirements regarding communication between the control units. Examples of the app identification information include a Controller Area Network (CAN) ID of CAN, a transmission source and destination Medium Access Control (MAC) address in Ethernet, transmission source and destination Internet Protocol (IP) addresses in IP, and a transmission source and destination port number in Transmission Control Protocol (TCP) or User Datagram Protocol (UDP).The communication requirements 64 include a communication band column 65, a communication delay column 66, a fluctuation column 67, and a loss rate column 68. Note that in a case where a single app performs a plurality of communications, the app expresses the plurality of communications using a plurality of lines, like app A3. Furthermore, an app that does not perform communication may specify only the execution requirements, like app A4.

[0037] Fig. 7 shows a topology information table 70 stored by the topology information storage unit 22. The topology information table 70 has a type column 72 and a connection information column 73 for a connection column 71 indicating connections between the control units in the in-vehicle network. The type column 72 describes whether a type of each connection is a bus type (a mode in which multiple control units are connected to a common communication path) or a mesh type (a mode in which one control unit is connected to another control unit on a one-to-one basis). The connection information column 73 stores an ID of a control unit connected to each connection.

[0038] Fig. 8 shows partial sections of a communication performance information table 80 stored by the communication performance information storage unit 23. The communication performance information table 80 has a communication direction 82, a total band column 83, a used band column 84, a delay time column 85, a fluctuation column 86, a loss rate column 87, and a buffer usage column 88 for a link column 81. The total band column 83 represents a total link band for each link and each communication direction. The usage band column 84 represents a band used by an existing app. The delay time column 85 represents a maximum delay time.

[0039] Fig. 9 is a flowchart showing an operation of the app placement selection unit 24. This flowchart is started in response to the app request table 50 being updated to add an app via OTA. First, in step S100, the app request table 50 is retrieved from the app request storage unit 21. Then, in step S101, the following processing is performed for each app registered in the app request table 50. In step S102, the placement completion flag of a target app is checked. If the placement is completed (Yes), processing proceeds to processing a next app without executing any operation. If the placement is not completed (No), step S103 and subsequent steps are executed. In step S103, it is checked whether the execution requirements of the target app are registered in the app request table 50.If the execution request has not been registered (No), the ECU candidate list defined previously in step S108 is sorted in descending order of total resources to determine ECU candidates of app placement targets, and processing proceeds to processing a next app. If the registration is completed (Yes), the following processing is performed. In step S104, the ECU internal resource availability information table 30 is retrieved from the resource availability information storage unit 20. In the subsequent step S105, among the ECUs in the ECU internal resource availability information table 30, the ECUs that have a computing resource and a memory resource greater than the computing resource and memory resource in the app execution requests and that satisfy the specification requested by the app are selected.Subsequently, the ECUs that meet the execution requirements requested by the app are selected, and the placement target ECU candidate list is created. Next, in step S106, the ECU candidate list is sorted in descending order of available resources to determine the app's placement target ECU candidates. In step S107, the loop termination for the apps is determined, and if processing is completed for all apps, this processing is terminated.

[0040] Fig. 10 shows an app placement target ECU candidate list 90 output from the app placement selection unit 24. The app placement target ECU candidate list 90 stores placement target ECU candidates 92 for each app column 91. The app placement target ECU candidate list 90 is a next input to the communication path selection unit 25.

[0041] Fig. 11 is a flowchart showing an operation of the communication path selecting unit 25. This flowchart is started in response to an input of the app placement target ECU candidate list 90 from the app placement selecting unit 24. First, in step S200, the app placement target ECU candidate list 90 is retrieved from the app placement selecting unit 24. In step S201, the topology information table 70 of the in-vehicle network is retrieved from the topology information storage unit 22. In step S202, it is checked whether the topology information about the in-vehicle network is included in the topology information table 70. In a case where the topology information is not included (No), the default topology information defined in advance in step S204 is used. In a case where the topology information is included in step S202 (Yes), the topology information in the topology information table 70 is used in step S203.

[0042] In the subsequent step S205, the following loop processing is performed for each app in the app column 91 of the app placement target ECU candidate list 90. First, in step S206, the communication partner information is retrieved from the app request storage unit 21 for each communication data (packet) of an app. Here, the communication partner information collectively refers to a data transmission source in received data and a data destination in transmitted data. In step S207, the communication partner information is checked, and if the communication partner information is not included (No), it is determined that communication is not performed, and processing proceeds to processing regarding a next app. If the communication partner information is included in step S207 (Yes), processing proceeds to step S208 and subsequent steps.

[0043] In step S208, a loop is started for the placement target ECU candidates 92 in the app placement target ECU candidate list 90. In step S209, path candidates from the transmission source to the data reception destination are determined in separately defined processing. If the processing in S209 is completed for all placement target ECU candidates, the loop with respect to the placement target ECU candidates is terminated in S210.

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

[0045] Fig. 12 is a flowchart showing an example of the detailed processing in step S209 in Fig. 11. First, in step S220, a loop is started for each communication belonging to an app. In the subsequent step S221, a path from the transmission source ECU to the destination ECU is searched for in a separately defined process. In step S222, if the path arrives at the destination ECU, the searched path is added to the path candidate list. Once processing for all communication data is completed, the loop ends in step S223, and this processing ends.

[0046] Fig. 13 is a flowchart showing an example of the detailed processing in step S221 in Fig. 12 shows. Here, the path from the transmission source ECU to the destination ECU is searched in broad-rank search, but the search may be performed based on another search algorithm such as deep-rank search. Fig. 14 shows an example of a search list 100 used in the present search processing. The search list 100 has a phase 101 indicating a search stage, a communication path candidate 102 indicating already searched path candidates from the transmission source ECU to the target ECU, and a state 103 indicating a state of the communication path candidate 102.

[0047] First, in step S230, a variable "phase" is set to 0, the state is set to incomplete, and the transmission source ECU is selected. This transmission source ECU is added to the search list as the first entry. In the subsequent step S231, the phase is incremented by 1. Next, in step S232, among the communication path candidates 102 whose states indicate incompleteness in the search list of a previous phase, a control unit directly connected to the topology is extracted from a control unit at the bottom of the path candidates, and the control unit added to the bottom of the communication path candidate 102 is added to the search list 100 in a current phase.

[0048] In step S233, a loop is started for the current phase search list 100 created as described above. In step S234, the states of the communication path candidate 102 are checked. First, in a case where the lower end of the communication path candidate 102 is the target ECU (S234a), the state 103 of the communication path is set to "arrival at destination" in step S235, and this ECU is added to the path candidate list output by the communication path selection unit 25 in step S236. Next, in a case where the lower end of the communication path candidate 102 is a searched ECU in step S234 (S234b), that is, in a case where multiple identical ECUs are included in the communication path candidate, the state 103 of the communication path candidate is set to "searched arrival" in step S237.If an ECU other than the searched ECU is found in step S234 (S234c), the communication path candidate state 103 is set to incomplete in step S238. If processing is completed up to the end of the search list of the current phase, the loop ends in step S239.

[0049] Finally, in step S240, it is checked whether the communication path candidate 102 whose status indicates incomplete is present in the search list of the current phase. If the communication path candidate 102 whose status indicates incomplete is present, processing returns to step S231 and continues. If no communication path candidate 102 whose status indicates incomplete is present, that is, if the search for the topology of the in-vehicle network is complete, this processing ends.

[0050] Fig. Figure 14 shows an example of the results of executing the processing of Fig. 13 on a network of a zone architecture. In the current phase, a list of communication path candidates is created by adding a next reachable ECU to a communication path candidate whose state indicates incomplete in the previous phase. Then, in phase 5, in a case where the state is destination arrival (the part of ECU C indicated by underline) or search-complete arrival (the part of ECU A indicated by italics), the search is completed.

[0051] Fig. 15 is an app communication path candidate list 110 output from the communication path selection unit 25 and input to the performance determination unit 26. The app communication path candidate list 110 stores communication path candidates 112 for an app column 111.

[0052] Fig. 16 is a flowchart showing an operation of the performance determination unit 26. First, in step S300, the app communication path candidate list 110 is received from the communication path selection unit 25. Next, in step S301, the loop for the apps described in the communication path candidate list 110 is executed. Next, in step S302, communication request information about the apps is retrieved from the app request storage unit 21 in a separately defined process. Next, in step S303, communication performance information in each connection on the in-vehicle network is retrieved from the communication performance information storage unit 23 in a separately defined process. Next, in step S304, the loop for path candidates for the apps described in the communication path candidate list 110 is performed.Next, the communication performance of the app at the time of using the selected path is evaluated based on the communication performance information about the path candidates and the app's communication requirement using a method separately defined in step S305. This evaluation result is determined in step S306, and if the app's communication requirement is not met (No), the loop continues with respect to the path candidate list. If a communication path that can satisfy the app's communication requirement exists in step S306 (Yes), a determination is made in step S310 that the app has been successfully placed, and the communication path information is output to the app setting unit 27. Subsequently, in step S311, the information is updated via the resource availability information storage unit 20 and the communication performance information storage unit 23.If no communication path exists that can satisfy the app's communication request and the loop ends in step S307, the app placement fails in step S308. Finally, processing is performed until the loop ends for each app in step S309.

[0053] Fig. 17 is a flowchart showing an example of detailed processing in step S302 in Fig. 16. This processing is processing for a specific app. First, in step S320, the app request storage unit 21 fetches a communication request for each piece of the app's communication data. Note that for an app that does not perform communication, no communication request is fetched. Next, it is checked whether the communication request data fetched in step S321 includes the app's communication request such as a communication band and a delay. If the communication request is included (Yes), the app's communication request from the app request storage unit 21 is used in step S322. If no communication request is included in step S321 (No), a predefined default communication request is used in step S323.

[0054] Fig. 18 is a flowchart showing an example of the detailed processing in step S303 in Fig. 16. Next, in step S330, the communication performance information for each connection in the in-vehicle network is retrieved from the communication performance information storage unit 23. In the next step S331, a loop is started for each connection in the in-vehicle network. In step S332, it is checked whether some communication performance information is included in the communication performance information retrieved for each connection. If the communication performance information is included (Yes), the communication performance information retrieved from the communication performance information storage unit 23 is used in step S333. If no communication performance information is included in step S332 (No), it is assumed that no communication is being performed via the connection in step S335. When the processing for all connections is completed, the loop is terminated in step S334.

[0055] Fig. 19 is a flowchart showing an example of the detailed processing in step S305 in Fig. 16 shows. Here, four values ​​of the communication band, delay, jitter, and packet loss rate are obtained by numerical calculation as communication performance on the link for each app. Since the four values ​​described above can be calculated independently, the following steps can be performed both sequentially and in parallel. First, in step S340, a loop is started for the links that each constitute the path candidates. Steps S341 to S344 can be executed independently. In step S341, the communication band in a case of adding the app is obtained by adding the communication band of the app to the usage band on the link. In step S342, a packet length of the app is added to the delay on the link to obtain a delay in the case of adding the app.The jitter is defined by a maximum value of a packet length transmitted on the link. The jitter on the link is compared with the app's packet length. If the app's packet length is greater than the jitter on the link, the jitter is updated to the app's packet length in step S343. The packet loss rate is generated by the overflow of a transmission buffer on the link. In step S344, a value obtained by adding the app's packet length to a buffer usage on the link is set as SUM, and in a case where the SUM is greater than a buffer size, the packet loss rate is obtained by a formula of (SUM - Buffer Size) / SUM. In step S345, the loop is terminated for the links that respectively constitute the path candidates.

[0056] Fig. 20 shows a communication path list 120 output by the performance determination unit 26 and input to the app setting unit 27. The communication path list 120 stores the communication path 122 selected by the performance determination unit 26 for the app column 121.

[0057] Fig. 21 is a flowchart showing an operation of the app setting unit 27. First, in step S400, the included apps are extracted from the communication path list 120 obtained from the performance determination unit 26, and an app list is created. Next, in step S401, the identification information about the apps included in the retrieved app list is retrieved from the app request storage unit 21. Next, in step S402, the communication path information is reconfigured, and a communication path setting table 130 is generated for each control unit. In the communication path setting table 130, the identification information about the apps through which the communication data passes is assigned to the next transmission destination ECU of the communication data. A configuration example of the communication path setting table 130 will be described with reference to Fig. 22. In the next step S403, the processing in step S404 is performed for each control unit in the communication path setting table 130. In step S404, the app identification information and the next transmission destination ECU are set for each control unit. In step S405, the loop to each control unit in the communication path setting table 130 is terminated. Finally, the apps included in the app list are set to the placement destination ECU. The placement destination ECU is the ECU at the head of the transmission data or at the foot of the reception data in the app's communication path.

[0058] Fig. 22 shows a configuration example of the communication path setting table 130 used in the app placement unit 27. The communication path setting table 130 stores app identification information 132 about the app through which the communication data passes and a next transmission destination ECU 133 for the ECU column 131. Regarding the data received from the app in the app placement destination ECU, the transmission destination is referred to as the CPU.

[0059] With the above action, the in-vehicle network system can install a new app in the ECU when adding an app via OTA, taking into account the computing and storage resources in the ECU and the communication resources. Furthermore, when updating an existing app via OTA, the app can be installed using a similar process. (Summary)

[0060] In the present embodiment, a network system in which an app is placed in any one of a plurality of arithmetic devices 3 and 9 present in a network to satisfy execution requests 53 of the app, the network system includes an app request storage unit 21 that stores the execution requests 53 and a communication request 64 of the app, a resource availability information storage unit 20 that stores resource availability information about the plurality of arithmetic devices 3 and 9, an app placement selection unit 24 that selects an arithmetic device capable of executing the app from the plurality of arithmetic devices 3 and 9 based on the execution requests 53 and the resource availability information and creates an app placement target arithmetic device candidate list 90, a topology information storage unit 22 that stores topology information,which indicate a communication connection relationship of the plurality of arithmetic devices 3 and 9, a communication performance information storage unit 23 which stores communication performance information about network connections, a communication path selection unit 25 which selects a communication path of the app in a case where the app is placed in each arithmetic device in the app placement target arithmetic device candidate list 90, and creates a communication path candidate list 110 based on the topology information, a performance determination unit 26 which determines whether the communication requirements 64 are satisfied in each communication path in the communication path candidate list 110 based on the communication performance information and the communication requirements 64, and an app setting unit 27 which places the app in an arithmetic device corresponding to a communication path whose communication requirement 64,whose fulfillment has been determined by the performance determination unit 26, is among the arithmetic devices in the app placement target arithmetic device candidate list 90.,

[0061] Furthermore, in the present embodiment, a network management method for placing an app in any one of a plurality of arithmetic devices 3 and 9 present in a network to satisfy execution requests 53 of the app is provided, the network management method comprising maintaining the execution requests 53 and a communication request 64 of the app, maintaining resource availability information about the plurality of arithmetic devices 3 and 9, selecting an arithmetic device capable of executing the app from the plurality of arithmetic devices 3 and 9 based on the execution requests 53 and the resource availability information, and creating an app placement target arithmetic device candidate list 90, maintaining topology information indicating a communication connection relationship of the plurality of arithmetic devices 3 and 9, maintaining communication performance information about network connections,Selecting a communication path of the app in a case where the app is placed in each arithmetic device in the app placement target arithmetic device candidate list 90, and creating a communication path candidate list 110 based on the topology information, checking whether the communication requirements 64 are satisfied in each communication path in the communication path candidate list 110 based on the communication performance information and the communication requirements 64, and placing the app in an arithmetic device corresponding to a communication path whose communication requirements 64 were determined to be satisfied when determining the performance among the arithmetic devices in the app placement target arithmetic device candidate list 90.

[0062] According to the present embodiment configured as described above, when an app is placed in one of the plurality of arithmetic devices 3 and 9 present in the network, the execution performance and the communication performance of the app can be ensured by taking into account the arithmetic resources of the arithmetic devices 3 and 9 and the communication resources between the arithmetic devices, thereby stably executing the app.

[0063] Furthermore, in the present embodiment, the communication requirements 64 and the communication performance information include one or more of the communication bands, the communication delay, the communication jitter, and the packet loss rate of the app. This makes it possible to define the communication requirements 64 and the communication performance information for the app.

[0064] Furthermore, according to the present embodiment, the performance determination unit 26 checks whether the communication requirements 64 are met in each communication path of the communication path candidate list 110 using a numerical calculation based on the communication performance information and the communication requirements 64. Thus, it can be easily determined for each communication path of the communication path candidate list 110 whether the communication requirements 64 are met.

[0065] Furthermore, according to the present embodiment, the performance determination unit 26 checks, based on the communication performance information and the communication requirements 64, through simulation whether the communication requirements 64 are met in each communication path of the communication path candidate list 110. Thus, for each communication path in the communication path candidate list 110, it can be accurately determined whether the communication requirements 64 are met.

[0066] In the present embodiment, the metadata 43, which is input to the network along with the app when the app is deployed, includes the execution requirements 53, including one or more of the computing resource, the storage resource, and the specifications; the communication specifications 58, including one or more of the communication direction, the communication party, the communication cycle, the communication data size, and the communication identification information; and the communication requirements 64, including one or more of the communication band, the communication delay, the communication jitter, and the packet loss rate. This makes it possible to define the execution requirements 53, the communication specifications 58, and the communication requirements 64 of the app.

[0067] The network in the present embodiment is the in-vehicle network mounted on a vehicle, and the plurality of arithmetic devices 3 and 9 are the plurality of in-vehicle electronic control devices 3 and 9 mounted on the vehicle. This makes it possible to stably execute the newly placed app in the in-vehicle network.

[0068] The in-vehicle unit in the present embodiment includes the network system. This enables the newly installed app to operate stably in the in-vehicle unit.

[0069] Furthermore, the communication requests 64 in the present embodiment include parts related to sensor data output from the sensors 4 mounted on the vehicle, control data for controlling the vehicle, and intermediate data obtained from the sensor data during calculations to obtain the control data. This makes it possible to define the communication requests 64 according to the requirement performance of the in-vehicle device. [Second embodiment]

[0070] In the first embodiment, the communication performance was estimated using numerical calculations. Although this method is simple due to the low computational complexity, the accuracy of the estimation is low. Therefore, in the second embodiment, a method for estimating communication performance using network simulation is described as another method.

[0071] The main configuration and operation flow in the present embodiment are similar to those of the first embodiment. Only the differences from the first embodiment will be described below.

[0072] Fig. 23 is a configuration diagram of the performance determination unit 26 according to the second embodiment. The performance determination unit 26 in the present embodiment can have approximately two configurations. Fig. Figure 23(a) is the configuration diagram for a case where the simulation is performed in a vehicle. The performance determination unit 26 includes a simulation unit 28 and causes the simulation unit 28 to perform a simulation to determine the performance. Fig. Figure 23(b) is the configuration diagram for the case where the simulation is performed outside the vehicle. Here, "outside the vehicle" means a computing resource other than the vehicle itself, such as a cloud, multi-access edge computing (MEC), a roadside machine, or another vehicle. The performance determination unit 26 communicates with the simulation unit 28 installed outside the vehicle via wireless communication or the like and transmits the required settings to the simulation unit 28. The performance determination unit 26 then instructs the simulation unit 28 to perform a simulation and receives a result from the simulation unit 28.

[0073] Fig. 24 is a flowchart showing an operation in step S305 in Fig. 16 shows the operation of the performance determination unit 26 in the second embodiment. First, in step S500, simulation settings are created. Next, in step S501, the simulation unit 28 is operated to perform a simulation. Finally, in step S502, a performance evaluation result is obtained from the simulation result for each section (link) of the candidate path. The performance evaluation result includes a communication band, delay, jitter, packet loss rate, and the like.

[0074] As described above, the invention according to the present embodiment makes it possible to evaluate performance with higher accuracy, increase a storage capacity for apps, and improve the stability of app operation. (Summary)

[0075] The performance determination unit 26 of the network system according to the present embodiment checks, based on the communication performance information and the communication requirements 64, by simulation whether the communication requirements 64 are satisfied in each communication path of the communication path candidate list 110.

[0076] The above-described configuration according to the present embodiment makes it possible to accurately check whether the communication requirements 64 are satisfied for each communication path in the communication path candidate list 110.

[0077] Furthermore, in a performance determination step of a network management method according to the present embodiment, a determination is made as to whether the communication requirements 64 are satisfied in each communication path in the communication path candidate list 110 by simulation based on the communication performance information and the communication requirements 64 with a computer in the vehicle interior. This makes it possible to perform the simulation even in an environment where the network system cannot communicate with the outside world.

[0078] Furthermore, in the performance determination step of the network management method according to the present embodiment, a determination is made as to whether the communication requirements 64 are satisfied in each communication path in the communication path candidate list 110 with simulation based on the communication performance information and the communication requirements 64 with a computer outside the vehicle. This can improve the accuracy of the simulation because the resources for performing the simulation are not limited. [Third Embodiment]

[0079] In the first and second embodiments, it is assumed that the topology of the in-vehicle network is fixed. On the other hand, the topology of the in-vehicle network may change due to the addition of a new device to the CAN, a communication interruption due to a hardware anomaly, or the like. Therefore, the third embodiment describes an in-vehicle network system capable of following such a topology change.

[0080] Fig. 25 is a functional block diagram of the in-vehicle network system according to the third embodiment. Compared to Fig. 3, a topology change monitoring unit 29 has been added.

[0081] The topology change monitoring unit 29 monitors the state of the in-vehicle network using a "bus failure" or "error" state in CAN and a method such as Link Level Discovery Protocol (LLDP) in Ethernet. The state of the in-vehicle network refers to whether the connection on the in-vehicle network is in a normal communication state. In the normal state, no action is taken. If an abnormality is detected, the connection information in the topology information table 70 of the topology information storage unit 22 is deleted or marked as an abnormal state and not used. After that, the apps, including the placed apps, are placed again. That is, the communication path selection unit 25, the performance determination unit 26, and the app setting unit 27 are operated to place the app and the communication path while preventing the connection from entering the abnormal state. (Summary)

[0082] The network system according to the present embodiment further includes the topology change monitoring unit 29 that detects a topology change of the network and informs the topology information storage unit 22 of the detected topology change.

[0083] The above configuration according to the present embodiment makes it possible to place the app in the arithmetic devices 3 and 9 so that the execution requests 53 and the communication requests 64 are satisfied even in a case where the topology of the network changes. [Fourth Embodiment]

[0084] In the first and second embodiments, in a case where multiple apps are added via OTA, the order of adding the apps is not considered. Therefore, an app added earlier may consume resources within the ECU and communication resources between ECUs, and an app added later may not be added. Therefore, in a case where the rank varies between apps, a high-ranking app is not added.

[0085] Therefore, the fourth embodiment will describe a device that places an app among apps in consideration of rank.

[0086] Fig. Figure 26 shows the app request table 50 stored by the app request storage unit 21 according to the fourth embodiment. A difference from the first to third embodiments is that a rank column 69 has been added to the communication specifications 58. In Fig. 26, the rank is set to eight values ​​between 0 and 7, where 0 is the lowest rank and 7 is the highest rank. Since the execution requirements 53 and the communication requirements 64 are identical to those of the first and third embodiments, the description of the individual columns is omitted.

[0087] Fig. Fig. 27 is a flowchart showing an operation of the app placement selection unit 24 according to the fourth embodiment. The same numbers are assigned to the same processing as those of the flowchart ( Fig. 9) in the first embodiment. The only difference between the first and third embodiments is that the loop processing in step S101 is changed to step S600. In step S600, in the present embodiment, the loop is performed with respect to the app in descending order of rank in the app request table 50. As a result, the ECU placement and communication path for apps with higher ranks are determined earlier. (Summary)

[0088] In the present embodiment, the app request storage unit 21 stores the rank for each app. The app placement selection unit 24 creates the app placement target arithmetic device candidate list 90 in descending order of the rank of the apps.

[0089] The above configuration according to the present embodiment makes it possible to place the apps in the arithmetic devices 3 and 9 in descending order of rank. [Fifth Embodiment]

[0090] In the first to fourth embodiments, each part of the communication request is handled based on the same priority, but the degree of satisfaction of the request may vary between communication requests depending on the app. Therefore, in the fifth embodiment, a configuration is described in which the communication request to be specifically satisfied can be determined for each app.

[0091] Fig. Figure 28 is the app request table 50 stored by the app request storage unit 21 according to the fifth embodiment. A difference from the first to fourth embodiments is that the rank columns 69a to 69d have been added for the respective parts of the communication request. Fig. 28, the rank is set to eight values ​​between 0 and 7, with 0 being the lowest rank and 7 being the highest rank. By using the rank for the respective parts of the communication requirement, the apps can be placed in such a way that the communication requirement for each app is particularly met.

[0092] Fig. Figure 29 is a flowchart showing an activity of the performance assessment unit 26. The same numbers are assigned to the same processing as those of the flowchart ( Fig. 16) in the first embodiment. A difference from the first embodiment is that step S306 is changed to step S700, and the app placement in step S308 does not fail immediately after the end of step S307, but the app placement is retried after the lowest-ranked part is excluded from the communication request in steps S700 and S701.

[0093] In step S700, based on the evaluation of the app's communication performance, it is determined whether the app's communication performance can satisfy the communication requirement with a preference greater than 0. If the requirement is satisfied (Yes), i.e., the app placement is successful, step S310 and the subsequent steps are executed. If the requirement is not satisfied (No), the path candidate list loop ends in step S307.

[0094] In step S701, the rank of the communication request of the apps in the app request table 50 is checked. If the rank in two or more communication requests has a value greater than 0, a determination is made that the communication request with the lowest rank among the communication requests with a rank greater than 0 can be excluded. If it is determined in step S701 that exclusion is possible (Yes), in step S702, the rank of the communication request determined as excludable in step S700 is overwritten with 0. If it is determined in step S701 that exclusion is impossible (No), processing proceeds to step S308, and the app placement is deemed to have failed.

[0095] As described above, the particular requirement to be satisfied can be determined among the communication requirements, and the app placement that satisfies the requirement can be implemented. (Summary)

[0096] The app request storage unit 21 in the present embodiment maintains the rank for each piece of the communication requests 64 of each app. The performance determination unit 26 excludes a piece with the lowest rank from the communication requests 64 and re-determines whether the communication requests 64 are satisfied if one or more unsatisfied pieces exist in the communication requests 64.

[0097] The above configuration according to the present embodiment makes it possible to place more apps in the arithmetic devices 3 and 9 by excluding a low-rank part from the communication requests 64 of each app.

[0098] 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 for a simple understanding of the present invention, and the present invention is not necessarily limited to those having all the described configurations. Furthermore, a part of the configuration of a specific embodiment may be added to the configuration of another embodiment, a part of the configuration of the specific embodiment may be deleted, or a part of the configuration of the other embodiment may be replaced. Reference character list 1 vehicle 2 Gateway 3, 3a to 3d Domain ECU (arithmetic unit and electronic vehicle interior control unit) 4, 4a to 4d sensor 5, 5a to 5d actuator 6, 6a to 6d connection 7 TCU 8 Central ECU (arithmetic unit and electronic vehicle interior control unit) 9, 9a to 9d Zone ECU (arithmetic unit and electronic vehicle interior control unit) 10 common connection 11 CPU 12 storage 13 network switches 20 Resource Availability Information Storage Unit 21 App request storage unit 22 Topology information storage unit 23 Communication performance information storage unit 24 App placement dialer 25 Communication path selection unit 26 performance assessment unit 27 App setting unit 28 Simulation Unit 29 Topology change monitoring unit 30 ECU internal resource availability information table 31 ECU column 32 Computational Resource Column 33 Memory resource column 34 Determination column 40 OTA data 41 head 42 App data 43 metadata 50 App requirements table 51 App column 52 Placement Completion Flag 53 Execution requirement 54 Communication ID 55 Computational Resource Column 56 Memory resource column 57 Determination column 58 Communication determination 59 Communication direction column 60 Communication participant column 61 Communication cycle column 62 Package size column 63 App identification information 64 communication requirements 65 communication band gap 66 Communication delay column 67 Fluctuation column 68 Loss rate column 69, 69a to 69d rank column 70 Topology information table 71 connecting column 72 Type column 73 Connection information column 80 Communication Performance Information Table 81 connecting column 82 Communication direction 83 total band gap 84 band gaps 85 Delay time column 86 fluctuation column 87 Loss rate column 88 Buffer usage column 90 App placement target ECU candidate list (App placement target arithmetic device candidate list) 91 App column 92 Placement Target ECU Candidate 100 search list 101 Phase 102 communication path candidates 103 Condition 110 Communication path candidate list 111 App column 112 communication path candidates 120 Communication path list 121 App column 122 Communication path 130 Communication path setting table 131 ECU column 132 App identification information 133 Transmission destination ECU

Claims

[1] A network system in which an application is placed in any of a plurality of arithmetic devices existing in a network to meet execution requirements of the application, the network system comprising: an app request storage unit that stores the execution requests and communication requests of the app; a resource availability information storage unit that stores resource availability information about the plurality of arithmetic devices; an app placement selection unit that selects an arithmetic device capable of executing the app from the plurality of arithmetic devices based on the execution requirements and the resource availability information, and creates an app placement target arithmetic device candidate list; a topology information storage unit that stores topology information indicating a communication connection relationship of the plurality of arithmetic devices; a communication performance information storage unit that stores communication performance information about network connections; a communication path selection unit that selects a communication path of the app in a case where the app is placed in each arithmetic device in the app placement target arithmetic device candidate list, and creates a communication path candidate list based on the topology information; a performance determination unit that determines, based on the communication performance information and the communication requirements, whether the communication requirements are met in each communication path of the communication path candidate list; and an app setting unit that places the app in an arithmetic device corresponding to a communication path whose communication requirements are determined to be satisfied by the performance determination unit among the arithmetic devices in the app placement target arithmetic device candidate list. [2] The network system of claim 1, wherein the communication requirements and the communication performance information include one or more of the following: a communication band, a communication delay, a communication jitter, and a packet loss rate of the app. [3] The network system according to claim 1, wherein the performance determination unit determines whether the communication requirements are satisfied in each communication path in the communication path candidate list by numerical calculation based on the communication performance information and the communication requirements. [4] The network system according to claim 1, wherein the performance determination unit determines whether the communication requirements are satisfied in each communication path in the communication path candidate list by simulation based on the communication performance information and the communication requirements. [5] The network system according to claim 1, further comprising a topology change monitoring unit that detects a topology change of the network and notifies the topology information storage unit of the detected topology change. [6] Network system according to claim 1, wherein the app request storage unit holds a rank for each app, and wherein the app placement selecting unit creates the app placement target arithmetic device candidate list in descending order of rank. [7] Network system according to claim 1, wherein the app request storage unit holds a rank for parts of the communication requests, and wherein the performance determination unit excludes a lowest-ranking part from the communication requirements and, in a case where one or more unsatisfied parts exist in the communication requirements, re-determines whether the communication requirements are met. [8] The network system of claim 1, wherein the metadata that is entered into the network along with the app when the app is placed comprises the execution requirements including one or more computing resources, a memory resource and specifications, the communication specifications including one or more communication directions, a communication participant, a communication cycle, a communication data size and communication identification information, and the communication requirements including one or more communication bands, a communication delay, a communication jitter, and a packet loss rate. [9] Network system according to claim 1, wherein the network is an in-vehicle network mounted on a vehicle, and wherein the plurality of arithmetic devices are a plurality of in-vehicle electronic control devices mounted on the vehicle. [10] An in-vehicle device comprising the network system according to claim 9. [11] The network system according to claim 9, wherein the communication requests include parts related to sensor data output from a sensor mounted on the vehicle, control data for controlling the vehicle, and intermediate data obtained from the sensor data during calculations for obtaining the control data. [12] A network management method for placing an application in any of a plurality of arithmetic devices existing in a network to meet execution requirements of the application, the network management method comprising: Storing the app's execution and communication requirements; Storing resource availability information about the plurality of arithmetic devices; Selecting an arithmetic device capable of executing the app from the plurality of arithmetic devices based on the execution requirements and the resource availability information, and creating an app placement target arithmetic device candidate list; Storing topology information indicating a communication connection relationship of the plurality of arithmetic devices; Storing communication performance information about network connections; Selecting a communication path of the app in a case where the app is placed in each arithmetic device in the app placement target arithmetic device candidate list and creating a communication path candidate list based on the topology information; Determining whether the communication requirements are met in each communication path in the communication path candidate list based on the communication performance information and the communication requirements; and Placement of the app in an arithmetic device corresponding to a communication path whose communication requirements are considered satisfied when determining performance among the arithmetic devices in the app placement target arithmetic device candidate list. [13] Network management method according to claim 12, wherein the network is an in-vehicle network mounted on a vehicle, and wherein the plurality of arithmetic devices are a plurality of electronic vehicle interior control devices present in the vehicle. [14] The network management method according to claim 13, wherein in the performance determination, a determination is made as to whether the communication requirements are satisfied in each communication path in the communication path candidate list by simulation with a computer in the vehicle on the basis of the communication performance information and the communication requirements. [15] The network management method according to claim 13, wherein in the performance determination, a determination is made by simulation with a computer outside the vehicle based on the communication performance information and the communication requirements as to whether the communication requirements are satisfied in each communication path in the communication path candidate list.

Images