WO2024111175A1 - ネットワークシステム、およびネットワーク管理方法 - Google Patents

ネットワークシステム、およびネットワーク管理方法 Download PDF

Info

Publication number
WO2024111175A1
WO2024111175A1 PCT/JP2023/028821 JP2023028821W WO2024111175A1 WO 2024111175 A1 WO2024111175 A1 WO 2024111175A1 JP 2023028821 W JP2023028821 W JP 2023028821W WO 2024111175 A1 WO2024111175 A1 WO 2024111175A1
Authority
WO
WIPO (PCT)
Prior art keywords
communication
application
requirements
network
communication path
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2023/028821
Other languages
English (en)
French (fr)
Inventor
裕司 大石
勇太 武藤
和 三村
功治 前田
隆 村上
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Astemo Ltd
Original Assignee
Hitachi Astemo Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Astemo Ltd filed Critical Hitachi Astemo Ltd
Priority to CN202380060698.3A priority Critical patent/CN119654848A/zh
Priority to DE112023002997.0T priority patent/DE112023002997T5/de
Publication of WO2024111175A1 publication Critical patent/WO2024111175A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5054—Automatic deployment of services triggered by the service manager, e.g. service implementation by automatic configuration of network components
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies

Definitions

  • the present invention relates to a network system and a network management method for deploying applications to multiple computing devices on a network.
  • 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.
  • a vehicle system is made up of multiple electronic control units (ECUs) connected via a network.
  • ECU is used as a general term for sensors such as cameras, actuators that operate the engine and steering, etc., 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 strain on the in-vehicle network, but the load on the in-vehicle network varies depending on the placement of the apps.
  • Patent Document 1 discloses a method for selecting an ECU that will run an app when adding an app.
  • an in-vehicle system equipped with multiple ECUs on which additional apps acquired by an app acquisition unit can be installed includes a request specification unit, a resource specification unit, and a selection unit.
  • the request specification unit specifies requested resources, which are resources required by the additional app.
  • the resource specification unit specifies provided resources, which are resources that can be provided by each ECU.
  • the selection unit selects an ECU whose provided resources satisfy the requested resources as the installation destination for the additional app.
  • Patent Document 1 can select the ECU where an app is to be placed based on the ECU's computational resources, but it cannot place apps while taking into account communication resources between ECUs, such as the load status of the in-vehicle network.
  • the present invention has been made in consideration of the above problems, and its purpose is to provide a network system and a network management method that enable the placement of applications taking into account the computing resources of each computing device on the network and the communication resources between the computing devices.
  • the present invention provides a network system that places an application on one of a plurality of computing devices on a network so as to satisfy the execution requirements of the application, the network system comprising: an application requirement storage unit that stores the 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 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 free resource information, and creates a list of computing device candidates for application placement; a topology information storage unit that stores topology information indicating the communication connection relationship 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 placed on each computing device in the computing device candidate list for application placement based on the topology information, and creates a communication path candidate list; a performance verification unit that verifies whether the communication requirements are satisfied by each communication path
  • the present invention also provides a network management method for placing an application on one of a plurality of computing devices on a network so as to satisfy the execution requirements of the application, the method comprising: an application requirement holding step for holding the execution requirements and communication requirements of the application; a free resource information holding step for holding free resource information of the plurality of computing devices; an application placement selection step for selecting a computing device capable of executing the application from among the plurality of computing devices based on the execution requirements and the free resource information, and creating a list of computing device candidates for application placement; a topology information holding step for holding topology information indicating the communication connection relationship of the plurality of computing devices; a communication performance information holding step for holding communication performance information of each link of the network; a communication path selection step for selecting a communication path for the application when the application is placed on each computing device in the computing device candidate list for application placement based on the topology information, and creating a communication path candidate list; a performance verification step for verifying whether the communication requirements are satisfied on each communication path in the communication path candidate list based on the
  • the computing resources of each computing device and the communication resources between the computing devices are taken into consideration, thereby ensuring the execution and communication performance of the app, thereby enabling the app to operate stably.
  • FIG. 1 is a diagram of the electrical and electronic architecture of an in-vehicle device incorporating an in-vehicle network system according to the present invention
  • Hardware configuration diagram of domain ECU, zone ECU, central ECU, and gateway Functional block diagram of an in-vehicle network system according to the present invention is a diagram of the electrical and electronic architecture of an in-vehicle device incorporating an in-vehicle network system according to the present invention.
  • ECU free resource information table held by free resource information holding unit Example of the configuration of OTA data received by the application requirement storage unit via the TCU Application requirement table held by the application requirement holding unit Topology information table held by the topology information holding unit An excerpt from the communication performance information table stored in the communication performance information storage unit Flowchart showing the operation of the application placement selection unit A list of ECU candidates for application placement that is the output of the application placement selection unit Flowchart showing the operation of the communication path selection unit A flowchart showing an example of detailed processing of step S209 in FIG. A flowchart showing an example of detailed processing of step S221 in FIG. 12. An example of the results of executing the process of FIG.
  • FIG. 13 on a network of a zone architecture
  • a list of application communication route candidates output from the communication route selection unit and input to the performance verification unit Flowchart showing the operation of the performance verification unit
  • a flowchart showing an example of detailed processing of step S302 in FIG. A flowchart showing an example of detailed processing of step S303 in FIG. 16.
  • a communication path list output from the performance verification unit and input to the configuration application unit Flowchart showing the operation of the setting application unit
  • FIG. 13 is a configuration diagram of a performance verification unit in the second embodiment.
  • 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.
  • a functional block diagram of an in-vehicle network system according to a third embodiment.
  • Application requirement table held by the application requirement holding unit in the fourth embodiment Application requirement table held by the application requirement holding unit in the fourth embodiment
  • Application requirement table held by the application requirement holding unit in the fifth embodiment Flowchart showing the operation of the performance verification unit
  • FIG. 1 shows 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 representative electrical and electronic architectures, but the application of the present invention is not limited to these.
  • Figure 1(a) shows the logical structure of an architecture called 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.
  • a domain ECU 3 is placed for each domain to manage that domain.
  • the domain ECUs 3 are connected to each other via a gateway 2 to enable communication between domains.
  • domains examples include the ADAS (Advanced Driver Assistance System) domain, which is responsible for safe driving assistance; the PT/CH (Power Train/Chassis) domain, which controls the vehicle's forward/rearward and left/right movements; the BODY domain, which controls electrical equipment such as power windows; and the Infotainment domain, which controls navigation and audio.
  • ADAS Advanced Driver Assistance System
  • PT/CH Power Train/Chassis
  • BODY which controls electrical equipment such as power windows
  • Infotainment domain which controls navigation and audio.
  • An ADAS ECU 3a, PT/CH ECU 3b, BODY ECU 3c, and Infotainment ECU 3d are placed for each domain.
  • ECUs 4, 5 such as sensors 4a-4d (hereinafter collectively referred to as 4) and actuators 5a-5d (hereinafter collectively referred to as 5) are connected to the domain ECU 3 via links 6a-6d (hereinafter collectively referred to as 6) appropriate for each domain, such as a Controller Area Network (CAN) or a Local Interconnect Network (LIN).
  • CAN Controller Area Network
  • LIN Local Interconnect Network
  • Multiple ECUs 4, 5 may be connected to a single link 6.
  • a TCU (Telematics Control Unit) 7 that communicates with servers outside the vehicle, clouds, etc. via a wireless network is connected to the gateway 2.
  • ADAS ECUs and Infotainment ECUs use hardware with high processing performance to handle large volumes of data such as video.
  • PT/CH ECUs use highly reliable hardware to ensure a safe direct connection.
  • Figure 1(b) shows the physical configuration of an architecture called zone architecture.
  • zone architecture This is a method of classifying ECUs 4, 5 according to their spatial positions inside the vehicle 1, and connecting them to zone ECUs 9a to 9d (hereinafter collectively referred to as 9) that manage these positions. It is composed of one or more zone ECUs 9, a central ECU 8 that is connected to the zone ECU 9 and executes multiple applications across multiple domains, and sensors 4 and actuators 5 that are connected to the zone ECU 9.
  • the zone ECUs 9 are arranged corresponding to positions (zones) such as front, rear, left and right in the vehicle, and are connected to sensors 4 or actuators 5, or both, that are close to the installation position.
  • zone ECUs 9 are connected to other zone ECUs 9 by shared links 10 that use a common communication method between domains.
  • the common communication method is assumed to be a switching network using Ethernet (registered trademark).
  • the TCU 7 is connected to the central ECU 8 or any zone ECU 9, but Figure 1(b) shows an example of connection to the central ECU 8.
  • Figure 2 shows the hardware configuration of the domain ECU 3, zone ECU 9, central ECU 8, and gateway 2.
  • the thick lines in Figure 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.
  • FIG. 2(a) shows the hardware configuration of the domain ECU 3.
  • a CPU Central Processing Unit
  • FIG. 1 shows the hardware configuration of the domain ECU 3.
  • a CPU Central Processing Unit
  • FIG. 1 shows the hardware configuration of the domain ECU 3.
  • a CPU Central Processing Unit
  • FIG. 1 shows the hardware configuration of the domain ECU 3.
  • a CPU Central Processing Unit
  • FIG. 1 shows the hardware configuration of the domain ECU 3.
  • a CPU Central Processing Unit
  • memory 12 for holding data used for calculations by the CPU 11.
  • From the CPU 11 there are links for connecting to the gateway 2 and to the sensors 4 and actuators 5.
  • FIG. 2(b) shows the hardware configuration of the zone ECU 9.
  • the zone ECU 9 has a network switch 13 that accommodates a shared link 10 for connecting to other zone ECUs 9 or for connecting to the sensor 4 or actuator 5.
  • the zone ECU 9 also has a CPU 11 for processing information received from the sensor 4 and actuator 5 or the shared link 10, and is connected to the network switch 13.
  • the CPU 11 is also connected to a memory 12. If the sensor 4 and actuator 5 support a common communication method, they may be directly connected to the network switch 13. If the sensor 4 and actuator 5 do not support a common communication method, they can be connected to the CPU 11 and converted to the common communication method.
  • FIG. 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.
  • FIG. 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.
  • FIG. 3 is a functional block diagram of an in-vehicle network system according to the present invention.
  • the functional blocks may be implemented as independent devices not shown in FIG. 1, or may be implemented as software and executed by any of the ECUs in FIG. 1.
  • the present invention comprises the following functional blocks: free resource information holding unit 20, application requirement holding unit 21, topology information holding unit 22, communication performance information holding unit 23, application placement selection unit 24, communication path selection unit 25, performance verification unit 26, and setting application unit 27.
  • the free resource information storage unit 20 periodically collects and stores information about the resource status within each ECU, such as free CPU capacity and free memory capacity.
  • 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 that are pre-installed when the vehicle is shipped, and requirements for applications added via OTA are received via the TCU 7 together with OTA data. Specific examples of requirements will be explained using Figure 6.
  • the topology information storage unit 22 stores topology information that indicates the connection relationships of the in-vehicle network.
  • the communication performance information storage unit 23 stores performance information of the currently ongoing communication for each link in the in-vehicle network, i.e., the communication resource status between ECUs.
  • the application placement selection unit 24 determines candidate ECUs for placement of the application based on the resource status inside each ECU obtained from the free resource information storage unit 20 and execution requirement information related to the application's ECU internal resources (computational resources) obtained from the application requirement storage unit 21.
  • the communication path selection unit 25 determines communication path candidates for communication performed by the app based on the candidate ECUs for placement of the app determined by the app placement selection unit 24, the communication destination information of the app obtained from the app requirement storage unit 21, and the topology information of the in-vehicle network obtained from the topology information storage unit 22.
  • the performance verification unit 26 verifies the communication performance of the application when the communication route candidate is selected for the application's communication route candidate determined by the communication route selection unit 25, based on the application's communication requirements acquired from the application requirement storage unit 21 and the communication performance information acquired from the communication performance information storage unit 23. From the route candidates that satisfy the communication performance of the application as a result of the verification, one communication route to be actually used is selected.
  • the setting application unit 27 applies the communication path determined by the performance verification unit 26 to the in-vehicle network. To this end, it obtains the 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.
  • FIG. 4 shows the intra-ECU free resource information table 30 held by the free resource information holding unit 20.
  • the intra-ECU free resource information table 30 holds information in a computational resource column 32, a memory resource column 33, and a spec column 34 for an ECU column 31.
  • the specs refer to the characteristics of an ECU, such as high performance and high reliability.
  • FIG. 5 shows an example of the configuration 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 code of the application itself in binary format, etc., and metadata 43 related to the application referenced in the present invention.
  • Metadata 43 holds execution requirements 53, communication specifications 58, and communication requirements 64 similar to those in application requirement table 50 shown in FIG. 6, corresponding to communication ID 54, which is an identification number for communication in the application.
  • communication ID 54 which is an identification number for communication in the application.
  • an application performs multiple communications, it has multiple sets of communication ID, execution requirements 53, communication specifications 58, and communication requirements 64. Details of execution requirements 53, communication specifications 58, and communication requirements 64 are the same as those in FIG. 6, and will be explained together with FIG. 6.
  • Application requirement table 50 holds an application column 51 holding the ID of an application, a deployed flag 52 indicating that the application has been deployed to any ECU, execution requirements 53 holding requirements related to ECU internal resources (computational resources), communication specifications 58 holding specifications for communication between ECUs, and communication requirements 64 holding requirements related to communication resources between ECUs.
  • Execution requirements 53 include a computational resource column 55, a storage resource column 56, and a spec column 57.
  • communication specifications 58 include, as application requirements related to communication between ECUs, a communication direction column 59 indicating whether the application is sending or receiving, a communication partner column 60 identifying the communication partner of the application, a communication cycle column 61, a packet size column 62, and application identification information 63 which is information for identifying the application from a communication packet.
  • application identification information include the CAN ID of a CAN, source and destination MAC addresses in Ethernet, source and destination IP addresses in IP (Internet Protocol), and source and destination port numbers in TCP (Transmission Control Protocol) or UDP (User Datagram Protocol).
  • the communication requirements 64 include a communication bandwidth column 65, a communication delay column 66, a jitter column 67, and a discard rate column 68. If a single application performs multiple communications, the application uses multiple rows to represent the multiple communications, as in application A3. Also, if an application does not perform communications, only the execution requirements can be set for the application, as in application A4.
  • FIG. 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 the in-vehicle network, a type column 72 indicating whether the type of 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.
  • a link column 71 representing each link connecting ECUs in the in-vehicle network
  • a type column 72 indicating whether the type of 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)
  • a connection information column 73 holding the IDs of the ECUs connected to the link.
  • Figure 8 shows an excerpt from a communication performance information table 80 held by the communication performance information holding unit 23.
  • the communication performance information table 80 has a link column 81, a communication direction 82, a total bandwidth column 83 indicating the total bandwidth of the link for each link and communication direction, a used bandwidth column 84 indicating the bandwidth used by existing applications, a delay time column 85 indicating the maximum delay time, a jitter column 86, a discard rate column 87, and a buffer usage column 88.
  • step S100 the application requirement table 50 is obtained from the application requirement storage unit 21.
  • step S101 the following processing is looped for each application registered in the application requirement table 50.
  • step S102 the placement flag of the target application is checked, and if the application has been placed (Yes), nothing is done and the process moves to the next application. If the application has not been placed (No), steps S103 and after are executed.
  • step S103 it is checked whether the execution requirements of the target application have been registered in the application requirement table 50.
  • step S108 the predefined ECU candidate list is sorted in descending order of total resources, and the ECU is set as a candidate ECU for placement of the application, and the process moves to the next application. If the application has been registered (Yes), the following processing is performed.
  • step S104 the ECU free resource information table 30 is obtained from the free resource information storage unit 20.
  • step S105 from among the ECUs in the ECU free resource information table 30, ECUs whose computational and memory resources are greater than the computational and memory resources in the execution requirements of the app and that satisfy the specifications required by the app are selected, thereby selecting ECUs that satisfy the execution requirements required by the app, and creating a list of candidate ECUs for placement.
  • step S106 the ECU candidate list is sorted in descending order of free resources to determine the candidate ECUs for placement of the app.
  • step S107 it is determined whether the loop for the app has ended, and if processing has been completed for all apps, this processing ends.
  • FIG. 10 shows the application placement ECU candidate list 90, which is the output of the application placement selection unit 24.
  • the application placement ECU candidate list 90 holds placement ECU candidates 92 for each application sequence 91.
  • the application placement ECU candidate list 90 becomes the input to the next communication path selection unit 25.
  • step S200 the application placement ECU candidate list 90 is obtained from the application placement selection unit 24.
  • step S201 the topology information table 70 of the in-vehicle network is obtained from the topology information storage unit 22.
  • step S202 it is confirmed whether the topology information of the in-vehicle network is included in the topology information table 70, and if not (No), default topology information defined in advance is used in step S204. If the topology information is included in step S202 (Yes), the topology information in the topology information table 70 is used in step S203.
  • step S206 communication partner information is obtained from the application requirement storage unit 21 for each communication data (packet) of the application.
  • communication partner information collectively refers to the data sender in received data and the data destination in transmitted data.
  • 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 be performed and the processing proceeds to the next application. If information about the communication partner is included in step S207 (Yes), the processing proceeds to step S208 and subsequent steps.
  • step S208 a loop is started for the placement ECU candidates 92 in the application placement ECU candidate list 90.
  • step S209 route candidates from the data transmission source to the data reception destination are obtained by a process defined separately. When the process of S209 is completed for all placement ECU candidates, the loop for the placement ECU candidates is ended in S210.
  • step S211 If processing has been completed for all apps in the app placement destination ECU candidate list 90, the loop ends in step S211, and processing by the communication path selection unit 25 ends.
  • FIG. 12 is a flowchart showing an example of detailed processing of step S209 in FIG. 11.
  • step S220 a loop is started for each communication belonging to the application.
  • step S221 a route from the source ECU to the destination ECU is searched for using a process defined separately.
  • step S222 if the destination ECU is reached, the searched route is added to a route candidate list.
  • step S223 When processing has been completed for all communication data, the loop is ended in step S223, and this process is terminated.
  • FIG. 13 is a flowchart showing an example of detailed processing of step S221 in FIG. 12.
  • 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 is 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 for from the source ECU to the destination ECU, and a state 103 indicating the state of the communication path candidates 102.
  • step S230 the variable "phase" is set to 0, the source ECU is selected with a status of incomplete, and added to the first entry in the search list.
  • step S231 the phase is incremented by 1.
  • step S232 from among the communication path candidates 102 whose status is incomplete in the search list of the previous phase, ECUs that are directly connected in the topology to the ECU at the end of the path candidates are 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.
  • step S233 a loop is started for the search list 100 of the current phase created as described above.
  • step S234 the status of the communication path candidate 102 is checked.
  • the communication path status 103 is set to "destination reached" in step S235, and is added to the route candidate list, which is the output of the communication path selection unit 25, in step S236.
  • step S234b the end of the communication path candidate 102 is a searched ECU in step S234 (S234b), that is, if the communication path candidate includes multiple identical ECUs
  • the communication path candidate status 103 is set to "searched and reached" in step S237.
  • step S234 S234c
  • the communication path candidate status 103 is set to incomplete in step S238. Then, if processing has been completed up to the end of the search list of the current phase, the loop ends in step S239.
  • 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.
  • Figure 14 shows an example of the results of executing the process of Figure 13 on a network of zone architecture. For those whose status was incomplete in the previous phase, in the current phase, a list of communication path candidates is created by adding the next reachable ECU. Then, in phase 5, the status becomes destination reached (ECU C shown in underline) or searched and reached (ECU A shown in italics), and the search is completed.
  • FIG. 15 shows the application communication path candidate list 110, which is output from the communication path selection unit 25 and input to the performance verification unit 26.
  • the application communication path candidate list 110 holds communication path candidates 112 for an application sequence 111.
  • FIG 16 is a flowchart showing the operation of the performance verification unit 26.
  • step S300 the communication route candidate list 110 for the application is received from the communication route selection unit 25.
  • step S301 a loop is performed for the application listed in the communication route candidate list 110.
  • step S302 communication requirement information for the application is obtained from the application requirement storage unit 21 using a procedure defined separately.
  • 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.
  • step S304 a loop is performed for the route candidates for the application listed in the communication route candidate list 110.
  • step S305 the communication performance of the application when using the selected route is evaluated from the communication performance information of the route candidate and the communication requirements of the application using a procedure defined separately.
  • the evaluation result is determined in step S306, and if the communication requirements of the application cannot be met (No), the loop for the route candidate list is continued. 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.
  • 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 to have failed in step S308. Finally, these processes are executed in step S309 until the loop for each application ends.
  • FIG. 17 is a flowchart showing an example of detailed processing of step S302 in FIG. 16. After this processing, the processing is related to a specific application.
  • step S320 communication requirements are obtained from the application requirement storage unit 21 for each communication data of the application. Note that communication requirements are not obtained for applications that do not communicate.
  • 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), in step S323, predefined default communication requirements are used.
  • FIG. 18 is a flowchart showing an example of detailed processing of step S303 in FIG. 16.
  • step S330 communication performance information for each link on the in-vehicle network is obtained from the communication performance information storage unit 23.
  • step S331 a loop is started for each link on the in-vehicle network.
  • step S332 it is checked 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 in step S332 (No), in step S335, it is assumed that no communication is taking place on that link. Once processing has been completed for all links, the loop ends in step S334.
  • FIG 19 is a flowchart showing an example of detailed processing of step S305 in Figure 16.
  • 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. Since the four values can be calculated independently, the following steps are allowed to be executed either consecutively or in parallel.
  • step S340 a loop is started for each link constituting a route candidate. Steps S341 to S344 can be executed independently.
  • the communication bandwidth of the application is added to the bandwidth used on the link to calculate the communication bandwidth when the application is added.
  • the delay when the application is added is calculated by adding the packet length of the application to the delay on the link.
  • step S343 since the jitter is defined by the maximum packet length transmitted on the link, the jitter on the link is compared with the packet length of the application, and if the packet length of the application is greater than the jitter on the link, the jitter is updated to the packet length of the application.
  • step S344 because the packet loss rate occurs due to overflow of the transmission buffer on the link, the buffer usage on the link plus the packet length of the application is set as SUM, and if SUM is greater than the buffer size, the packet loss rate is calculated using the formula (SUM - buffer size) / SUM.
  • step S345 the loop is terminated for each link that constitutes the route candidate.
  • FIG. 20 shows the 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 the communication path 122 selected by the performance verification unit 26 for each application sequence 121.
  • 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.
  • step S401 the identification information of the applications included in the obtained application list is obtained from the application requirement storage unit 21.
  • step S402 the communication path information is reconstructed, and a communication path setting table 130 is generated in which, for each ECU, the identification information of the application through which the communication data passes corresponds to 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.
  • step S403 the process of step S404 is looped for each ECU in the communication path setting table 130.
  • step S404 the application identification information and the next destination ECU are set for the ECU.
  • step S405 the loop for the ECU in the communication path setting table 130 is ended.
  • the applications included in the application list are placed in the placement destination ECU.
  • the destination ECU is the ECU that is at the beginning of the transmitted data or the end of the received data on the application's communication path.
  • FIG. 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 the next destination ECU 133. Note that for data received by an application in the ECU where the application is located, the destination is represented as the CPU.
  • the above operations allow the in-vehicle network system to place apps in the ECU when a new app is added via OTA, taking into account the computational and storage resources within the ECU and the communication resources between ECUs. App placement can also be performed in a similar manner when updating an existing app via OTA.
  • the system in a network system in which an application is placed on one of a plurality of computing devices 3, 9 present on a network so as to satisfy an execution requirement 53 of the application, the system includes an application requirement holding unit 21 which holds the execution requirement 53 and communication requirement 64 of the application, a free resource information holding unit 20 which holds free resource information of the plurality of computing devices 3, 9, an application placement selection unit 24 which selects a computing device capable of executing the application from the plurality of computing devices 3, 9 based on the execution requirement 53 and the free resource information, and creates an application placement destination computing device candidate list 90, a topology information holding unit 22 which holds topology information indicating a communication connection relationship of the plurality of computing devices 3, 9, and a network configuration information holding unit 23 which holds the network configuration information of the plurality of computing devices 3, 9.
  • the communication path selection unit 25 which selects a communication path of the application when the application is placed on each computing device in the application placement destination computing device candidate list 90 based on the topology information, and creates a communication path candidate list 110; a performance verification unit 26 which verifies whether or not the communication requirement 64 is satisfied on each communication path in the communication path candidate list 110 based on the communication performance information and the communication requirement 64; and a setting application unit 27 which deploys the application on a computing device corresponding to a communication path verified by the performance verification unit 26 to satisfy the communication requirement 64 among the computing devices in the application placement destination computing device candidate list 90.
  • the method in a network management method for placing an application on one of a plurality of computing devices 3, 9 present on a network so as to satisfy an execution requirement 53 of the application, the method includes an application requirement holding step for holding the execution requirement 53 and communication requirement 64 of the application, an available resource information holding step for holding available resource information of the plurality of computing devices 3, 9, an application placement selection step for selecting a computing device capable of executing the application from the plurality of computing devices 3, 9 based on the execution requirement 53 and the available resource information, and creating a candidate computing device list 90 for application placement, a topology information holding step for holding topology information indicating the communication connection relationship of the plurality of computing devices 3, 9, and
  • the method includes a communication performance information holding step for holding communication performance information of each link of the network, a communication path selection step for selecting a communication path of the application when the application is placed on each computing device in the application placement destination computing device candidate list 90 based on the topology information to create a communication path candidate list 110, a performance verification step for verifying whether or not the communication requirement
  • the execution performance and communication performance of the app can be ensured by taking into consideration the computing resources of each computing device 3, 9 and the communication resources between the computing devices, making it possible to operate the app stably.
  • 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. This makes it possible to define the communication requirements 64 and communication performance information of the application.
  • the performance verification unit 26 in this embodiment verifies whether or not the communication requirements 64 are satisfied for each communication path in the communication path candidate list 110 by performing a numerical calculation based on the communication performance information and the communication requirements 64. This makes it possible to easily verify whether or not the communication requirements 64 are satisfied for each communication path in the communication path candidate list 110.
  • 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.
  • the metadata 43 that is input to the network together with the app when the app 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.
  • 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
  • communication requirements 64 including one or more of communication bandwidth, communication delay, communication jitter, and packet loss rate.
  • the network in this embodiment is an in-vehicle network mounted on a vehicle
  • the multiple computing devices 3, 9 are multiple in-vehicle electronic control devices 3, 9 mounted on the vehicle. This makes it possible to stably operate a newly deployed app on the in-vehicle network.
  • the in-vehicle device in this embodiment also includes the network system. This allows the newly installed app to run stably on the in-vehicle device.
  • the communication requirements 64 in this embodiment include items related to sensor data output from the sensors 4 mounted on the vehicle, control data for controlling the vehicle, and intermediate data obtained during the calculation to derive the control data from the sensor data. This makes it possible to define the communication requirements 64 according to the required performance of the vehicle-mounted device.
  • 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.
  • Figure 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.
  • Figure 23(a) is a configuration diagram when a simulation is performed inside the vehicle.
  • the performance verification unit 26 has a simulation unit 28 inside, which is used to perform performance verification by simulation.
  • Figure 23(b) is a configuration diagram when a simulation is performed outside the vehicle.
  • outside the vehicle means a computing resource other than the vehicle itself, such as the cloud, Multi-access Edge Computing (MEC), a roadside unit, or another vehicle.
  • the performance verification unit 26 communicates with the simulation unit 28 installed outside the vehicle by wireless communication, etc., sends the 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.
  • MEC Multi-access Edge Computing
  • FIG. 24 is a flow chart showing the operation of step S305 in FIG. 16, among the operations of the performance verification unit 26 in the second embodiment.
  • step S500 a simulation setting is created.
  • step S501 the simulation unit 28 is operated to execute a simulation.
  • step S502 a performance evaluation result is obtained for each section (link) of the route candidate from the simulation result.
  • the performance evaluation result includes the communication bandwidth, delay, jitter, packet discard rate, etc.
  • the invention of this embodiment enables more accurate performance evaluation, making it possible to increase the number of stored apps and improve the stability of app operation.
  • the network system performance verification unit 26 in this embodiment verifies whether or not the communication requirements 64 are satisfied by each communication path in the communication path candidate list 110 by performing a simulation based on the communication performance information and the communication requirements 64 .
  • 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. Therefore, in the third embodiment, an in-vehicle network system that can follow such topology changes is shown.
  • FIG. 25 is a functional block diagram of an in-vehicle network system in the third embodiment. Compared to FIG. 3, a topology change monitoring unit 29 has been added.
  • 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.
  • the status of the in-vehicle network means whether or not the links on the in-vehicle network are in a state in which communication is possible normally. If the state is normal, no action is taken. If an abnormality is detected, the information on the link is deleted from the topology information table 70 of the topology information storage unit 22 or marked as being in an abnormal state, and the link is not used. After that, the apps are relocated, including the apps that have already been deployed. In other words, the communication path selection unit 25, performance verification unit 26, and setting application unit 27 are operated to set up app deployment and communication paths that avoid the link that has become abnormal.
  • the network system in 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.
  • the fourth embodiment therefore shows a device that places apps while taking into account the priority between apps.
  • FIG. 26 shows the application requirement table 50 held by the application requirement holding unit 21 in the fourth embodiment.
  • the difference from the first to third embodiments is that a priority column 69 is added to the communication specifications 58.
  • priority is set in eight levels from 0 to 7, with 0 being the lowest priority and 7 being the highest priority.
  • execution requirements 53 and communication requirements 64 are the same as those in the first and third embodiments, so descriptions of the individual columns are omitted.
  • FIG. 27 is a flowchart showing the operation of the application placement selection unit 24 in the fourth embodiment. Processes similar to those in the flowchart of embodiment 1 (FIG. 9) are given the same numbers. The only difference from embodiments 1 to 3 is that the loop process of step S101 is changed to step S600. In step S600, a loop related to applications is performed in descending order of priority in the application requirement table 50 in this embodiment. As a result, the ECU placement and communication path are determined earlier for applications with higher priority.
  • the application requirement holding unit 21 in this embodiment holds a priority for each application, and the application placement selection unit 24 creates the application placement destination computing device candidate list 90 in descending order of priority of the applications.
  • 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, the fifth embodiment shows a configuration that allows the specification of communication requirements that must be satisfied for each application.
  • FIG. 28 shows the application requirement table 50 held by the application requirement holding unit 21 in the fifth embodiment.
  • the difference from the first to fourth embodiments is that priority columns 69a to 69d for each item of the communication requirement have been added.
  • priority is set on eight levels from 0 to 7, with 0 being the lowest priority and 7 being the highest priority. Using the priority for each item of the communication requirement, applications can be arranged to satisfy communication requirements that should be particularly satisfied for each application.
  • FIG. 29 is a flowchart showing the operation of the performance verification unit 26. Processes similar to those in the flowchart of the first embodiment 1 (FIG. 16) are given the same numbers. The differences from the first embodiment are that step S306 is changed to step S700, and that rather than immediately determining in step S308 that the app placement has failed after step S307 is completed, the lowest priority item is removed from the communication requirements in steps S700 and S701, and then app placement is attempted again.
  • step S700 the application communication performance evaluation is used to determine whether the application's communication performance satisfies the communication requirements with a priority level greater 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 on the route candidate list is terminated in step S307.
  • step S701 the priority of each communication requirement of the application is checked from application requirement table 50. If the priority of two or more communication requirements is greater than 0, it is determined that the communication requirement with the lowest priority greater than 0 can be excluded. If it is determined that it can be excluded in step S701 (Yes), in step S702 the priority of the communication requirement determined to be excludable in step S700 is overwritten with 0. If it is determined that it cannot be excluded in step S701 (No), the process proceeds to step S308 and the application deployment is deemed to have failed.
  • the application requirement storage unit 21 stores a priority for each item of the application's communication requirements 64, and if there are one or more items of 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.
  • the present invention is not limited to the above-mentioned embodiments and includes various modified examples.
  • the above-mentioned embodiments have been described in detail to explain the present invention in an easy-to-understand manner, and the present invention is not necessarily limited to those having all of the configurations described.
  • jitter column 68 ... discard rate column, 69, 69a to 69d ... priority column, 70 ... topology information table, 71 ... link column, 72 ... type column, 73 ... connection information column, 80 ... communication performance information table, 81 ... link column, 82 ... communication direction, 83 ... total bandwidth column, 84 ... bandwidth column, 85 ...
  • delay time column 86 ...jitter column, 87...discard rate column, 88...buffer usage column, 90...list of candidate ECUs for application placement (list of candidate computing devices for application placement), 91...application column, 92...destination ECU candidates, 100...search list, 101...phase, 102...candidate communication paths, 103...state, 110...candidate communication path list, 111...application column, 112...candidate communication paths, 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Small-Scale Networks (AREA)

Abstract

本発明は、ネットワーク上に存在する各演算装置の演算リソースおよび演算装置間の通信リソースを考慮したアプリケーションの配置が可能なネットワークシステムおよびネットワーク管理方法を提供することを目的とする。そのために、複数の演算装置３，９の通信接続関係を示すトポロジ情報に基づいて、アプリ配置先演算装置候補リスト９０内の各演算装置にアプリを配置した場合の前記アプリの通信経路を選択し、通信経路候補リスト１１０を作成する通信経路選択部２５と、通信性能情報と通信要件６４とに基づいて、通信経路候補リスト１１０内の各通信経路にて通信要件６４が満たされるか否かを検証する性能検証部２６と、アプリ配置先演算装置候補リスト９０内の演算装置のうち、性能検証部２６によって通信要件６４が満たされることが検証された通信経路に対応する演算装置に前記アプリを配置する設定適用部２７とを備える。

Description

ネットワークシステム、およびネットワーク管理方法
　本発明は、ネットワーク上に存在する複数の演算装置へのアプリケーションの配置を行うネットワークシステムおよびネットワーク管理方法に関する。
　自動運転や安全運転支援技術は日進月歩であり、今後も進化が続く。自動車メーカにおいてはこれらの技術進歩を新型車両へ適用するだけでなく、販売済み車両にも適用することを検討している。そのための技術にＯＴＡ（Over-the-Air）アップデート技術がある。
　ＯＴＡでは新規または更新された車載アプリケーション（以降、単にアプリと呼ぶ）を、クラウド等のサーバから無線ネットワークを介して車両へ配信する。車両側では配信されたアプリを車両システムに展開し適用・実行する。
　車両システムは複数の電子制御ユニット（ＥＣＵ：Electronic Control Unit）がネットワークにより接続された構成となっている。ここでＥＣＵはカメラ等のセンサ、エンジンやステアリング等を操作するアクチュエータ、および制御のための演算を実行する装置の総称として用いる。ＥＣＵでは車載ネットワークを介してデータを送受信し、アプリによりデータを演算することで車両制御のための情報を得る。データの送受信により車載ネットワークには負荷がかかるが、アプリの配置状況によって車載ネットワークの負荷状況は異なる。
　ここでＯＴＡにより新規アプリが追加された場合、車両システムは新規アプリを実行するＥＣＵを選択する必要がある。特許文献１にはアプリ追加時にアプリを実行するＥＣＵを選択する方法が開示されている。これは、アプリ取得部の取得した追加アプリをインストール可能なＥＣＵを複数備えた車載システムは、要求特定部、リソース特定部、および選択部を備える。要求特定部は、追加アプリの要求するリソースである要求リソースを特定する。リソース特定部は、各ＥＣＵの提供可能なリソースである提供リソースを特定する。選択部は、提供リソースが要求リソースを満たしているＥＣＵを追加アプリのインストール先として選択する。
特開２０２０－８６５２２号公報
　特許文献１に記載の発明ではＥＣＵの演算リソースに基づいてアプリ配置先のＥＣＵを選択することができるが、車載ネットワークの負荷状況などＥＣＵ間の通信リソースを考慮したアプリ配置を行うことができない。
　本発明は、上記課題に鑑みてなされたものであり、その目的は、ネットワーク上に存在する各演算装置の演算リソースおよび演算装置間の通信リソースを考慮したアプリケーションの配置が可能なネットワークシステムおよびネットワーク管理方法を提供することにある。
　上記目的を達成するために、本発明は、アプリの実行要件を満たすように、ネットワーク上に存在する複数の演算装置のいずれかへ前記アプリを配置するネットワークシステムにおいて、前記アプリの実行要件および通信要件を保持するアプリ要件保持部と、前記複数の演算装置の空きリソース情報を保持する空きリソース情報保持部と、前記実行要件と前記空きリソース情報とに基づいて、前記複数の演算装置の中から前記アプリを実行可能な演算装置を選択し、アプリ配置先演算装置候補リストを作成するアプリ配置選択部と、前記複数の演算装置の通信接続関係を示すトポロジ情報を保持するトポロジ情報保持部と、前記ネットワークの各リンクの通信性能情報を保持する通信性能情報保持部と、前記トポロジ情報に基づいて、前記アプリ配置先演算装置候補リスト内の各演算装置に前記アプリを配置した場合の前記アプリの通信経路を選択して通信経路候補リストを作成する通信経路選択部と、前記通信性能情報と前記通信要件とに基づいて、前記通信経路候補リスト内の各通信経路にて前記通信要件が満たされるか否かを検証する性能検証部と、前記アプリ配置先演算装置候補リスト内の演算装置のうち、前記性能検証部によって前記通信要件が満たされることが検証された通信経路に対応する演算装置に前記アプリを配置する設定適用部とを備えるものとする。
　また、本発明は、アプリの実行要件を満たすように、ネットワーク上に存在する複数の演算装置のいずれかへ前記アプリを配置するネットワーク管理方法において、前記アプリの実行要件および通信要件を保持するアプリ要件保持ステップと、前記複数の演算装置の空きリソース情報を保持する空きリソース情報保持ステップと、前記実行要件と前記空きリソース情報とに基づいて、前記複数の演算装置の中から前記アプリを実行可能な演算装置を選択し、アプリ配置先演算装置候補リストを作成するアプリ配置選択ステップと、前記複数の演算装置の通信接続関係を示すトポロジ情報を保持するトポロジ情報保持ステップと、前記ネットワークの各リンクの通信性能情報を保持する通信性能情報保持ステップと、前記トポロジ情報に基づいて、前記アプリ配置先演算装置候補リスト内の各演算装置に前記アプリを配置した場合の前記アプリの通信経路を選択して通信経路候補リストを作成する通信経路選択ステップと、前記通信性能情報と前記通信要件とに基づいて、前記通信経路候補リスト内の各通信経路にて前記通信要件が満たされるか否かを検証する性能検証ステップと、前記アプリ配置先演算装置候補リスト内の演算装置のうち、前記性能検証ステップによって前記通信要件が満たされることが検証された通信経路に対応する演算装置に前記アプリを配置する設定適用ステップとを備えるものとする。
　本発明によれば、ネットワーク上に存在する複数の演算装置のいずれかへアプリを配置する際に、各演算装置の演算リソースおよび演算装置間の通信リソースを考慮することにより、アプリの実行性能および通信性能を確保することができるため、アプリを安定的に動作させることが可能となる。
本発明による車載ネットワークシステムを搭載する車載装置の電気電子アーキテクチャの図 ドメインＥＣＵ、ゾーンＥＣＵ、セントラルＥＣＵ、およびゲートウェイのハードウェア構成図 本発明による車載ネットワークシステムの機能ブロック図 空きリソース情報保持部の保持するＥＣＵ内空きリソース情報テーブル アプリ要件保持部がＴＣＵ経由で受信するＯＴＡデータの構成例 アプリ要件保持部の保持するアプリ要件テーブル トポロジ情報保持部の保持するトポロジ情報テーブル 通信性能情報保持部の保持する通信性能情報テーブルの抜粋 アプリ配置選択部の動作を表すフローチャート アプリ配置選択部の出力であるアプリ配置先ＥＣＵ候補リスト 通信経路選択部の動作を表すフローチャート 図１１中ステップＳ２０９の詳細な処理の一例を示すフローチャート 図１２中ステップＳ２２１の詳細な処理の一例を示すフローチャート 図１３の処理をゾーンアーキテクチャのネットワークに対して実行した結果の例 通信経路選択部から出力され性能検証部へ入力される、アプリの通信経路候補リスト 性能検証部の動作を表すフローチャート 図１６中ステップＳ３０２の詳細な処理の一例を表すフローチャート 図１６中ステップＳ３０３の詳細な処理の一例を表すフローチャート 図１６中ステップＳ３０５の詳細な処理の一例を表すフローチャート 性能検証部から出力され設定適用部へ入力される通信経路リスト 設定適用部の動作を表すフローチャート 設定適用部で使用する通信経路設定テーブルの構成例 第２の実施例における性能検証部の構成図 第２の実施例における性能検証部の動作のうち、図１６中ステップＳ３０５の動作を示すフローチャート 第３の実施例における車載ネットワークシステムの機能ブロック図 第４の実施例におけるアプリ要件保持部の保持するアプリ要件テーブル 第４の実施例におけるアプリ要件保持部の保持するアプリ要件テーブル 第５の実施例におけるアプリ要件保持部の保持するアプリ要件テーブル 性能検証部の動作を表すフローチャート
　以下、本発明の実施形態について図面を用いて説明する。なお、各図中、同等の要素には同一の符号を付し、重複した説明は適宜省略する。
　以下、図を用いて車載ネットワークシステムの第１の実施例を説明する。
　図１は本発明による車載ネットワークシステムを搭載する車載装置の電気電子アーキテクチャを示す図である。ここでは代表的な電気電子アーキテクチャとして２つの構成を取り上げるが、本発明の適用先はこれに限定されるものではない。
　図１（ａ）はドメイン別アーキテクチャと呼ばれるアーキテクチャの論理的構成を示す図である。これは車両１内部のＥＣＵ（車載電子制御装置）をドメインと呼ばれる機能別区分に分類し、同一ドメインに属するＥＣＵを体系的に接続する方式である。ドメイン毎にそのドメインを統括するドメインＥＣＵ３が置かれる。またドメイン間で通信を行うために、ドメインＥＣＵ３はゲートウェイ２を介して相互に接続される。ドメインには例えば安全運転支援を司るＡＤＡＳ（Advanced Driver Assistance System）ドメイン、車両の前後方向および左右方向の運動を制御するＰＴ／ＣＨ（Power Train/Chassis）ドメイン、パワーウィンドウ等の電装機器を制御するＢＯＤＹドメイン、ナビゲーションやオーディオを制御するＩｎｆｏｔａｉｎｍｅｎｔドメインなどがある。それぞれのドメインに対してＡＤＡＳ　ＥＣＵ３ａ、ＰＴ／ＣＨ　ＥＣＵ３ｂ、ＢＯＤＹ　ＥＣＵ３ｃ、Ｉｎｆｏｔａｉｎｍｅｎｔ　ＥＣＵ３ｄ（以下これらをまとめて３とも表記する）が設置される。ドメインＥＣＵ３にはセンサ４ａ～４ｄ（以下まとめて４とも表記する）やアクチュエータ５ａ～５ｄ（以下まとめて５とも表記する）などのＥＣＵ４，５がＣＡＮ（Controller Area Network）、ＬＩＮ（Local Interconnect Network）等、ドメイン毎に適したリンク６ａ～６ｄ（以下まとめて６とも表記する）により接続される。単一のリンク６に複数のＥＣＵ４，５が接続される場合がある。またゲートウェイ２には、車外のサーバやクラウド等と無線ネットワークを介して通信を行うＴＣＵ（Telematics Control Unit）７が接続される。
　ドメインＥＣＵはどのドメインごとに性能や機能要件が異なることがある。例えばＡＤＡＳ　ＥＣＵやＩｎｆｏｔａｉｎｍｅｎｔ　ＥＣＵはビデオ等の大容量データを扱うため処理性能の高いハードウェアが用いられる。一方ＰＴ／ＣＨ　ＥＣＵは安全に直結するため信頼性の高いハードウェアが用いられる。
　図１（ｂ）はゾーンアーキテクチャと呼ばれるアーキテクチャの物理的構成を示す図である。これはＥＣＵ４，５を車両１内部の空間的な位置によって分類し、その位置を統括するゾーンＥＣＵ９ａ～９ｄ（以下まとめて９とも表記する）へ接続する方式である。１つ以上のゾーンＥＣＵ９、ゾーンＥＣＵ９に接続し複数ドメインにまたがる複数のアプリを実行するセントラルＥＣＵ８、ゾーンＥＣＵ９に接続するセンサ４およびアクチュエータ５などから構成される。このゾーンＥＣＵ９はその名の通り、車両内での前後左右等の位置（ゾーン）に対応して配置されており、その設置位置に近接するセンサ４またはアクチュエータ５、あるいはその両方と接続される。またゾーンＥＣＵ９はドメイン間で共通通信方式を用いた共有リンク１０により他のゾーンＥＣＵ９と接続される。共通通信方式はＥｔｈｅｒｎｅｔ（登録商標）によるスイッチングネットワークが想定される。ＴＣＵ７はセントラルＥＣＵ８または任意のゾーンＥＣＵ９に接続されるが、図１（ｂ）ではセントラルＥＣＵ８に接続する例を示している。
　図２はドメインＥＣＵ３、ゾーンＥＣＵ９、セントラルＥＣＵ８、およびゲートウェイ２のハードウェア構成である。図２中の太線はゾーンアーキテクチャまたはドメインアーキテクチャにおける通信装置２間の接続方式である共通通信方式を表しており、細線はその他の通信方式を表している。
　図２（ａ）はドメインＥＣＵ３のハードウェア構成である。ドメインＥＣＵ３は内部に、センサ４およびアクチュエータ５あるいはゲートウェイ２から受信した情報を処理するためのＣＰＵ（Central Processing Unit）１１、およびＣＰＵ１１で演算を行うために用いるデータを保持するメモリ１２を持ち、ＣＰＵ１１からはゲートウェイ２へ接続するためのリンクおよびセンサ４やアクチュエータ５へ接続するためのリンクが出ている。
　図２（ｂ）はゾーンＥＣＵ９のハードウェア構成である。ゾーンＥＣＵ９は他のゾーンＥＣＵ９へ接続するため、あるいはセンサ４やアクチュエータ５へ接続するための共有リンク１０を収容するネットワークスイッチ１３を備える。またゾーンＥＣＵ９は、センサ４およびアクチュエータ５、あるいは共有リンク１０から受信した情報を処理するためのＣＰＵ１１を備え、ネットワークスイッチ１３と接続される。またＣＰＵ１１はメモリ１２とも接続される。センサ４およびアクチュエータ５が共通通信方式に対応している場合はネットワークスイッチ１３へ直接接続してよい。センサ４およびアクチュエータ５が共通通信方式に対応していない場合はＣＰＵ１１へと接続した上で共通通信方式へ変換することができる。
　図２（ｃ）はドメイン別アーキテクチャにおけるゲートウェイ２のハードウェア構成である。ゲートウェイ２は、ＣＰＵ１１、メモリ１２、およびドメインＥＣＵ３へ接続するためのネットワークスイッチ１３を備える。
　図２（ｄ）はゾーン別アーキテクチャにおけるセントラルＥＣＵ８のハードウェア構成である。セントラルＥＣＵ８は、ゲートウェイ２と概ね同様の構成となっており、ＣＰＵ１１、メモリ１２、およびゾーンＥＣＵ９へ接続するためのネットワークスイッチ１３を備える。
　図３は本発明による車載ネットワークシステムの機能ブロック図である。なお機能ブロックは図１に表示のない独立した装置として実装してもよいし、ソフトウェアとして実装し図１中いずれかのＥＣＵにて実行してもよい。ソフトウェアとして実装する場合、図１中の任意のＥＣＵにて機能を損なうことなく実行可能であるが、典型的には車載ネットワーク全体を管理するために、ドメイン別アーキテクチャであればゲートウェイに、ゾーンアーキテクチャであればセントラルＥＣＵに実装されると想定される。
　本発明は空きリソース情報保持部２０、アプリ要件保持部２１、トポロジ情報保持部２２、通信性能情報保持部２３、アプリ配置選択部２４、通信経路選択部２５、性能検証部２６、設定適用部２７の機能ブロックからなる。
　空きリソース情報保持部２０は各ＥＣＵ内部のリソース状況、例えばＣＰＵ空き容量やメモリ空き容量に関する情報を定期的に収集して保持する。
　アプリ要件保持部２１は車内の各ＥＣＵで実行するアプリに関する実行要件を保持する。アプリ要件保持部２１には車両の出荷時においてプリインストールされるアプリの要件は出荷時に格納されているものとし、ＯＴＡにより追加されるアプリの要件はＯＴＡデータとともにＴＣＵ７を介して受信するものとする。要件の具体例については図６を用いて説明する。
　トポロジ情報保持部２２では車載ネットワークの接続関係を表すトポロジ情報を保持する。
　通信性能情報保持部２３では車載ネットワーク内の各リンクごとに、現在行われている通信の性能情報、つまりＥＣＵ間の通信リソース状況を保持する。
　アプリ配置選択部２４は空きリソース情報保持部２０から取得する各ＥＣＵ内部のリソース状況およびアプリ要件保持部２１から取得するアプリのＥＣＵ内部リソース（演算リソース）に関する実行要件情報をもとに、アプリの配置先ＥＣＵ候補を決定する。
　通信経路選択部２５はアプリ配置選択部２４の決定したアプリの配置先ＥＣＵ候補、アプリ要件保持部２１から取得したアプリの通信先情報、およびトポロジ情報保持部２２から取得する車載ネットワークのトポロジ情報をもとに、アプリが行う通信の通信経路候補を決定する。
　性能検証部２６は通信経路選択部２５の決定したアプリの通信経路候補に対し、アプリ要件保持部２１から取得するアプリの通信要件および通信性能情報保持部２３から取得した通信の性能情報をもとに、通信経路候補を選択した場合のアプリの通信性能を検証する。検証の結果アプリが通信性能を満たす経路候補より、実際に使用する通信経路を１つ選択する。
　設定適用部２７では性能検証部２６が決定した通信経路を車載ネットワークへ適用する。そのためにアプリ要件保持部２１からアプリのデータ送受信先アドレス等を取得し、経路上のＥＣＵ内部にあるネットワークスイッチ１３に転送ルールを設定する。
　以降、各機能ブロックの詳細について説明する。
　図４は空きリソース情報保持部２０の保持するＥＣＵ内空きリソース情報テーブル３０である。ＥＣＵ内空きリソース情報テーブル３０はＥＣＵ列３１に対し、計算リソース列３２、記憶リソース列３３、およびスペック列３４の情報を保持する。スペックは高性能、高信頼等のＥＣＵが持つ特性を意味する。
　図５はアプリ要件保持部２１がＴＣＵ７経由で受信するＯＴＡデータ４０の構成例である。ＯＴＡデータ４０はアプリのＩＤ、バージョン情報などを含むヘッダ４１、バイナリ形式等でアプリ本体のコードを格納したアプリデータ４２、および本発明にて参照するアプリに関するメタデータ４３を含む。メタデータ４３には当該アプリにおける通信の識別番号である通信ＩＤ５４に対応して、図６に記載するアプリ要件テーブル５０と同様の実行要件５３、通信仕様５８および通信要件６４を保持する。アプリが複数の通信を行う場合は通信ＩＤ、実行要件５３、通信仕様５８および通信要件６４の組を複数持つ。実行要件５３、通信仕様５８および通信要件６４の詳細は図６と同様であるので、図６とともに説明する。
　図６はアプリ要件保持部２１の保持するアプリ要件テーブル５０である。アプリ要件テーブル５０はアプリのＩＤを保持するアプリ列５１に対し、アプリがいずれかのＥＣＵに配置済みであることを示す配置済みフラグ５２、ＥＣＵ内部リソース（演算リソース）に関する要件を保持する実行要件５３、ＥＣＵ間通信の仕様を保持する通信仕様５８およびＥＣＵ間の通信リソースに関する要件を保持する通信要件６４を保持する。実行要件５３は計算リソース列５５、記憶リソース列５６、スペック列５７を含む。また通信仕様５８はＥＣＵ間通信に関するアプリの要件として、アプリから見た場合の送信または受信の別を表す通信方向列５９、アプリの通信相手を特定する通信相手列６０、通信周期列６１、パケットサイズ列６２、および通信パケットからアプリを特定するための情報であるアプリ識別情報６３を含む。アプリ識別情報は例えばＣＡＮのＣＡＮ　ＩＤ、イーサネットにおける送信元・宛先ＭＡＣアドレス、ＩＰ（Internet Protocol）における送信元・宛先ＩＰアドレス、ＴＣＰ（Transmission Control Protocol）またはＵＤＰ（User Datagram Protocol）における送信元・宛先ポート番号などがある。通信要件６４は通信帯域列６５、通信遅延列６６、ジッタ列６７、および廃棄率列６８を含む。なお単一のアプリが複数の通信を行う場合、当該アプリはアプリＡ３のように複数の行を用いて複数の通信を表現する。また、アプリが通信を行わない場合、当該アプリはアプリＡ４のように実行要件のみ設定することができる。
　図７はトポロジ情報保持部２２の保持するトポロジ情報テーブル７０である。トポロジ情報テーブル７０は車載ネットワーク内のＥＣＵ間を接続する各リンクを表すリンク列７１に対して、当該リンクの種別がバス型（複数のＥＣＵが一つの共通の通信路に接続する形態）であるかメッシュ型（１つのＥＣＵが他のＥＣＵと一対一で接続する形態）であるかを記載する種別列７２および当該リンクに接続されるＥＣＵのＩＤを保持する接続情報列７３を持つ。
　図８は通信性能情報保持部２３の保持する通信性能情報テーブル８０の一部を抜粋したものである。通信性能情報テーブル８０はリンク列８１に対し、通信方向８２を持ち、リンクおよび当該通信方向ごとにリンクの総帯域を表す総帯域列８３、既存のアプリによって使用されている帯域を表す使用済み帯域列８４、最大の遅延時間を表す遅延時間列８５、ジッタ列８６、廃棄率列８７、およびバッファ使用量列８８を持つ。
　図９はアプリ配置選択部２４の動作を表すフローチャートである。本フローチャートはＯＴＡによるアプリの追加によるアプリ要件テーブル５０の更新を契機として開始される。まずステップＳ１００にてアプリ要件保持部２１からアプリ要件テーブル５０を取得する。続いてＳ１０１にて、アプリ要件テーブル５０に登録されているアプリ毎に以下の処理をループする。ステップＳ１０２にて対象アプリの配置済みフラグをしらべ、配置済みである場合（Ｙｅｓ）には何も行わず次のアプリの処理へ移る。配置済みでない場合（Ｎｏ）は、ステップＳ１０３以降を実行する。ステップＳ１０３では対象アプリの実行要件がアプリ要件テーブル５０に登録済みであるかを調べる。登録済みでない場合（Ｎｏ）、ステップＳ１０８にて事前に定義されたＥＣＵ候補リストを総リソースの大きい順にソートしアプリの配置先ＥＣＵ候補として、次のアプリの処理へ移る。登録済みの場合（Ｙｅｓ）、以下の処理を行う。ステップＳ１０４にて空きリソース情報保持部２０からＥＣＵ内空きリソース情報テーブル３０を取得する。続くステップＳ１０５にて、ＥＣＵ内空きリソース情報テーブル３０内のＥＣＵのうち、計算リソースおよび記憶リソースがアプリの実行要件にある計算リソースおよび記憶リソースより大きく、かつ、アプリの要求するスペックを満足するＥＣＵを選択することにより、アプリの要求する実行要件を満たすＥＣＵを選択し、配置先ＥＣＵ候補リストを作成する。そしてステップＳ１０６にてＥＣＵ候補リストを空きリソースの大きい順にソートしてアプリの配置先ＥＣＵ候補とする。ステップＳ１０７にてアプリに対するループの終了判定を行い、全アプリに対して処理が完了した場合は本処理を終了する。
　図１０はアプリ配置選択部２４の出力であるアプリ配置先ＥＣＵ候補リスト９０である。アプリ配置先ＥＣＵ候補リスト９０はアプリ列９１ごとに配置先ＥＣＵ候補９２を保持する。アプリ配置先ＥＣＵ候補リスト９０は次の通信経路選択部２５の入力となる。
　図１１は通信経路選択部２５の動作を表すフローチャートである。本フローチャートはアプリ配置選択部２４からのアプリ配置先ＥＣＵ候補リスト９０の入力を契機として開始される。まずステップＳ２００にてアプリ配置選択部２４からのアプリ配置先ＥＣＵ候補リスト９０を取得する。ステップＳ２０１にてトポロジ情報保持部２２より車載ネットワークのトポロジ情報テーブル７０を取得する。ステップＳ２０２にてトポロジ情報テーブル７０に車載ネットワークのトポロジ情報が含まれているか確認し、含まれていない場合（Ｎｏ）はステップＳ２０４にて事前に定義されたデフォルトのトポロジ情報を使用する。ステップＳ２０２にてトポロジ情報が含まれる場合（Ｙｅｓ）は、ステップＳ２０３にてトポロジ情報テーブル７０のトポロジ情報を使用する。
続くステップＳ２０５ではアプリ配置先ＥＣＵ候補リスト９０のアプリ列９１にあるアプリ毎に以下のループ処理を行う。まずステップＳ２０６にてアプリ要件保持部２１からアプリの通信データ（パケット）ごとに、通信相手情報を取得する。ここで通信相手情報とは、受信データにおけるデータ送信元、ならびに送信データにおけるデータ宛先を総称していう。ステップＳ２０７では前記通信相手情報を調べ、通信相手に関する情報が含まれない場合（Ｎｏ）は通信が行われないものと判断して次のアプリに関する処理に移る。ステップＳ２０７で通信相手に関する情報が含まれる場合（Ｙｅｓ）、ステップＳ２０８以降に進む。
ステップＳ２０８ではアプリ配置先ＥＣＵ候補リスト９０の配置先ＥＣＵ候補９２に対するループを開始する。ステップＳ２０９では別途定義する処理によりデータの送信元から受信先までの経路候補を求める。すべての配置先ＥＣＵ候補に関してＳ２０９の処理が完了した場合、Ｓ２１０にて配置先ＥＣＵ候補に関するループを終了する。
　アプリ配置先ＥＣＵ候補リスト９０のすべてのアプリに関して処理が完了した場合、ステップＳ２１１にてループを終了し、通信経路選択部２５の処理を終了する。
　図１２は図１１中ステップＳ２０９の詳細な処理の一例を示すフローチャートである。まずステップＳ２２０にてアプリに属する通信ごとにループを開始する。続くステップＳ２２１では別途定義する処理にて送信元ＥＣＵから宛先ＥＣＵまでの経路を探索する。そしてステップＳ２２２では宛先ＥＣＵに到達した場合は探索した経路を経路候補リストへ追加する。すべての通信データに対して処理が完了した場合、ステップＳ２２３にてループを終了し、本処理を終了する。
　図１３は図１２中ステップＳ２２１の詳細な処理の一例を示すフローチャートである。ここでは幅優先探索にて送信元ＥＣＵから宛先ＥＣＵまでの経路を探索するが、深さ優先探索など他の探索アルゴリズムにて実施してもよい。また図１４は本探索処理で用いる探索リスト１００の例である。探索リスト１００は探索の段階を示すフェーズ１０１、送信元ＥＣＵから宛先ＥＣＵまでのすでに探索した経路候補を示す通信経路候補１０２、および通信経路候補１０２の状態を示す状態１０３を持つ。
　まずステップＳ２３０にて変数「フェーズ」を０に設定、状態を未完了として送信元ＥＣＵを選択し、探索リストの最初のエントリに追加する。続くステップＳ２３１ではフェーズを１だけ増加する。次いでステップＳ２３２では前フェーズの探索リストで状態が未完了である通信経路候補１０２のうち、経路候補の末尾にあるＥＣＵからトポロジ上で直結するＥＣＵを抽出の上、通信経路候補１０２の末尾に追加したものを、現フェーズの探索リスト１００に追加する。
　ステップＳ２３３では前記のようにして作成した現フェーズの探索リスト１００に対してループを開始する。ステップＳ２３４にて通信経路候補１０２の状態をチェックする。まず通信経路候補１０２の末尾が宛先ＥＣＵであった場合（Ｓ２３４ａ）はステップＳ２３５にて通信経路の状態１０３を「宛先到達」に設定し、ステップＳ２３６にて通信経路選択部２５の出力である経路候補リストへ追加する。次にステップＳ２３４にて通信経路候補１０２の末尾が探索済みＥＣＵであった場合（Ｓ２３４ｂ）、つまり通信経路候補に同一ＥＣＵが複数含まれる場合は、ステップＳ２３７にて通信経路候補の状態１０３を「探索済み到達」に設定する。ステップＳ２３４にてそれ以外であった場合（Ｓ２３４ｃ）、ステップＳ２３８にて通信経路候補の状態１０３を未完了に設定する。そして現フェーズの探索リスト末尾まで処理が完了した場合、ステップＳ２３９にてループを終了する。
　最後にステップＳ２４０にて現フェーズの探索リストに状態が未完了の通信経路候補１０２があるか否かを確認し、状態が未完了の通信経路候補１０２がある場合はステップＳ２３１に戻って処理を継続する。状態が未完了の通信経路候補１０２がない場合、つまり車載ネットワークのトポロジに対する探索を完了した場合は、本処理を終了する。
　図１４は図１３の処理をゾーンアーキテクチャのネットワークに対して実行した結果の例である。前フェーズで状態が未完了となったものに対し、現フェーズでは次に到達可能なＥＣＵを追加した通信経路候補をリスト化する。そしてフェーズ５にて状態が宛先到達の場合（下線で示すＥＣＵ　Ｃの箇所）または探索済み到達（イタリック体で示すＥＣＵ　Ａの箇所）となり、探索を完了する。
　図１５は通信経路選択部２５から出力され性能検証部２６へ入力される、アプリの通信経路候補リスト１１０である。アプリの通信経路候補リスト１１０はアプリ列１１１に対する通信経路候補１１２を保持する。
　図１６は性能検証部２６の動作を表すフローチャートである。まずステップＳ３００にて、通信経路選択部２５からアプリの通信経路候補リスト１１０を受信する。次にステップＳ３０１にて通信経路候補リスト１１０に記載のアプリについてループする。次にステップＳ３０２では別途定義する手順にてアプリ要件保持部２１よりアプリの通信要件情報を取得する。次にステップＳ３０３では別途定義する手順にて通信性能情報保持部２３より車載ネットワーク上の各リンクにおける通信性能情報を取得する。次にステップＳ３０４にて通信経路候補リスト１１０に記載の当該アプリに対する経路候補についてループする。次にステップＳ３０５にて別途定義する手順により、経路候補の通信性能情報とアプリの通信要件から、選択経路使用時の当該アプリの通信性能を評価する。この評価結果をステップＳ３０６にて判定し、アプリの通信要件を満たせない場合（Ｎｏ）は経路候補リストに関するループを継続する。ステップＳ３０６にてアプリの通信要件を満たせる通信経路が存在した場合（Ｙｅｓ）、ステップＳ３１０にてアプリの配置成功とし、設定適用部２７へ通信経路情報を出力する。続いてステップＳ３１１にて空きリソース情報保持部お２０よび通信性能情報保持部２３の情報を更新する。アプリの通信要件を満たせる通信経路が存在せずステップＳ３０７にてループが終了した場合、ステップＳ３０８にてアプリ配置を失敗とする。最後にこれらの処理をステップＳ３０９にてアプリ毎のループが終了するまで実行する。
　図１７は図１６中ステップＳ３０２の詳細な処理の一例を表すフローチャートである。この処理次点で特定アプリに関する処理となっている。まずステップＳ３２０にてアプリ要件保持部２１より当該アプリの各通信データについて通信要件を取得する。なお通信を行わないアプリについては通信要件を取得しないものとする。次にステップＳ３２１にて取得した通信要件データに、通信帯域や遅延などアプリの通信要件が含まれるか否かを調べる。通信要件が含まれる場合（Ｙｅｓ）、ステップＳ３２２にてアプリ要件保持部２１より取得したアプリの通信要件を使用する。ステップＳ３２１にて通信要件が含まれない場合（Ｎｏ）、ステップＳ３２３にて事前に定義されたデフォルトの通信要件を使用する。
　図１８は図１６中ステップＳ３０３の詳細な処理の一例を表すフローチャートである。まずステップＳ３３０にて、通信性能情報保持部２３より車載ネットワーク上の各リンクにおける通信性能情報を取得する。次にステップＳ３３１にて車載ネットワーク上のリンクごとにループを開始する。ステップＳ３３２にてリンクごとの取得した通信性能情報に何かしらの通信性能情報が含まれるか否かを調べる。通信性能情報が含まれる場合（Ｙｅｓ）、ステップＳ３３３にて通信性能情報保持部２３より取得した通信性能情報を使用する。ステップＳ３３２にて通信性能情報が含まれない場合（Ｎｏ）、ステップＳ３３５にて当該リンク上では通信が行われていないものと仮定する。全リンクについて処理を完了すれば、ステップＳ３３４にてループを終了する。
　図１９は図１６中ステップＳ３０５の詳細な処理の一例を表すフローチャートである。ここではアプリごとにリンク上の通信性能として、通信帯域、遅延、ジッタ、パケット廃棄率の４つの値を数値計算により求める。前記４つの値は独立に計算可能であるため、以下のステップは連続でも並列でも実行することが許可される。まずステップＳ３４０で経路候補を構成する各リンクについてループを開始する。ステップＳ３４１からステップＳ３４４は独立に実行可能である。ステップＳ３４１ではリンク上の使用帯域にアプリの通信帯域を加算することにより、アプリを追加した場合の通信帯域を求める。ステップＳ３４２ではリンク上の遅延にアプリのパケット長を加算することにより、アプリを追加した場合の遅延を求める。ステップＳ３４３では、ジッタがリンク上に送信されるパケット長の最大値で規定されることより、リンク上のジッタとアプリのパケット長を比較し、リンク上のジッタよりもアプリのパケット長が大きい場合、ジッタをアプリのパケット長に更新する。ステップＳ３４４では、パケット廃棄率がリンク上の送信バッファあふれにより発生することより、リンク上のバッファ使用量にアプリのパケット長を加算した値をＳＵＭとし、ＳＵＭがバッファサイズよりも大きい場合、パケット廃棄率を（ＳＵＭ－バッファサイズ）／ＳＵＭの式により求める。ステップＳ３４５にて経路候補を構成する各リンクについてループを終了する。
　図２０は性能検証部２６から出力され設定適用部２７へ入力される通信経路リスト１２０である。通信経路リスト１２０はアプリ列１２１ごとに性能検証部２６によって選択された通信経路１２２を保持する。
　図２１は設定適用部２７の動作を表すフローチャートである。まずステップＳ４００にて、性能検証部２６より受信した通信経路リスト１２０から、含まれるアプリを抽出しアプリ一覧を取得する。次にステップＳ４０１にて前記取得したアプリ一覧に含まれるアプリについて、その識別情報をアプリ要件保持部２１より取得する。次にステップＳ４０２にて、通信経路情報を再構成し、ＥＣＵごとに、通信データが通過するアプリの識別情報と当該通信データの次の転送先ＥＣＵとを対応付けた通信経路設定テーブル１３０を生成する。通信経路設定テーブル１３０の構成例は図２２を用いて説明する。次にステップＳ４０３では、通信経路設定テーブル１３０のＥＣＵごとにステップＳ４０４の処理をループする。ステップＳ４０４では当該ＥＣＵに対し、アプリ識別情報と次の転送先ＥＣＵを設定する。ステップＳ４０５では通信経路設定テーブル１３０中のＥＣＵに関するループを終了する。最後にアプリ一覧に含まれるアプリについて、配置先ＥＣＵへ配置する。配置先ＥＣＵはアプリの通信経路において、送信データの先頭または受信データの末尾にあるＥＣＵである。
　図２２は設定適用部２７内部で使用する通信経路設定テーブル１３０の構成例である。通信経路設定テーブル１３０はＥＣＵ列１３１に対し、通信データが通過するアプリのアプリ識別情報１３２および次の転送先ＥＣＵ１３３を保持する。なおアプリの配置先ＥＣＵにおいてアプリが受信するデータは転送先をＣＰＵと表現する。
　以上の動作により、車載ネットワークシステムはＯＴＡによる新規アプリの追加に伴うアプリのＥＣＵへの配置を、ＥＣＵ内の計算・記憶リソースおよびＥＣＵ間の通信リソースを考慮して行うことができる。またＯＴＡによる既存アプリ更新時にも同様の方法にてアプリ配置を行うことができる。
　（まとめ）
　本実施例では、アプリの実行要件５３を満たすように、ネットワーク上に存在する複数の演算装置３，９のいずれかへ前記アプリを配置するネットワークシステムにおいて、前記アプリの実行要件５３および通信要件６４を保持するアプリ要件保持部２１と、複数の演算装置３，９の空きリソース情報を保持する空きリソース情報保持部２０と、実行要件５３と空きリソース情報とに基づいて、複数の演算装置３，９の中から前記アプリを実行可能な演算装置を選択し、アプリ配置先演算装置候補リスト９０を作成するアプリ配置選択部２４と、複数の演算装置３，９の通信接続関係を示すトポロジ情報を保持するトポロジ情報保持部２２と、前記ネットワークの各リンクの通信性能情報を保持する通信性能情報保持部２３と、前記トポロジ情報に基づいて、アプリ配置先演算装置候補リスト９０内の各演算装置に前記アプリを配置した場合の前記アプリの通信経路を選択して通信経路候補リスト１１０を作成する通信経路選択部２５と、通信性能情報と通信要件６４とに基づいて、通信経路候補リスト１１０内の各通信経路にて通信要件６４が満たされるか否かを検証する性能検証部２６と、アプリ配置先演算装置候補リスト９０内の演算装置のうち、性能検証部２６によって通信要件６４が満たされることが検証された通信経路に対応する演算装置に前記アプリを配置する設定適用部２７とを備える。
　また、本実施例では、アプリの実行要件５３を満たすように、ネットワーク上に存在する複数の演算装置３，９のいずれかへ前記アプリを配置するネットワーク管理方法において、前記アプリの実行要件５３および通信要件６４を保持するアプリ要件保持ステップと、複数の演算装置３，９の空きリソース情報を保持する空きリソース情報保持ステップと、実行要件５３と空きリソース情報とに基づいて、複数の演算装置３，９の中から前記アプリを実行可能な演算装置を選択し、アプリ配置先演算装置候補リスト９０を作成するアプリ配置選択ステップと、複数の演算装置３，９の通信接続関係を示すトポロジ情報を保持するトポロジ情報保持ステップと、前記ネットワークの各リンクの通信性能情報を保持する通信性能情報保持ステップと、前記トポロジ情報に基づいて、アプリ配置先演算装置候補リスト９０内の各演算装置に前記アプリを配置した場合の前記アプリの通信経路を選択して通信経路候補リスト１１０を作成する通信経路選択ステップと、通信性能情報と通信要件６４とに基づいて、通信経路候補リスト１１０内の各通信経路にて通信要件６４が満たされるか否かを検証する性能検証ステップと、アプリ配置先演算装置候補リスト９０内の演算装置のうち、前記性能検証ステップによって通信要件６４が満たされることが検証された通信経路に対応する演算装置に前記アプリを配置する設定適用ステップとを備える。
　以上のように構成した本実施例によれば、ネットワーク上に存在する複数の演算装置３，９のいずれかへアプリを配置する際に、各演算装置３，９の演算リソースおよび演算装置間の通信リソースを考慮することにより、アプリの実行性能および通信性能を確保することができるため、アプリを安定的に動作させることが可能となる。
　また、本実施例における通信要件６４および通信性能情報は、アプリの通信帯域、通信遅延、通信ジッタ、およびパケット廃棄率のいずれか１つ以上を含む。これにより、アプリの通信要件６４および通信性能情報を定義することが可能となる。
　また、本実施例における性能検証部２６は、通信経路候補リスト１１０内の各通信経路にて通信要件６４が満たされるか否かを、通信性能情報と通信要件６４とに基づく数値計算により検証する。これにより、通信経路候補リスト１１０内の各通信経路にて通信要件６４が満たされるか否かを簡易的に検証することが可能となる。
　また、本実施例における性能検証部２６は、通信経路候補リスト１１０内の各通信経路にて通信要件６４が満たされるか否かを、通信性能情報と通信要件６４とに基づくシミュレーションにより検証する。通信経路候補リスト１１０内の各通信経路にて通信要件６４が満たされるか否かを高い精度で検証することが可能となる。
　また、本実施例における、前記アプリを配置する際に前記アプリとともに前記ネットワークに入力されるメタデータ４３は、計算リソース、記憶リソース、およびスペックのいずれか１以上を含む実行要件５３と、通信方向、通信相手、通信周期、通信データサイズ、および通信識別情報のいずれか１以上を含む通信仕様５８と、通信帯域、通信遅延、通信ジッタ、パケット廃棄率のいずれか１以上を含む通信要件６４とを含む。これにより、アプリの実行要件５３、通信仕様５８、および通信要件６４を定義することが可能となる。
　また、本実施例におけるネットワークは、車両に搭載された車載ネットワークであり、複数の演算装置３，９は、前記車両に搭載された複数の車載電子制御装置３，９である。これにより、車載ネットワークにおいて、新たに配置したアプリを安定的に動作させることが可能となる。
　また、本実施例における車載装置は、前記ネットワークシステムを備える。これにより、車載装置において、新たに配置したアプリを安定的に動作させることが可能となる。
　また、本実施例における通信要件６４は、前記車両に搭載されたセンサ４から出力されるセンサデータ、前記車両を制御するための制御データ、および前記センサデータから前記制御データを求める演算の途中で得られる中間データに関する項目を含む。これにより、車載装置の要求性能に応じた通信要件６４を定義することが可能となる。
　第１の実施例では数値計算により通信性能を推定した。この方法は計算量が小さく簡便であるが、推定の精度は低い。そこで第２の実施例では別の方法として、ネットワークシミュレーションによる通信性能の推定を行う方法を示す。
　本実施例における主な構成および動作のフローは第１の実施例と同様である。以下、第１の実施例との差分のみ説明することとする。
　図２３は第２の実施例における性能検証部２６の構成図である。本実施例における性能検証部２６は大きく２つの構成が可能である。図２３（ａ）は車内でシミュレーションを実行する場合の構成図である。性能検証部２６はその内部にシミュレーション部２８を有し、これを用いてシミュレーションによる性能検証を行う。図２３（ｂ）は車外でシミュレーションを行う場合の構成図である。ここで車外とは、クラウド、Multi-access Edge Computing（ＭＥＣ）、路側機、あるいは他の車両など、自車両以外の計算リソースを意味する。性能検証部２６は無線通信等により車外に設置されたシミュレーション部２８と通信を行い、必要な設定をシミュレーション部２８へ送信後にシミュレーション部２８へシミュレーション実行を指示し、結果をシミュレーション部２８から受信する。
　図２４は第２の実施例における性能検証部２６の動作のうち、図１６中ステップＳ３０５の動作を示すフローチャートである。まずステップＳ５００にてシミュレーション設定を作成する。次にステップＳ５０１にてシミュレーション部２８を動作させ、シミュレーションを実行する。最後にステップＳ５０２にてシミュレーション結果より経路候補の区間（リンク）別に性能評価結果を取得する。ここで性能評価結果には通信帯域、遅延、ジッタ、パケット廃棄率などを含む。
　以上により本実施例による発明によって、より精度の高い性能評価が可能となり、収容アプリ数の増加やアプリ動作の安定性向上が可能となる。
　（まとめ）
　本実施例におけるネットワークシステムの性能検証部２６は、通信経路候補リスト１１０内の各通信経路にて通信要件６４が満たされるか否かを、通信性能情報と通信要件６４とに基づくシミュレーションにより検証する。
　以上のように構成した本実施例によれば、通信経路候補リスト１１０内の各通信経路にて通信要件６４が満たされるか否かを高い精度で検証することが可能となる。
　また、本実施例におけるネットワーク管理方法の性能検証ステップでは、通信経路候補リスト１１０内の各通信経路にて通信要件６４が満たされるか否かを、車両内部の計算機を用いた、通信性能情報と通信要件６４とに基づくシミュレーションにより検証する。これにより、ネットワークシステムが外部と通信できない環境下でもシミュレーションを行うことが可能となる。
　また、本実施例におけるネットワーク管理方法の性能検証ステップでは、通信経路候補リスト１１０内の各通信経路にて通信要件６４が満たされるか否かを、車両外部の計算機を用いた、通信性能情報と通信要件６４とに基づくシミュレーションにより検証する。これにより、シミュレーションを行うリソースが制限されないため、シミュレーションの精度を向上させることが可能となる。
　第１および第２の実施例においては車載ネットワークのトポロジを固定的なものと仮定していた。一方で車載ネットワークのトポロジは、ＣＡＮ等への新たなデバイスの追加やハードウェア異常等による通信断にて変化しうる。そこで第３の実施例では、このようなトポロジ変化に対し追従可能な車載ネットワークシステムを示す。
　図２５は第３の実施例における車載ネットワークシステムの機能ブロック図である。図３と比較してトポロジ変更監視部２９が追加されている。
　トポロジ変更監視部２９はＣＡＮでは「バス障害」や「エラー状態」により、またイーサネットではＬＬＤＰ（Link Level Discovery Protocol）等の方式を用いて車載ネットワークの状態を監視する。ここで車載ネットワークの状態とは、車載ネットワーク上のリンクが正常に通信可能な状態であるか否かを意味する。正常状態であれば何も動作は行わない。異常が検出された場合、当該リンクの情報をトポロジ情報保持部２２のトポロジ情報テーブル７０上で削除するか異常状態としてマークし、使用しないこととする。その後、配置済みアプリを含めてアプリの再配置を行う。つまり通信経路選択部２５、性能検証部２６、設定適用部２７を動作させ、異常状態となったリンクを避けたアプリ配置および通信経路を設定する。
　（まとめ）
　本実施例におけるネットワークシステムは、ネットワークのトポロジ変化を検出してトポロジ情報保持部２２に通知するトポロジ変更監視部２９をさらに備える。
　以上のように構成した本実施例によれば、ネットワークのトポロジが変化した場合であっても、実行要件５３と通信要件６４とを満たすようにアプリを演算装置３，９へ配置することが可能となる。
　第１および第２の実施例は複数のアプリがＯＴＡにより追加される場合、アプリ間の追加順序を考慮しない。そのため先に追加されたアプリがＥＣＵ内部のリソースやＥＣＵ間の通信リソースを消費してしまい、後から追加するアプリが追加不能となる場合がある。そのため、アプリ間で優先度が異なる場合に、高優先アプリが追加されないこととなる。
　そこで第４の実施例ではアプリ間の優先度を考慮したアプリ配置を行う装置を示す。
　図２６は第4の実施例におけるアプリ要件保持部２１の保持するアプリ要件テーブル５０である。実施例１から３との違いは、通信仕様５８に優先度列６９が追加される点である。図２６では０～７の８段階で優先度を設定しており、０が最低、７が最高の優先度である。なお実行要件５３および通信要件６４は第１および第３の実施例と同一であるため個別の列の記載を省略している。
　図２７は第４の実施例におけるアプリ配置選択部２４の動作を表すフローチャートである。実施例１のフローチャート（図９）と同様の処理は同じ番号を付与している。実施例１から３との違いはステップＳ１０１のループ処理がステップＳ６００のように変更されている点のみである。ステップＳ６００ではアプリに関するループを本実施例におけるアプリ要件テーブル５０の優先度の降順に行う。これにより優先度の高いアプリほど先にＥＣＵ配置および通信経路が決定される。
　（まとめ）
　本実施例におけるアプリ要件保持部２１は、アプリごとに優先度を保持し、アプリ配置選択部２４は、優先度の高いアプリから順にアプリ配置先演算装置候補リスト９０を作成する。
　以上のように構成した本実施例によれば、優先度の高いアプリから順に演算装置３，９へ配置することが可能となる。
　第１から第４の実施例では通信要件の各項目を等しい優先度で扱っているが、アプリによっては通信要件間で要件を充足すべき度合いが異なる場合がある。そこで第５の実施例では、アプリ毎に特に充足すべき通信要件を指定できる構成を示す。
　図２８は第５の実施例におけるアプリ要件保持部２１の保持するアプリ要件テーブル５０である。第１から第４の実施例との違いは、通信要件の各項目に対する優先度列６９ａ～６９ｄが追加されている点である。図２８では０～７の８段階で優先度を設定しており、０が最低、７が最高の優先度である。通信要件の各項目に対する優先度を用いて、アプリ毎に特に充足すべき通信要件を満たすようなアプリ配置を行うことができる。
　図２９は性能検証部２６の動作を表すフローチャートである。第１の実施例１のフローチャート（図１６）と同様の処理は同じ番号を付与している。第１の実施例との違いは、ステップＳ３０６がステップＳ７００に変更された点と、ステップＳ３０７終了後にすぐステップＳ３０８にてアプリ配置失敗とするのではなく、ステップＳ７００およびＳ７０１にて最低優先度の項目を通信要件から除外した上で再度アプリ配置を試みる点である。
　ステップＳ７００ではアプリ通信性能評価の結果、アプリの通信性能が優先度が０より大きい通信要件を満たせるか否かを判断する。満たせる場合（Ｙｅｓ）はアプリ配置成功としてステップＳ３１０以降を実行する。満たせない場合（Ｎｏ）はステップＳ３０７にて経路候補リストに対するループを終了する。
　ステップＳ７０１ではアプリ要件テーブル５０よりアプリの通信要件毎の優先度を調べる。２つ以上の通信要件にて優先度が０より大きい値である場合、当該優先度が０より大きい通信要件のうち優先度が最も低いものを除外可能と判断する。ステップＳ７０１で除外可能と判断された場合（Ｙｅｓ）は、ステップＳ７０２ではステップＳ７００で除外可能と判断した通信要件の優先度を０にて上書きする。ステップＳ７０１で除外不可能と判断された場合（Ｎｏ）は、ステップＳ３０８へと進みアプリ配置失敗とする。
　以上により通信要件のうち特に充足すべき要件を指定し、その要件を満たすアプリ配置を実現することができる。
　（まとめ）
　本実施例におけるアプリ要件保持部２１は、アプリの通信要件６４の項目ごとに優先度を保持し、性能検証部２６は、通信要件６４のうち満足されない項目が１つ以上あった場合に、優先度が最も低い項目を通信要件６４から除外し、通信要件６４が満たされるか否かを再度検証する。
　以上のように構成した本実施例によれば、アプリの通信要件６４から優先度の低い項目を除外することにより、より多くのアプリを演算装置３，９へ配置することが可能となる。
　以上、本発明の実施例について詳述したが、本発明は、上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は、本発明を分かり易く説明するために詳細に説明したものであり、本発明は必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成に他の実施例の構成の一部を加えることも可能であり、ある実施例の構成の一部を削除し、あるいは、他の実施例の一部と置き換えることも可能である。
　１…車両、２…ゲートウェイ、３，３ａ～３ｄ…ドメインＥＣＵ（演算装置、車載電子制御装置）、４，４ａ～４ｄ…センサ、５，５ａ～５ｄ…アクチュエータ、６，６ａ～６ｄ…リンク、７…ＴＣＵ、８…セントラルＥＣＵ（演算装置、車載電子制御装置）、９，９ａ～９ｄ…ゾーンＥＣＵ（演算装置、車載電子制御装置）、１０…共有リンク、１１…ＣＰＵ、１２…メモリ、１３…ネットワークスイッチ、２０…空きリソース情報保持部、２１…アプリ要件保持部、２２…トポロジ情報保持部、２３…通信性能情報保持部、２４…アプリ配置選択部、２５…通信経路選択部、２６…性能検証部、２７…設定適用部、２８…シミュレーション部、２９…トポロジ変更監視部、３０…ＥＣＵ内空きリソース情報テーブル、３１…ＥＣＵ列、３２…計算リソース列、３３…記憶リソース列、３４…スペック列、４０…ＯＴＡデータ、４１…ヘッダ、４２…アプリデータ、４３…メタデータ、５０…アプリ要件テーブル、５１…アプリ列、５２…配置済みフラグ、５３…実行要件、５４…通信ＩＤ、５５…計算リソース列、５６…記憶リソース列、５７…スペック列、５８…通信仕様、５９…通信方向列、６０…通信相手列、６１…通信周期列、６２…パケットサイズ列、６３…アプリ識別情報、６４…通信要件、６５…通信帯域列、６６…通信遅延列、６７…ジッタ列、６８…廃棄率列、６９，６９ａ～６９ｄ…優先度列、７０…トポロジ情報テーブル、７１…リンク列、７２…種別列、７３…接続情報列、８０…通信性能情報テーブル、８１…リンク列、８２…通信方向、８３…総帯域列、８４…帯域列、８５…遅延時間列、８６…ジッタ列、８７…廃棄率列、８８…バッファ使用量列、９０…アプリ配置先ＥＣＵ候補リスト（アプリ配置先演算装置候補リスト）、９１…アプリ列、９２…配置先ＥＣＵ候補、１００…探索リスト、１０１…フェーズ、１０２…通信経路候補、１０３…状態、１１０…通信経路候補リスト、１１１…アプリ列、１１２…通信経路候補、１２０…通信経路リスト、１２１…アプリ列、１２２…通信経路、１３０…通信経路設定テーブル、１３１…ＥＣＵ列、１３２…アプリ識別情報、１３３…転送先ＥＣＵ。

Claims (15)

  1. 　アプリの実行要件を満たすように、ネットワーク上に存在する複数の演算装置のいずれかへ前記アプリを配置するネットワークシステムにおいて、
    　前記アプリの実行要件および通信要件を保持するアプリ要件保持部と、
    　前記複数の演算装置の空きリソース情報を保持する空きリソース情報保持部と、
    　前記実行要件と前記空きリソース情報とに基づいて、前記複数の演算装置の中から前記アプリを実行可能な演算装置を選択し、アプリ配置先演算装置候補リストを作成するアプリ配置選択部と、
    　前記複数の演算装置の通信接続関係を示すトポロジ情報を保持するトポロジ情報保持部と、
    　前記ネットワークの各リンクの通信性能情報を保持する通信性能情報保持部と、
    　前記トポロジ情報に基づいて、前記アプリ配置先演算装置候補リスト内の各演算装置に前記アプリを配置した場合の前記アプリの通信経路を選択して通信経路候補リストを作成する通信経路選択部と、
    　前記通信性能情報と前記通信要件とに基づいて、前記通信経路候補リスト内の各通信経路にて前記通信要件が満たされるか否かを検証する性能検証部と、
    　前記アプリ配置先演算装置候補リスト内の演算装置のうち、前記性能検証部によって前記通信要件が満たされることが検証された通信経路に対応する演算装置に前記アプリを配置する設定適用部とを備える
    　ことを特徴とするネットワークシステム。
  2. 　請求項１に記載のネットワークシステムにおいて、
    　前記通信要件および前記通信性能情報は、前記アプリの通信帯域、通信遅延、通信ジッタ、およびパケット廃棄率のいずれか１つ以上を含む
    　ことを特徴とするネットワークシステム。
  3. 　請求項１に記載のネットワークシステムにおいて、
    　前記性能検証部は、前記通信経路候補リスト内の各通信経路にて前記通信要件が満たされるか否かを、前記通信性能情報と前記通信要件とに基づく数値計算により検証する
    　ことを特徴とするネットワークシステム。
  4. 　請求項１に記載のネットワークシステムにおいて、
    　前記性能検証部は、前記通信経路候補リスト内の各通信経路にて前記通信要件が満たされるか否かを、前記通信性能情報と前記通信要件とに基づくシミュレーションにより検証する
    　ことを特徴とするネットワークシステム。
  5. 　請求項１に記載のネットワークシステムにおいて、
    　前記ネットワークのトポロジ変化を検出して前記トポロジ情報保持部に通知するトポロジ変更監視部をさらに備える
    　ことを特徴とするネットワークシステム。
  6. 　請求項１に記載のネットワークシステムにおいて、
    　前記アプリ要件保持部は、アプリごとに優先度を保持し、
    　前記アプリ配置選択部は、優先度の高いアプリから順に前記アプリ配置先演算装置候補リストを作成する
    　ことを特徴とするネットワークシステム。
  7. 　請求項１に記載のネットワークシステムにおいて、
    　前記アプリ要件保持部は、前記通信要件の項目ごとの優先度を保持し、
    　前記性能検証部は、前記通信要件のうち満足されない項目が１つ以上あった場合に、優先度が最も低い項目を前記通信要件から除外し、前記通信要件が満たされるか否かを再度検証する
    　ことを特徴とするネットワークシステム。
  8. 　請求項１に記載のネットワークシステムにおいて、
    　前記アプリを配置する際に前記アプリとともに前記ネットワークに入力されるメタデータは、
    　計算リソース、記憶リソース、およびスペックのいずれか１以上を含む実行要件と、
    　通信方向、通信相手、通信周期、通信データサイズ、および通信識別情報のいずれか１以上を含む通信仕様と、
    　通信帯域、通信遅延、通信ジッタ、パケット廃棄率のいずれか１以上を含む通信要件とを含む
    　ことを特徴とするネットワークシステム。
  9. 　請求項１に記載のネットワークシステムにおいて、
    　前記ネットワークは、車両に搭載された車載ネットワークであり、
    　前記複数の演算装置は、前記車両に搭載された複数の車載電子制御装置である
    　ことを特徴とするネットワークシステム。
  10. 　請求項９に記載のネットワークシステムを備える
    　ことを特徴とする車載装置。
  11. 　請求項９に記載のネットワークシステムにおいて、
    　前記通信要件は、前記車両に搭載されたセンサから出力されるセンサデータ、前記車両を制御するための制御データ、および前記センサデータから前記制御データを求める演算の途中で得られる中間データに関する項目を含む
    　ことを特徴とするネットワークシステム。
  12. 　アプリの実行要件を満たすように、ネットワーク上に存在する複数の演算装置のいずれかへ前記アプリを配置するネットワーク管理方法において、
    　前記アプリの実行要件および通信要件を保持するアプリ要件保持ステップと、
    　前記複数の演算装置の空きリソース情報を保持する空きリソース情報保持ステップと、
    　前記実行要件と前記空きリソース情報とに基づいて、前記複数の演算装置の中から前記アプリを実行可能な演算装置を選択し、アプリ配置先演算装置候補リストを作成するアプリ配置選択ステップと、
    　前記複数の演算装置の通信接続関係を示すトポロジ情報を保持するトポロジ情報保持ステップと、
    　前記ネットワークの各リンクの通信性能情報を保持する通信性能情報保持ステップと、
    　前記トポロジ情報に基づいて、前記アプリ配置先演算装置候補リスト内の各演算装置に前記アプリを配置した場合の前記アプリの通信経路を選択して通信経路候補リストを作成する通信経路選択ステップと、
    　前記通信性能情報と前記通信要件とに基づいて、前記通信経路候補リスト内の各通信経路にて前記通信要件が満たされるか否かを検証する性能検証ステップと、
    　前記アプリ配置先演算装置候補リスト内の演算装置のうち、前記性能検証ステップによって前記通信要件が満たされることが検証された通信経路に対応する演算装置に前記アプリを配置する設定適用ステップとを備える
    　ことを特徴とするネットワーク管理方法。
  13. 　請求項１２に記載のネットワーク管理方法において、
    　前記ネットワークは、車両に搭載された車載ネットワークであり、
    　前記複数の演算装置は、前記車両に搭載された複数の車載電子制御装置である
    　ことを特徴とするネットワーク管理方法。
  14. 　請求項１３に記載のネットワーク管理方法において、
    　前記性能検証ステップでは、前記通信経路候補リスト内の各通信経路にて前記通信要件が満たされるか否かを、前記車両内部の計算機を用いた、前記通信性能情報と前記通信要件とに基づくシミュレーションにより検証する
    　ことを特徴とするネットワーク管理方法。
  15. 　請求項１３に記載のネットワーク管理方法において、
    　前記性能検証ステップでは、前記通信経路候補リスト内の各通信経路にて前記通信要件が満たされるか否かを、前記車両外部の計算機を用いた、前記通信性能情報と前記通信要件とに基づくシミュレーションにより検証する
    　ことを特徴とするネットワーク管理方法。
PCT/JP2023/028821 2022-11-24 2023-08-07 ネットワークシステム、およびネットワーク管理方法 Ceased WO2024111175A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202380060698.3A CN119654848A (zh) 2022-11-24 2023-08-07 网络系统和网络管理方法
DE112023002997.0T DE112023002997T5 (de) 2022-11-24 2023-08-07 Netzwerksystem, fahrzeuginnengerät, und netzwerkverwaltungsverfahren

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2022-187538 2022-11-24
JP2022187538A JP7828268B2 (ja) 2022-11-24 2022-11-24 ネットワークシステム、およびネットワーク管理方法

Publications (1)

Publication Number Publication Date
WO2024111175A1 true WO2024111175A1 (ja) 2024-05-30

Family

ID=91195337

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/028821 Ceased WO2024111175A1 (ja) 2022-11-24 2023-08-07 ネットワークシステム、およびネットワーク管理方法

Country Status (4)

Country Link
JP (1) JP7828268B2 (ja)
CN (1) CN119654848A (ja)
DE (1) DE112023002997T5 (ja)
WO (1) WO2024111175A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2026046804A (ja) * 2024-09-03 2026-03-13 株式会社オートネットワーク技術研究所 車載ネットワーク管理システム、車載ネットワーク管理装置および車載ネットワーク管理プログラム

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017143365A (ja) * 2016-02-09 2017-08-17 日本電信電話株式会社 アプリケーション配備システム及び方法
JP2020086522A (ja) * 2018-11-15 2020-06-04 株式会社デンソー 車載システム
JP2020137073A (ja) * 2019-02-25 2020-08-31 日本電信電話株式会社 アプリケーション配置装置及びアプリケーション配置プログラム
JP2020149480A (ja) * 2019-03-14 2020-09-17 富士通株式会社 ソフトウェア配信プログラム、ソフトウェア配信方法、および情報処理装置
JP2021197570A (ja) * 2020-06-09 2021-12-27 株式会社日立製作所 コンピューティングサービス管理装置、方法、およびプログラム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017143365A (ja) * 2016-02-09 2017-08-17 日本電信電話株式会社 アプリケーション配備システム及び方法
JP2020086522A (ja) * 2018-11-15 2020-06-04 株式会社デンソー 車載システム
JP2020137073A (ja) * 2019-02-25 2020-08-31 日本電信電話株式会社 アプリケーション配置装置及びアプリケーション配置プログラム
JP2020149480A (ja) * 2019-03-14 2020-09-17 富士通株式会社 ソフトウェア配信プログラム、ソフトウェア配信方法、および情報処理装置
JP2021197570A (ja) * 2020-06-09 2021-12-27 株式会社日立製作所 コンピューティングサービス管理装置、方法、およびプログラム

Also Published As

Publication number Publication date
CN119654848A (zh) 2025-03-18
JP2024076132A (ja) 2024-06-05
JP7828268B2 (ja) 2026-03-11
DE112023002997T5 (de) 2025-04-30

Similar Documents

Publication Publication Date Title
US7570597B2 (en) Discovery process in a vehicle network
JP2018120422A (ja) 車載通信システム、ドメインマスタ、及びファームウェア更新方法
JP2017212727A (ja) 電子制御ユニット、通信方法及び車載ネットワークシステム
WO2019202965A1 (ja) 車載更新装置、車載更新システム、更新処理方法及び更新処理プログラム
JP4987760B2 (ja) 中継装置、通信システム及び通信方法
CN113168314A (zh) 更新管理装置、更新管理系统及更新管理方法
JP7828268B2 (ja) ネットワークシステム、およびネットワーク管理方法
US10300923B2 (en) Device for storing data in a motor vehicle
CN104683126B (zh) 基于can总线的网络管理方法
US20130151660A1 (en) Delay system, delay device and communication device constituting delay system
CN106506252B (zh) 用于通信节点的符合性测试设备和方法
US10771400B2 (en) Relay device
CN112968821A (zh) 电子控制单元、通信方法以及车载网络系统
JP7839284B2 (ja) スリープ／ウェイクアップ方法、システム、および装置
JP2010231407A (ja) 入出力装置
CN117234187A (zh) 车辆的诊断方法、车辆、设备及存储介质
JP7704038B2 (ja) 中継装置、プログラム及び、中継方法
WO2023063068A1 (ja) 車載装置、プログラム及び、プログラムの更新方法
CN118869573B (zh) 面向分布式存储系统的网络数据流调度方法、设备、程序产品及介质
CN117581515A (zh) 车载控制装置、车载系统、信息处理方法及程序
CN104821888B (zh) 用于运行尤其是机动车的通信网络的方法和装置
JP2013106077A (ja) 経路決定装置、ノード装置及び経路決定方法
CN120186086A (zh) 数据传输方法、系统、设备、存储介质及程序产品
JP5728043B2 (ja) ゲートウェイ装置
EP1632062A1 (en) Vehicle network and method of communicating data packets in a vehicle network

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23894191

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 202380060698.3

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 112023002997

Country of ref document: DE

WWP Wipo information: published in national office

Ref document number: 202380060698.3

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 112023002997

Country of ref document: DE

122 Ep: pct application non-entry in european phase

Ref document number: 23894191

Country of ref document: EP

Kind code of ref document: A1