WO2025263148A1 - 通信制御装置およびネットワークシステム - Google Patents

通信制御装置およびネットワークシステム

Info

Publication number
WO2025263148A1
WO2025263148A1 PCT/JP2025/017060 JP2025017060W WO2025263148A1 WO 2025263148 A1 WO2025263148 A1 WO 2025263148A1 JP 2025017060 W JP2025017060 W JP 2025017060W WO 2025263148 A1 WO2025263148 A1 WO 2025263148A1
Authority
WO
WIPO (PCT)
Prior art keywords
communication
requirements
control device
network
requirement
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.)
Pending
Application number
PCT/JP2025/017060
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
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 Astemo Ltd filed Critical Astemo Ltd
Publication of WO2025263148A1 publication Critical patent/WO2025263148A1/ja
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/50—Testing arrangements
    • H04L43/55—Testing of service level quality, e.g. simulating service usage

Definitions

  • the present invention relates to a communication control device and a network system, and in particular to an in-vehicle communication control device that controls an in-vehicle network and an in-vehicle network system equipped with the same.
  • a vehicle system is made up of multiple electronic control units (ECUs: Electronic Control Units) connected via a network.
  • ECU Electronic Control Units
  • ECU is used as a general term for sensors such as cameras, actuators that operate the engine and steering, and devices that perform calculations for control.
  • the ECU sends and receives data via the in-vehicle network, and obtains information for vehicle control by calculating the data using apps.
  • Sending and receiving data places a load on the in-vehicle network, but the load on the in-vehicle network varies depending on the placement of the apps.
  • Communication scheduling requires a network design that utilizes QoS (Quality of Service) functions, which adjust the data transmission priority of network switches, and TSN (Time-Sensitive Network) functions, which control the transmission timing and bandwidth of transmitted data.
  • QoS Quality of Service
  • TSN Time-Sensitive Network
  • Patent Document 1 discloses a method in which, in a wireless communication system, a counter value is set for the traffic that each communication device is attempting to transmit, taking into account, for example, transmission timing and allowable delay amount, and the counter value is expressed as an integer value in units of time slot length, and the traffic to be transmitted in each time slot is identified based on the counter value.
  • variable-length packet transmission timing is scheduled for fixed-length time slots, so the time slots are longer than the maximum length of variable-length packets, and in principle, there are periods when packets are not transmitted.
  • communication performance is ensured by providing a margin for individual communications, communication bandwidth utilization cannot be improved.
  • the number of applications that can be accommodated in SDVs reaches a plateau, and there is a risk that users will not be able to install the apps they want, especially in low-priced ECUs installed in mass-market cars.
  • the degree to which applications affect vehicle driving safety varies. For example, communications related to vehicle driving control such as the engine/motor, brakes, and steering should be prioritized, communications related to sensor data for recognizing the driving environment around the vehicle should be secured as much as possible, and information and entertainment communications such as audio/video should be permitted only when there is capacity. Therefore, simply increasing the number of applications used in SDVs may affect vehicle driving safety.
  • an object of the present invention is to provide a communication control device and network system that enables the addition of applications to SDVs while ensuring vehicle driving safety.
  • the communication control device of the present invention is a communication control device that controls communication on a network including multiple communication devices, and includes: a communication requirements storage unit that stores, for each application, communication requirements that are requirements for the communication performance of the communication, and priorities determined according to the degree of impact the communication has on the operation of a system including the network, for communications related to multiple applications; a communication performance monitoring unit that determines whether the communication satisfies the communication requirements; a communication requirements update unit that updates the communication requirements for the first communication based on the priority of a first communication that is determined by the communication performance monitoring unit not to satisfy the communication requirements and the priority of other communications that are determined to satisfy the communication requirements; a communication setting creation unit that creates communication settings for the network based on the communication requirements updated by the communication requirement update unit; and a setting unit that sets the communication settings created by the communication setting creation unit for the network.
  • the placement takes into account the resources within the ECU and the communication resources between ECUs, ensuring stable operation of the apps by ensuring the execution and communication performance of the apps.
  • FIG. 1 is a diagram showing an electrical and electronic architecture (architecture by domain) inside a vehicle equipped with an in-vehicle network system according to the present invention
  • 1 is a diagram of an electrical and electronic architecture (zone architecture) inside a vehicle equipped with an in-vehicle network system according to the present invention.
  • FIG. 2 is a hardware configuration diagram of a domain ECU.
  • 1 is a hardware configuration diagram of a zone ECU.
  • Gateway hardware configuration diagram. 1 is a hardware configuration diagram of a central ECU.
  • 10 is a flowchart showing the operation of a communication performance monitoring unit 51.
  • 10 is a flowchart showing the operation of a communication requirement update unit 52;
  • 10 is a flowchart showing details of step S122 of the operation of the communication requirement update unit 52;
  • FIG. 10 is a functional block diagram of a network system according to a second embodiment.
  • 10 is a flowchart showing the overall operation of a communication control device 21 according to a second embodiment.
  • 10 is a flowchart showing the overall operation of a communication control device 21 according to a third embodiment.
  • FIG. 10 is a functional block diagram of a network system according to a fourth embodiment.
  • 10 is a flowchart showing the operation of a communication requirement update unit 52 in the fourth embodiment.
  • FIG. 1A A first embodiment of an in-vehicle network system according to the present invention will be described below with reference to FIGS. 1A to 9.
  • FIG. 1A A first embodiment of an in-vehicle network system according to the present invention will be described below with reference to FIGS. 1A to 9.
  • FIGS. 1A and 1B are diagrams each showing the electrical and electronic architecture within a vehicle equipped with an in-vehicle network system according to the present invention. Two configurations are shown here as typical electrical and electronic architectures, but the application of the present invention is not limited to these.
  • Figure 1A shows the logical configuration of an electrical and electronic architecture known as a domain-based architecture. This is a method of classifying the ECUs inside vehicle 1 into functional divisions called domains, and systematically connecting ECUs belonging to the same domain. Each domain is assigned a domain ECU 3a-3d (hereinafter collectively referred to as domain ECU 3) that oversees that domain. Furthermore, to enable communication between domains, domain ECUs 3 are interconnected via gateway 2.
  • domains examples include the ADAS (Advanced Driver Assistance System) domain, which manages safe driving assistance; the PT/CH (Power Train/Chassis) domain, which controls the vehicle's longitudinal and lateral movement; 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 Battery Depleted Domain
  • Each domain is equipped with an ADAS ECU 3a, a PT/CH ECU 3b, a BODY ECU 3c, and an Infotainment ECU 3d (hereinafter collectively referred to as domain ECUs 3).
  • ECUs 4 and 5 such as sensors 4a to 4d (hereinafter collectively referred to as sensors 4) and actuators 5a to 5d (hereinafter collectively referred to as actuators 5), are connected to the domain ECUs 3a to 3d via buses 6a to 6d (hereinafter collectively referred to as buses 6), such as a CAN (Controller Area Network) or a LIN (Local Interconnect Network), that are appropriate for each domain.
  • buses 6 such as a CAN (Controller Area Network) or a LIN (Local Interconnect Network), that are appropriate for each domain.
  • Multiple ECUs 4 and 5 may be connected to a single bus 6.
  • the gateway 2 is connected to a TCU (Telematics Control Unit) 7, which communicates with servers outside the vehicle, cloud services, etc. via a wireless network.
  • TCU Transmission Control Unit
  • Domain ECUs may have different performance and functional requirements for each domain.
  • ADAS ECUs and Infotainment ECUs handle large volumes of data such as video, so they use hardware with high processing performance.
  • PT/CH ECUs are directly connected for safety, so they use highly reliable hardware.
  • FIG. 1B shows the physical configuration of an electrical and electronic architecture known as a zone architecture.
  • This system classifies ECUs 4 and 5 according to their spatial location within the vehicle 1 and connects them to zone ECUs 9a-9d (hereinafter collectively referred to as zone ECUs 9) that oversee these locations. It comprises one or more zone ECUs 9, a central ECU 8 connected to the zone ECUs 9 and running multiple apps across multiple domains, and sensors 4 and actuators 5 connected to the zone ECUs 9.
  • the zone ECUs 9 are positioned in positions corresponding to the front, rear, left, right, etc. within the vehicle 1, and are connected to sensors 4, actuators 5, or both, that are close to their installation locations.
  • zone ECUs 9 are connected to other zone ECUs 9 via a shared bus 10 that uses a common communication method between domains. This common communication method is assumed to be a switching network using Ethernet (registered trademark). Additionally, a TCU 7 is connected. The TCU 7 is connected to the central ECU 8 or any zone ECU 9, but Figure 1B shows an example in which it is connected to the central ECU 8.
  • Figures 2A to 2D show the hardware configurations of the domain ECU 3, zone ECU 9, gateway 2, and central ECU 8, respectively.
  • the thick lines in Figures 2A to 2D represent the common communication method, which is the connection method between communication devices in the zone architecture, and the thin lines represent other communication methods.
  • FIG 2A shows the hardware configuration of a domain ECU 3 in the domain-specific architecture ( Figure 1A).
  • the domain ECU 3 has an internal CPU (Central Processing Unit) 11 for processing information received from the sensors 4 and actuators 5 or the gateway 2, and memory 12 for storing data used for calculations by the CPU 11. From the CPU 11 there are buses for connection to the gateway 2 and buses for connection to the sensors 4 and actuators 5.
  • CPU Central Processing Unit
  • FIG 2B shows the hardware configuration of a zone ECU 9 in the zone architecture ( Figure 1B).
  • the zone ECU 9 is equipped with a network switch 13 that houses a shared bus 10 for connecting to other zone ECUs 9 or for connecting to sensors 4 and actuators 5.
  • the zone ECU 9 also has a CPU 11 for processing information received from the sensors 4 and actuators 5 or the shared bus 10, and is connected to the network switch 13.
  • the CPU 11 is also connected to memory 12. If the sensors 4 and actuators 5 support a common communication method, the memory 12 may be connected directly to the network switch 13. If the sensors 4 and actuators 5 do not support a common communication method, the memory 12 can be connected to the CPU 11 and then converted to the common communication method.
  • FIGS 2C and 2D show the hardware configuration of the gateway 2 in the domain architecture ( Figure 1A) and the central ECU 8 in the zone architecture ( Figure 1B). They have roughly the same configuration, and include a CPU 11, memory 12, and a network switch 13 for connecting to the domain ECU 3 or zone ECU 9.
  • FIG. 3 shows the software configuration executed in a typical ECU.
  • ECUs such as the domain ECU 3, gateway 2, zone ECU 9, and central ECU 8 are comprised of hardware 32, which consists of a CPU (Central Processing Unit) or MCU (Micro-Controller Unit) for executing the software, memory, peripheral circuits, etc.; middleware 31 (which may include an operating system, etc.) that runs on the hardware 32 and provides functions commonly used by various software programs; and application 30, which implements functions necessary for controlling vehicle operation.
  • the various functional blocks in this embodiment are implemented on middleware 31. However, the effects obtained will not change even if some or all of the various functions in this embodiment are implemented as hardware 32 or application 30.
  • FIG 4 is a functional block diagram of a network system in a first embodiment of the present invention. This function is executed as middleware 31 on each of the ECUs 2, 3, 8, and 9 in Figure 1.
  • the network system 19 in this embodiment consists of an in-vehicle network 20, a communication control device 21, and an application management device 22. These devices may be implemented as different ECUs, or some or all of them may be implemented as a single ECU.
  • the application management device 22 may have some or all of its functions located inside the vehicle or outside the vehicle. Examples of devices located outside the vehicle include an OTA server for software updates via OTA and rewrite tools for ECU rewrites at a dealer.
  • the in-vehicle network 20 is a communication path for applications to communicate and is configured by connecting multiple communication devices, or ECUs (such as the domain ECU 3, gateway 2, zone ECU 9, and central ECU 8), and transfers data from a source application to a destination application.
  • the communication control device 21 controls communications on the in-vehicle network 20, which includes multiple ECUs (such as the domain ECU 3, gateway 2, zone ECU 9, and central ECU 8).
  • the application management device 22 is a device that manages the distribution and updates of applications in the SDV.
  • the application management device 22 transfers application data to the destination ECU and makes the new application executable on the ECU (not shown).
  • the application management device 22 transfers data related to application communications to the communication control device 21 as application metadata attached to the application data itself.
  • the data related to application communications in this embodiment refers to all the data shown in FIG. 6, which will be described later.
  • the functional blocks of the network system in the first embodiment of the present invention will be described with reference to the overall network system processing flowchart of Figure 5 (particularly the flowchart showing the overall operation of the communication control device 21).
  • the vehicle starts up and the network system begins its operation, it performs the processes of S100 to S107, and once completed, the vehicle is ready to drive.
  • the application management device 22 creates an application deployment plan for the ECU while the vehicle is stopped. The application deployment plan determines which ECU will execute the application based on ECU performance, available resources, etc.
  • the communication control device 21 creates communication settings for the in-vehicle network 20 and applies them to the in-vehicle network 20.
  • the communication control device 21 performs a communication test on the in-vehicle network 20, simulating communication related to the application while driving.
  • the in-vehicle network 20 measures the communication performance for each application.
  • the communication control device 21 acquires the communication performance for each application measured by the in-vehicle network 20.
  • the communication control device 21 compares the acquired communication performance for each application with the stored communication requirements for each communication of the application, and if there is any communication that does not satisfy the communication requirements (Yes), in S106 the communication control device 21 updates the communication requirements.
  • the process returns to S101, and the process from the creation of the communication settings onwards is carried out again, such as by recreating the communication settings for the in-vehicle network 20. If there is no communication that does not satisfy the communication requirements (No) in S105, the communication of the application satisfies the communication requirements, and therefore the application can operate. Therefore, in S107, the application management device 22 starts the operation of the application, and the process ends.
  • FIG. 4 also shows a functional block diagram of the communication control device 21 and in-vehicle network 20 for implementing the processing of Figure 5.
  • the communication control device 21 further comprises a communication requirements storage unit 50, a communication performance monitoring unit 51, a communication requirements update unit 52, a communication setting creation unit 53, and a setting unit 54.
  • the ECUs included in the in-vehicle network 20 are provided with performance acquisition units 60a-60c (hereinafter collectively referred to as performance acquisition units 60), which measure the communication performance of each communication flow, which is the unit of performance measurement.
  • Communication performance includes, for example, transmission delay time, communication bandwidth, packet loss rate, jitter, etc.
  • Communication flows can be identified by communication identification information consisting of a combination of, for example, source and destination ECUs, source and destination applications, etc.
  • the performance acquisition unit 60 holds and stores the communication performance for this communication identification information and transmits it to the communication control device 21.
  • the communication requirements storage unit 50 stores the communication requirements of an application from metadata related to the application distributed from the application management device 22.
  • Communication requirements are requirements for the communication performance of communication related to the application, and include requirements for transmission delay time, communication bandwidth, packet loss rate, jitter, etc.
  • the communication requirements are communication delay requirements for transmission delay time and communication bandwidth requirements for communication bandwidth.
  • Figure 6 shows the communication requirements storage table 100 stored in the communication requirements storage unit 50.
  • the communication requirements storage table 100 (also referred to as the application requirements storage table 100) stores information on communication parameters such as communication priority 103, communication cycle time 104, and packet length 105, as well as information on communication requirements such as transmission delay requirements 106 and communication bandwidth requirements 107 for each combination of communication identification information, namely, source 101 and destination 102 (i.e., for each application).
  • the communication priority 103 is set according to the degree of impact that the communication has on the operation of the network system, including the in-vehicle network 20.
  • the communication priority 103 is set to a value corresponding to the safety of the communication flow during vehicle operation, thereby ensuring the safety of vehicle operation.
  • the priority of communications related to vehicle operation control such as the engine/motor, brakes, and steering
  • the priority of communications related to sensor data for recognizing the driving environment around the vehicle is set medium (“2" in Figure 6)
  • the priority of communications related to information and entertainment systems, such as audio and video is set low ("1" in Figure 6).
  • a vehicle 1 equipped with this network system is equipped with actuators for driving the vehicle and sensors for recognizing the driving environment around the vehicle, and the priority of communications related to sensor data is set lower than the priority of communications related to actuator control (the priority of communications related to actuator control is set higher than the priority of communications related to sensor data), and the priority of communications other than communications related to actuator control and communications related to sensor data is set lower than the priority of communications related to actuator control and communications related to sensor data.
  • the communication flow is for driving control, sensor data, or information/entertainment communication can be determined by referencing information from the sender 101.
  • the value of the communication priority 103 may be set by the application management device 22 before the application is added to the ECU (before processing by the communication control device 21), or may be set by the communication control device 21 in accordance with the application for each vehicle.
  • the communication performance monitoring unit 51 acquires the communication performance for each communication from the performance acquisition unit 60 of the in-vehicle network 20, and monitors whether the communication performance satisfies the communication requirements (communication requirement fulfillment state).
  • Figure 7 shows a flowchart of the communication performance monitoring unit 51. This shows the details of S104 in the overall processing flowchart of Figure 5.
  • the communication performance monitoring unit 51 acquires the communication requirements for each communication flow from the communication requirement storage unit 50. In particular, it acquires information related to communication requirements such as the transmission delay requirements 106 and the communication bandwidth requirements 107.
  • S111 acquires the communication performance for each communication flow from the performance acquisition unit 60 of the in-vehicle network 20.
  • S112 it compares the communication requirements acquired in S110 for each communication flow with the communication performance acquired in S111.
  • S113 it outputs the communication requirement fulfillment state for each communication flow.
  • the communication requirement update unit 52 updates the communication requirements for each communication flow according to the communication requirement fulfillment state for each communication flow obtained from the communication performance monitoring unit 51.
  • Figure 8 shows a flowchart of the communication requirement update unit 52. This shows the details of S106 in the overall processing flowchart of Figure 5.
  • the communication requirement update unit 52 obtains the communication requirements for each communication flow from the communication requirement storage unit 50.
  • S121 it obtains the communication requirement fulfillment state for each communication flow from the communication performance monitoring unit 51.
  • S122 it updates the communication requirements for communication flows that do not fulfill the communication requirements (details will be explained later).
  • S123 it outputs the updated communication requirements for each communication flow.
  • the communication requirements update unit 52 first determines, in S130, whether there is a first communication whose communication performance does not satisfy the communication requirements. This determination is made based on the communication requirement fulfillment state for each communication flow obtained from the communication performance monitoring unit 51. If there is no first communication (No), the processing ends. If there is a first communication (Yes), the process proceeds to S131. In S131, it determines whether there is a second communication that has a lower priority than the first communication and satisfies the communication requirements. In other words, the priority of the first communication is obtained, and a search is made for a communication flow that satisfies the communication requirements and has a lower priority than the first communication.
  • the communication requirements for the second communication are updated in S132. If there is no second communication (No in S131), the communication requirements for the first communication are updated in S133.
  • the communication requirement update unit 52 determines whether to update the communication requirements for the first communication or the communication requirements for the other communication (other than the first communication) based on the priority of the first communication whose communication performance is determined not to satisfy the communication requirements and the priority of the other communication whose communication performance is determined to satisfy the communication requirements.
  • updating the communication requirements in S132 means loosening the communication requirements.
  • the transmission delay requirement may be set to a value greater than the value set by the application management device 22, or for a communication flow having a communication bandwidth requirement, the communication bandwidth requirement may be set to a value smaller than the value set by the application management device 22.
  • updating the communication requirements in S133 means tightening the communication requirements.
  • the transmission delay requirement may be set to a value smaller than the value set by the application management device 22, or for a communication flow having a communication bandwidth requirement, the communication bandwidth requirement may be set to a value larger than the value set by the application management device 22.
  • the communication setting creation unit 53 creates communication settings for the in-vehicle network 20 using the communication requirements updated by the communication requirement update unit 52.
  • the communication settings can be created using any publicly known technology, such as the technology described in Patent Document 1.
  • the setting unit 54 applies (sets) the communication settings created by the communication setting creation unit 53 to the in-vehicle network 20. This can be done using any known technology, such as NETCONF (Internet Engineering Task Force, Request for Comments: 6241) or SNMP (Simple Network Management Protocol; Internet Engineering Task Force, Request for Comments: 3411).
  • the setting unit 54 also sets performance acquisition conditions for the performance acquisition unit 60. In other words, it sets the communication performance information to be acquired for communication identification information consisting of a combination of the source and destination ECUs, source and destination applications, etc.
  • the communication control device 21 After the setting unit 54 has completed the communication settings, the communication control device 21 performs a communication test on the in-vehicle network 20 that simulates communication related to an application while the vehicle is traveling.
  • the performance margin of the communication settings for the communication requirements of each inserted communication flow is reduced, making it possible to accommodate communication flows that could not be accommodated due to a lack of resources through simple communication design.
  • the value of the communication priority 103 is set to a value that corresponds to the safety of the communication flow during vehicle operation, the safety of vehicle operation can be ensured.
  • the safety of vehicle operation due to changes to the network settings can be reliably ensured.
  • the second embodiment shows a configuration required for enabling application updates while the vehicle is traveling in an SDV.
  • communication settings are created and communication performance is monitored in real time for applications added while the vehicle is traveling. If there is a communication flow whose communication performance does not satisfy the communication requirements, the communication settings are first restored to the state before the application was added, and then the communication requirements are updated and the communication settings are created again.
  • Figure 10 is a block diagram showing the configuration of a network system in the second embodiment.
  • a communication setting storage unit 55 has been added to the communication control device 21.
  • the communication setting storage unit 55 stores communication settings for the in-vehicle network 20 that were previously created, and by reading these settings as needed, it is possible to easily return to the previous communication settings.
  • the network system 19 starts its operation when the application management device 22 adds an application S200.
  • the communication control device 21 creates communication settings for the in-vehicle network 20 and applies them to the in-vehicle network 20.
  • the communication performance for each application is measured for communications actually performed on the in-vehicle network 20.
  • the communication control device 21 acquires the communication performance for each application measured by the in-vehicle network 20.
  • the communication control device 21 compares the acquired communication performance for each application with the stored communication requirements for each communication of the application, and if there is any communication that does not satisfy the communication requirements (Yes), it further checks in S202 whether the communication that does not satisfy the communication requirements is new communication by an application newly added by the application management device 22. If the communication that does not satisfy the communication requirements is new communication (Yes in S202), then in S203, the communication control device 21 switches the communication settings of the in-vehicle network 20 back to the communication settings before the application was added in S200.
  • the communication control device 21 acquires from the communication setting storage unit 55 the previous communication settings at the time when the communication other than the new communication satisfied the communication requirements, and sets the previous communication settings acquired from the communication setting storage unit 55 for the in-vehicle network 20 (easily restoring to the previous communication settings).
  • the communication control device 21 updates the communication requirements and returns to S101. If in S202 the communication that does not satisfy the communication requirements is not new communication (No in S202), then the communication settings are not switched back and the process returns to S101. Thereafter, the process from the creation of the communication settings onward is performed again, such as by recreating the communication settings for the in-vehicle network 20. If in S105 there is no communication that does not satisfy the communication requirements (No), the process ends.
  • each functional block of the communication control device 21 is the same as in the first embodiment, except for the communication setting storage unit 55 added in the second embodiment.
  • the second embodiment ensures the safety of the vehicle while it is traveling, even when an application is added while the vehicle is in motion, and can accommodate communication flows that could not be accommodated due to resource shortages through simple communication design.
  • the communication state in order to update communication settings in response to sudden changes in the communication state in the in-vehicle network 20, the communication state is monitored in real time and communication requirements are updated to update the communication settings, thereby ensuring communication for applications that have a significant impact on the driving safety of the vehicle. Furthermore, when the communication state is restored, the communication settings are restored to their original state, thereby improving the availability of communication for applications other than those that have a significant impact on the driving safety of the vehicle.
  • the configuration of the network system in the third embodiment is the same as that in the first embodiment.
  • the above objective can be achieved by the operation of the overall processing flowchart shown in Figure 12 without changing the operation of each functional block of the network system.
  • the network system shown in the figure operates in a short time (for example, approximately 10 milliseconds, which is the shortest control period of the in-vehicle system).
  • the in-vehicle network 20 measures the communication performance for each application.
  • the communication control device 21 acquires the communication performance for each application measured by the in-vehicle network 20.
  • the communication control device 21 determines whether there has been a change in the acquired communication performance compared to the communication performance acquired last time. If there has been no change (No), the operation for the current period is terminated. If there has been a change (Yes), in S105, the communication control device 21 determines whether there is any communication that does not satisfy the communication requirements.
  • the communication control device 21 updates the communication requirements in S106 and performs S101.
  • the communication control device 21 restores the communication requirements to the original (in other words, the communication requirements before the update) and executes S101. Then in S101, the communication control device 21 creates communication settings for the in-vehicle network 20 and applies them to the in-vehicle network 20. This flow ends in S101 and waits for the next cycle to be executed.
  • the third embodiment prevents degradation of communication performance, which has a significant impact on vehicle driving safety, even when a sudden change in communication state occurs within the in-vehicle network 20, thereby improving vehicle driving safety.
  • the configuration of the network system in the fourth embodiment is shown in Figure 13. Like the second embodiment, the fourth embodiment has a communication setting storage unit 55, but the connection relationship is different.
  • the communication setting storage unit 55 receives and stores information about communication requirements and communication settings created for the communication requirements from the communication setting creation unit 53.
  • the communication setting storage unit 55 then provides communication settings previously created for the communication requirements in response to reference from the communication requirement update unit 52.
  • the network system 19 may also have an external communication device 23 as an additional component.
  • the communication setting storage unit 55 transmits and stores the communication requirements and communication settings stored via the external communication device 23 to an external location such as the cloud, and further searches for and receives communication settings for similar communication requirements from an external location such as the cloud, for use in creating communication settings for its own device. With this configuration, communication settings for communication requirements created in one vehicle can be transmitted to an external location to be shared with other vehicles and used in those other vehicles as well.
  • FIG 14 shows an overview of the communication setting storage table 200 in the communication setting storage unit 55.
  • the communication setting storage table 200 holds the original communication requirements 201 received from the application management device 22, the updated communication requirements 202 updated by the communication control device 21, and the communication settings 203 for the updated communication requirements 202.
  • FIG. 15 shows a flowchart of the communication requirements update unit 52 in the fourth embodiment.
  • the communication requirements update unit 52 first determines in S130 whether there is a first communication whose communication performance does not satisfy the communication requirements. If there is no first communication (No), the processing ends. If there is a first communication (Yes), the processing proceeds to S131. In S131, it determines whether there is a second communication that has a lower priority than the first communication and satisfies the communication requirements. If there is a second communication (Yes in S131), in S400, the communication setting memory unit 55 is searched for communication requirements similar to the communication requirements of the second communication.
  • the communication settings for the communication requirements similar to the communication requirements of the second communication are obtained from the communication setting memory unit 55 and used. If the search results in no communication requirements similar to those of the second communication (No in S400), in S132 the communication requirements of the second communication (not the first communication) are updated, as in the first embodiment.
  • the communication setting storage unit 55 is searched for communication requirements similar to those of the first communication. If the search results in communication requirements similar to those of the first communication (Yes in S401), in S403, communication settings for the communication requirements similar to those of the first communication are obtained from the communication setting storage unit 55 and used. If the search results in no communication requirements similar to those of the first communication (No in S401), in S133, the communication requirements of the first communication are updated as in the first embodiment.
  • the communication setting creation unit 53 does nothing.
  • the fourth embodiment makes it possible to create communication settings more efficiently and shortens the time from adding an application to starting operation when adding an application to SDV.
  • the communication control device 21 is a communication control device 21 that controls communication of a network (in-vehicle network 20) that includes a plurality of communication devices (ECUs), and includes: a communication requirement storage unit 50 that stores, for each application, communication requirements that are requirements for the communication performance of the communication and priorities that are determined according to the degree of impact that the communication has on the operation of a system that includes the network; a communication performance monitoring unit 51 that determines whether the communication (the communication performance of the communication) satisfies the communication requirements (communication requirement satisfaction state); a communication requirement update unit 52 that updates the communication requirements for the first communication based on the priority of a first communication that is determined by the communication performance monitoring unit 51 not to satisfy the communication requirements and the priority of another communication that is determined to satisfy the communication requirements; a communication setting creation unit 53 that creates communication settings for the network based on the communication requirements updated by the communication requirement update unit 52; and a setting unit 54 that sets the communication settings created
  • the communication requirement update unit 52 updates the communication requirements for a second communication that has a lower priority than the first communication and is determined to satisfy the communication requirements (S132 in FIG. 9).
  • the communication control device 21 performs communication for the application using the communication settings created by the communication setting creation unit 53 before the application operates (communication test), acquires the communication performance of the communication using the communication performance monitoring unit 51, and starts operation of the application if the acquired communication performance of the communication satisfies the communication requirements (S107 in FIG. 5). If the acquired communication performance of the communication does not satisfy the communication requirements, the application does not operate, updates the communication requirements, and recreates the communication settings for the network (S106 and subsequent steps in FIG. 5).
  • the communication control device 21 further includes a communication setting storage unit 55 that stores the communication settings created in the past, and when the first communication determined not to satisfy the communication requirements is communication related to a newly added application, the communication requirement update unit 52 obtains from the communication setting storage unit 55 the past communication settings at the time when communication other than the communication related to the newly added application satisfied the communication requirements, and the setting unit 54 sets the past communication settings obtained from the communication setting storage unit 55 for the network (second embodiment).
  • the communication performance monitoring unit 51 further monitors communication performance degradation in real time, and the communication requirement update unit 52 updates the communication requirements when communication performance degradation occurs and restores the communication requirements when the communication performance degradation is resolved (third embodiment).
  • the communication control device 21 further includes a communication setting storage unit 55 that stores the communication settings previously created for the communication requirements.
  • the communication requirement update unit 52 searches the communication setting storage unit 55 for communication requirements similar to the communication requirements. If a communication requirement similar to the communication requirement is found, the communication setting for the communication requirement similar to the communication requirement is obtained from the communication setting storage unit 55.
  • the setting unit 54 then configures the network using the communication settings obtained from the communication setting storage unit 55 (fourth embodiment).
  • the communication setting storage unit 55 transmits the stored communication requirements and communication settings to the outside to share them with other communication control devices, and (for example, if no communication requirements similar to the communication requirements are found) receives the communication requirements and communication settings stored in the other communication control device from the outside and uses them to create the communication settings in the device itself (fourth embodiment).
  • the communication requirements update unit 52 determines whether to update the communication requirements for the first communication or the communication requirements for the other communication based on the priority of the first communication determined by the communication performance monitoring unit 51 not to satisfy the communication requirements and the priority of the other communication determined to satisfy the communication requirements.
  • the communication requirement update unit 52 updates the communication requirements for the second communication; if there is no second communication that has a lower priority than the first communication and is determined to satisfy the communication requirements, the communication requirement update unit 52 updates the communication requirements for the first communication.
  • the network system 19 is a network system 19 having the aforementioned communication control device 21, and further includes an application management device 22 that adds (distributes) the application, and a network (on-board network 20) that is a communication path for the application to communicate and is made up of multiple communication devices (ECUs), and further includes a performance acquisition unit 60 within the communication devices (ECUs) that make up the network (on-board network 20) that acquires the communication performance of each application.
  • ECUs multiple communication devices
  • the priority is determined by the application management device 22 before the application is added to the communication device (ECU).
  • the priority is determined by the communication control device 21.
  • the communication control device 21 in this embodiment updates communication requirements according to the impact of the application on the vehicle's driving safety, and manages communication setting updates, switching back, etc.
  • the placement takes into consideration the resources within the ECU and the communication resources between ECUs, and by ensuring the execution performance and communication performance of the apps, stable operation of the apps is ensured, thereby providing a communication control device and network system that enables the addition of applications to SDVs while ensuring the driving safety of the vehicle.
  • the present invention is not limited to the above-described embodiments, and includes various modifications.
  • the above-described embodiments have been described in detail to clearly explain the present invention, and are not necessarily limited to those that include all of the configurations described.
  • it is possible to replace part of the configuration of one embodiment with the configuration of another embodiment and it is also possible to add the configuration of another embodiment to the configuration of one embodiment.
  • control and information lines shown are those considered necessary for the explanation, and do not necessarily represent all control and information lines on the product. In reality, it is safe to assume that almost all components are interconnected.
  • Vehicle 2 Gateway 3 Domain ECU 4 Sensor 5 Actuator 6 Bus 7 TCU 8 Central ECU 9 Zone ECU 10 shared bus 11 CPU 12 Memory 13 Network switch 19 Network system 20 In-vehicle network 21 Communication control device 22 Application management device 23 External communication device 30 Application 31 Middleware 32 Hardware 100 Communication requirement storage table 200 Communication setting storage table

Landscapes

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

Abstract

ＳＤＶにおいて、車両の走行安全性を確保しつつ、ネットワークに収容可能な通信数を向上することができる通信制御装置およびネットワークシステムを提供する。複数のアプリケーションに係る通信に関して、通信の通信性能に対する要件である通信要件、および、通信がネットワークを含むシステムの動作に与える影響の度合いに応じて定められた優先度を、アプリケーション毎に記憶し、通信（の通信性能）が通信要件を満たすか否か（通信要件充足状態）を判断し、通信要件を満たさないと判断された第一の通信の優先度および通信要件を満たすと判断された他の通信の優先度に基づいて、第一の通信に対する前記通信要件を更新する。

Description

通信制御装置およびネットワークシステム
　本発明は、通信制御装置およびネットワークシステムに関し、特に車載ネットワークの制御を行う車載通信制御装置およびそれを具備する車載ネットワークシステムに関する。
　自動運転や安全運転支援技術は日進月歩であり、今後も進化が続く。自動車メーカにおいては、これらの技術進歩を新型車両へ適用するだけでなく、販売済み車両にも適用することが検討されている。そのための技術にＯＴＡ（Ｏｖｅｒ－ｔｈｅ－Ａｉｒ）アップデート技術がある。ＯＴＡ等によりソフトウェアを適宜インストールするなど、ソフトウェアの変更を可能とすることで、挙動をソフトウェアにより変更可能とした車両をＳＤＶ（Ｓｏｆｔｗａｒｅ－Ｄｅｆｉｎｅｄ　Ｖｅｈｉｃｌｅ）と呼ぶ。
　車両システムは、複数の電子制御ユニット（ＥＣＵ：Ｅｌｅｃｔｒｏｎｉｃ　Ｃｏｎｔｒｏｌ　Ｕｎｉｔ）がネットワークにより接続された構成となっている。ここでＥＣＵは、カメラ等のセンサ、エンジンやステアリング等を操作するアクチュエータ、および制御のための演算を実行する装置の総称として用いる。ＥＣＵでは、車載ネットワークを介してデータを送受信し、アプリによりデータを演算することで車両制御のための情報を得る。データの送受信により車載ネットワークには負荷がかかるが、アプリの配置状況によって車載ネットワークの負荷状況は異なる。
　車載アプリの機能を成立させるためには、アプリのスケジューリングにより処理時間を確保するだけでなく、通信機能においても通信のスケジューリングにより性能確保をする必要がある。通信スケジューリングにおいては、ネットワークスイッチのデータ送信優先度を調整するＱｏＳ（Ｑｕａｌｉｔｙ　ｏｆ　Ｓｅｒｖｉｃｅ）機能や、送信データの送信タイミングや送信帯域を制御するＴＳＮ（Ｔｉｍｅ－Ｓｅｎｓｉｔｉｖｅ　Ｎｅｔｗｏｒｋ）機能を活用したネットワーク設計が必要である。
　ネットワーク設計においては、アプリの要求する通信遅延などの通信要件を基にネットワークのパラメータを設計する方法が、例えば特許文献１に開示されている。特許文献１には、無線通信システムでは、各通信機器が送信しようとしているトラフィックについて、例えば、送信タイミング、許容遅延量を考慮したカウンタ値であって、タイムスロット長を単位とする整数値により表されるカウンタ値を設定し、当該カウンタ値に基づいて、各タイムスロットで送信すべきトラフィックを特定する方法が開示されている。
特開２０２０－１５５８５７号公報
　特許文献１に記載の技術では、固定長のタイムスロットに対して可変長のパケットの送信タイミングをスケジュールするため、タイムスロットは可変長パケットの最大長以上の時間となっており、原理的にパケットが送信されない期間が存在する。つまり、個別通信にマージンを与えて通信性能を確保するため、通信帯域利用率を向上できない。そのため、ＳＤＶにおけるアプリケーション収容数が頭打ちとなり、特に大衆車に搭載される低価格帯のＥＣＵにてユーザの求めるアプリをインストールできなくなる恐れがある。また、車載ネットワークにおける通信設定のマージンを縮小することにより、ネットワークに収容可能な通信数を増加させてＳＤＶによるアプリのインストール（追加）を実現する場合において、アプリケーションが車両の走行安全性に影響を与える度合いが異なる。例えば、エンジン／モータ、ブレーキ、ステアリングといった車両の走行制御に関する通信は優先的に通信を確保し、車両周辺の走行環境を認識するためのセンサデータに関する通信は可能な限り通信を確保し、オーディオ・ビデオ等の情報系やエンターテインメント系通信は余裕のある場合に許可する必要がある。そのため、ＳＤＶにおいては使用するアプリケーション数を単に増加させるのみでは、車両の走行安全性に影響を及ぼす可能性がある。
　したがって、車両の走行安全性を確保しつつ、ＳＤＶにおけるアプリケーション追加を可能とする通信制御装置およびネットワークシステムを提供することが本発明における目的である。
　上記課題を解決するために、本発明による通信制御装置は、複数の通信装置を含むネットワークの通信を制御する通信制御装置であって、複数のアプリケーションに係る通信に関して、前記通信の通信性能に対する要件である通信要件、および、前記通信が前記ネットワークを含むシステムの動作に与える影響の度合いに応じて定められた優先度を、前記アプリケーション毎に記憶する通信要件記憶部と、前記通信が前記通信要件を満たすか否かを判断する通信性能監視部と、前記通信性能監視部により前記通信要件を満たさないと判断された第一の通信の優先度および前記通信要件を満たすと判断された他の通信の優先度に基づいて、前記第一の通信に対する前記通信要件を更新する通信要件更新部と、前記通信要件更新部により更新された前記通信要件に基づいて、前記ネットワークに対する通信設定を作成する通信設定作成部と、前記通信設定作成部により作成された前記通信設定を前記ネットワークに対して設定する設定部と、を備える。
　本発明によれば、通信装置であるＥＣＵへのアプリ配置の際に、ＥＣＵ内部のリソースおよびＥＣＵ間の通信リソースを考慮した配置を行い、アプリの実行性能および通信性能を確保することによりアプリの安定的な動作を確保することで、車両の走行安全性を確保しつつ、ＳＤＶにおけるアプリケーション追加を可能とする通信制御装置およびネットワークシステムを提供することができる。
　上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
本発明による車載ネットワークシステムを搭載する車両内部の電気電子アーキテクチャ（ドメイン別アーキテクチャ）の図。 本発明による車載ネットワークシステムを搭載する車両内部の電気電子アーキテクチャ（ゾーンアーキテクチャ）の図。 ドメインＥＣＵのハードウェア構成図。 ゾーンＥＣＵのハードウェア構成図。 ゲートウェイのハードウェア構成図。 セントラルＥＣＵのハードウェア構成図。 ＥＣＵとＥＣＵ上で実行されるソフトウェアの構成図。 第１の実施例におけるネットワークシステムの機能ブロック図。 第１の実施例における通信制御装置２１の全体動作を表すフローチャート。 通信要件記憶部５０が保持するアプリ要件記憶テーブル１００。 通信性能監視部５１の動作を表すフローチャート。 通信要件更新部５２の動作を表すフローチャート。 通信要件更新部５２の動作のうちＳ１２２の詳細を表すフローチャート。 第２の実施例におけるネットワークシステムの機能ブロック図。 第２の実施例における通信制御装置２１の全体動作を表すフローチャート。 第３の実施例における通信制御装置２１の全体動作を表すフローチャート。 第４の実施例におけるネットワークシステムの機能ブロック図。 通信設定記憶部５５が保持する通信設定記憶テーブル２００。 第４の実施例における通信要件更新部５２の動作を表すフローチャート。
［第１の実施例］
　以下、図１Ａ～図９を参照して、本発明による車載ネットワークシステムの第１の実施例を説明する。
　図１Ａおよび図１Ｂはそれぞれ、本発明による車載ネットワークシステムを搭載する車両内部の電気電子アーキテクチャを示す図である。ここでは代表的な電気電子アーキテクチャとして２つの構成を取り上げるが、本発明の適用先はこれに限定されるものではない。
　図１Ａは、電気電子アーキテクチャとしてドメイン別アーキテクチャと呼ばれるアーキテクチャの論理的構成を示す図である。これは、車両１内部のＥＣＵをドメインと呼ばれる機能別区分に分類し、同一ドメインに属するＥＣＵを体系的に接続する方式である。ドメイン毎にそのドメインを統括するドメインＥＣＵ３ａ～３ｄ（以下まとめてドメインＥＣＵ３とも表記する）が置かれる。また、ドメイン間で通信を行うために、ドメインＥＣＵ３はゲートウェイ２を介して相互に接続される。ドメインには、例えば安全運転支援を司るＡＤＡＳ（Ａｄｖａｎｃｅｄ　Ｄｒｉｖｅｒ　Ａｓｓｉｓｔａｎｃｅ　Ｓｙｓｔｅｍ）ドメイン、車両の前後方向および左右方向の運動を制御するＰＴ／ＣＨ（Ｐｏｗｅｒ　Ｔｒａｉｎ／Ｃｈａｓｓｉｓ）ドメイン、パワーウィンドウ等の電装機器を制御するＢＯＤＹドメイン、ナビゲーションやオーディオを制御するＩｎｆｏｔａｉｎｍｅｎｔドメインなどがある。それぞれのドメインに対してＡＤＡＳ　ＥＣＵ　３ａ、ＰＴ／ＣＨ　ＥＣＵ　３ｂ、ＢＯＤＹ　ＥＣＵ　３ｃ、Ｉｎｆｏｔａｉｎｍｅｎｔ　ＥＣＵ　３ｄ（以下これらをまとめてドメインＥＣＵ３とも表記する）が設置される。ドメインＥＣＵ３ａ～３ｄにはセンサ４ａ～４ｄ（以下まとめてセンサ４とも表記する）やアクチュエータ５ａ～５ｄ（以下まとめてアクチュエータ５とも表記する）などのＥＣＵ４、５がＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）、ＬＩＮ（Ｌｏｃａｌ　Ｉｎｔｅｒｃｏｎｎｅｃｔ　Ｎｅｔｗｏｒｋ）等、ドメイン毎に適したバス６ａ～６ｄ（以下まとめてバス６とも表記する）により接続される。単一のバス６に複数のＥＣＵ４、５が接続される場合がある。また、ゲートウェイ２に、車外のサーバやクラウド等と無線ネットワークを介して通信を行うＴＣＵ（Ｔｅｌｅｍａｔｉｃｓ　Ｃｏｎｔｒｏｌ　Ｕｎｉｔ）７が接続される。
　ドメインＥＣＵは、ドメインごとに性能や機能要件が異なることがある。例えば、ＡＤＡＳ　ＥＣＵやＩｎｆｏｔａｉｎｍｅｎｔ　ＥＣＵは、ビデオ等の大容量データを扱うため、処理性能の高いハードウェアが用いられる。一方、ＰＴ／ＣＨ　ＥＣＵは、安全に直結するため、信頼性の高いハードウェアが用いられる。
　図１Ｂは、電気電子アーキテクチャとしてゾーンアーキテクチャと呼ばれるアーキテクチャの物理的構成を示す図である。これは、ＥＣＵ４、５を車両１内部の空間的な位置によって分類し、その位置を統括するゾーンＥＣＵ９ａ～９ｄ（以下まとめてゾーンＥＣＵ９とも表記する）へ接続する方式である。１つ以上のゾーンＥＣＵ９、ゾーンＥＣＵ９に接続して複数ドメインにまたがる複数のアプリを実行するセントラルＥＣＵ８、ゾーンＥＣＵ９に接続するセンサ４およびアクチュエータ５などから構成される。このゾーンＥＣＵ９は、その名の通り、車両１内での前後左右等の位置に対応して配置されており、その設置位置に近接するセンサ４またはアクチュエータ５、あるいはその両方と接続される。また、ゾーンＥＣＵ９は、ドメイン間で共通通信方式を用いた共有バス１０により他のゾーンＥＣＵ９と接続される。共通通信方式は、Ｅｔｈｅｒｎｅｔ（登録商標）によるスイッチングネットワークが想定される。加えて、ＴＣＵ７が接続される。ＴＣＵ７は、セントラルＥＣＵ８または任意のゾーンＥＣＵ９に接続されるが、図１Ｂでは、セントラルＥＣＵ８に接続する例を示している。
　図２Ａ～図２Ｄはそれぞれ、ドメインＥＣＵ３、ゾーンＥＣＵ９、ゲートウェイ２およびセントラルＥＣＵ８のハードウェア構成である。図２Ａ～図２Ｄ中の太線は、ゾーンアーキテクチャにおける通信装置間の接続方式である共通通信方式を表しており、細線は、その他の通信方式を表している。
　図２Ａは、ドメイン別アーキテクチャ（図１Ａ）におけるドメインＥＣＵ３のハードウェア構成である。ドメインＥＣＵ３は、内部に、センサ４およびアクチュエータ５あるいはゲートウェイ２から受信した情報を処理するためのＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）１１、およびＣＰＵ１１で演算を行うために用いるデータを保持するメモリ１２を持ち、ＣＰＵ１１からはゲートウェイ２へ接続するためのバスおよびセンサ４・アクチュエータ５へ接続するためのバスが出ている。
　図２Ｂは、ゾーンアーキテクチャ（図１Ｂ）におけるゾーンＥＣＵ９のハードウェア構成である。ゾーンＥＣＵ９は、他のゾーンＥＣＵ９へ接続するため、あるいはセンサ４やアクチュエータ５へ接続するための共有バス１０を収容するネットワークスイッチ１３を備える。また、ゾーンＥＣＵ９は、センサ４およびアクチュエータ５、あるいは共有バス１０から受信した情報を処理するためのＣＰＵ１１を備え、ネットワークスイッチ１３と接続される。また、ＣＰＵ１１はメモリ１２とも接続される。センサ４およびアクチュエータ５が共通通信方式に対応している場合は、メモリ１２はネットワークスイッチ１３へ直接接続してもよい。センサ４およびアクチュエータ５が共通通信方式に対応していない場合は、メモリ１２はＣＰＵ１１へと接続したうえで共通通信方式へ変換することができる。
　図２Ｃおよび図２Ｄは、ドメイン別アーキテクチャ（図１Ａ）におけるゲートウェイ２およびゾーンアーキテクチャ（図１Ｂ）におけるセントラルＥＣＵ８のハードウェア構成である。これらはおおむね同様の構成となっており、ＣＰＵ１１、メモリ１２、およびドメインＥＣＵ３またはゾーンＥＣＵ９へ接続するためのネットワークスイッチ１３を備える。
　図３は、一般的なＥＣＵにおいて実行されるソフトウェアの構成を表す図である。ドメインＥＣＵ３、ゲートウェイ２、ゾーンＥＣＵ９、セントラルＥＣＵ８等のＥＣＵにおいては、ソフトウェアを実行するためのＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）あるいはＭＣＵ（Ｍｉｃｒｏ－Ｃｏｎｔｒｏｌｌｅｒ　Ｕｎｉｔ）、メモリ、周辺回路等からなるハードウェア３２、ハードウェア３２上で動作して各種ソフトウェアに共通で利用される機能を提供するミドルウェア３１（ここではオペレーティングシステム等を含んでよい）、および車両動作の制御に必要となる機能を実装したアプリケーション３０からなる。本実施例の各種機能ブロックは、特段の断りが無い限り、ミドルウェア３１上に実装されるものとする。ただし、本実施例の各種機能の一部または全部を、ハードウェア３２あるいはアプリケーション３０として実装したとしても、得られる効果に何ら変わりはない。
　図４は、本発明の第１の実施例におけるネットワークシステムの機能ブロック図である。本機能は、図１における各ＥＣＵ２、３、８、９上で、ミドルウェア３１として実行される。本実施例におけるネットワークシステム１９は、車載ネットワーク２０、通信制御装置２１、およびアプリケーション管理装置２２からなる。これらの装置は異なるＥＣＵとして実装されてもよいし、一部または全部を単一のＥＣＵとして実装してもよい。また、アプリケーション管理装置２２は、その機能の一部または全部を車両内部に備えてもよいし、車両外部に備えてもよい。車両外部に備える例としては、ＯＴＡによるソフトウェア更新時のＯＴＡサーバや、ディーラでのＥＣＵ書き換え時の書き換えツール類が相当する。車載ネットワーク２０は、アプリケーションが通信を行うための通信路であって複数の通信装置であるＥＣＵ（ドメインＥＣＵ３、ゲートウェイ２、ゾーンＥＣＵ９、セントラルＥＣＵ８等）を接続して構成され、送信元アプリケーションから宛先アプリケーションへデータを転送する。通信制御装置２１は、複数のＥＣＵ（ドメインＥＣＵ３、ゲートウェイ２、ゾーンＥＣＵ９、セントラルＥＣＵ８等）を含む車載ネットワーク２０の通信を制御する。アプリケーション管理装置２２は、ＳＤＶにおけるアプリケーションの配布や更新といった管理を行う装置である。アプリケーション管理装置２２は、アプリケーションデータを展開先のＥＣＵへ転送し、新たなアプリケーションをＥＣＵ上で実行可能な状態とする（不図示）。加えて、アプリケーション管理装置２２は、アプリケーションデータ本体に付随するアプリケーションのメタデータとして、アプリケーションの通信に関するデータを通信制御装置２１へ転送する。ここで本実施例におけるアプリケーションの通信に関するデータは、後述する図６に示す全てのデータとする。
　本発明の第１の実施例におけるネットワークシステムの各機能ブロックの説明を、図５のネットワークシステム全体処理フローチャート（特に、通信制御装置２１の全体動作を表すフローチャート）を参照しながら行う。まず、車両が起動し、ネットワークシステムはその動作を開始すると、Ｓ１００～Ｓ１０７の処理を実施し、完了後に車両は走行可能となる。Ｓ１００では、アプリケーション管理装置２２にて、車両の停車中に、ＥＣＵへのアプリケーション配置計画を作成する。アプリケーション配置計画とは、当該アプリケーションをどのＥＣＵにて実施するかを、ＥＣＵ性能および空きリソース等を基に計画する。次にＳ１０１にて、通信制御装置２１が、車載ネットワーク２０用の通信設定を作成し、車載ネットワーク２０へ適用する。続くＳ１０２では、通信制御装置２１が、車載ネットワーク２０に対して、走行時のアプリケーションに係る通信を模擬した通信テストを実施する。この通信テストに対してＳ１０３にて、車載ネットワーク２０はアプリケーション毎の通信性能を測定する。その後、Ｓ１０４にて、通信制御装置２１が、車載ネットワーク２０が測定したアプリケーション毎の通信性能を取得する。Ｓ１０５にて、通信制御装置２１が、取得したアプリケーション毎の通信性能と記憶している通信要件をアプリケーションの通信ごとに比較し、通信要件を満たさない通信がある場合（Ｙｅｓ）、Ｓ１０６にて、通信制御装置２１が通信要件を更新する。その後はＳ１０１に戻り、車載ネットワーク２０用の通信設定を再度作成するなど、通信設定の作成以降を再実施する。Ｓ１０５にて、通信要件を満たさない通信がない場合（Ｎｏ）、当該アプリケーションの通信が通信要件を満たすため、アプリケーションの動作が可能となる。そこでＳ１０７にて、アプリケーション管理装置２２がアプリケーションの動作を開始し、処理を終了する。
　図４に、図５の処理を実現するための通信制御装置２１および車載ネットワーク２０の機能ブロック図もあわせて示す。通信制御装置２１はさらに、通信要件記憶部５０、通信性能監視部５１、通信要件更新部５２、通信設定作成部５３、および設定部５４からなる。車載ネットワーク２０に含まれるＥＣＵには性能取得部６０ａ～６０ｃ（以下まとめて性能取得部６０とも表記する）を設け、性能測定の単位である通信フローごとにその通信性能を測定する。通信性能とは、例えば、伝送遅延時間、通信帯域、パケット廃棄率、ジッターなどを含む。通信フローは、例えば、送信元・宛先ＥＣＵ、送信元・宛先アプリケーションなどの組み合わせからなる通信識別情報によって識別することができる。性能取得部６０では、これらの通信識別情報に対する通信性能を保持して記憶し、通信制御装置２１へ送信する。
　通信要件記憶部５０は、アプリケーション管理装置２２から配信されたアプリケーションに関するメタデータより、アプリケーションの通信要件を記憶する。通信要件とは、アプリケーションに係る通信の通信性能に対する要件であり、伝送遅延時間、通信帯域、パケット廃棄率、ジッターなどに対する要件を含む。本実施例における通信要件は、伝送遅延時間に対する通信遅延要件、および通信帯域に対する通信帯域要件とする。通信要件記憶部５０が保持する通信要件記憶テーブル１００を図６に示す。通信要件記憶テーブル１００（アプリ要件記憶テーブル１００とも呼ぶ）は、通信識別情報である送信元１０１、宛先１０２の組み合わせに対し（すなわち、アプリケーション毎に）、通信優先度１０３、通信周期１０４やパケット長１０５といった通信パラメータに関する情報、伝送遅延要件１０６や通信帯域要件１０７といった通信要件に関する情報を保持する。
　通信優先度１０３は、通信が車載ネットワーク２０を含むネットワークシステムの動作に与える影響の度合いに応じて設定される。通信優先度１０３は、通信フローの車両走行における安全性に対応する値とすることで、車両走行の安全性を確保することができる。例えば、エンジン／モータ、ブレーキ、ステアリングといった車両の走行制御に関する通信の優先度を高く（図６中“３”）、車両周辺の走行環境を認識するためのセンサデータに関する通信の優先度を中に（図６中“２”）、オーディオ・ビデオ等の情報系やエンターテインメント系通信の優先度を低に（図６中“１”）設定する。言い換えれば、本ネットワークシステムを搭載する車両１は、車両を駆動するためのアクチュエータ、車両周辺の走行環境を認識するためのセンサなどを備え、アクチュエータの制御に関する通信の優先度よりも、センサのデータに関する通信の優先度を低く設定（センサのデータに関する通信の優先度よりも、アクチュエータの制御に関する通信の優先度を高く設定）し、アクチュエータの制御に関する通信およびセンサのデータに関する通信以外の通信の優先度を、アクチュエータの制御に関する通信およびセンサのデータに関する通信の優先度よりも低く設定する。通信フローが、走行制御、センサデータ、情報系・エンターテインメント系通信のいずれかであるかは、送信元１０１の情報を参照することにより決定することができる。なお、通信優先度１０３の値の設定主体は、アプリケーション管理装置２２によりアプリケーションのＥＣＵへの追加前（当該通信制御装置２１での処理の事前）に設定してもよいし、当該通信制御装置２１により車両ごとのアプリケーションに対応して設定してもよい。
　通信性能監視部５１は、通信ごとの通信性能を車載ネットワーク２０の性能取得部６０より取得し、通信性能が通信要件を満たしているかどうか（通信要件充足状態）の監視を行う。図７に、通信性能監視部５１のフローチャートを示す。これは、図５の全体処理フローチャートのうち、Ｓ１０４の詳細を表す。通信性能監視部５１は、まずＳ１１０にて、通信要件記憶部５０から通信フローごとの通信要件を取得する。特に、伝送遅延要件１０６や通信帯域要件１０７といった通信要件に関する情報を取得する。次にＳ１１１にて、車載ネットワーク２０の性能取得部６０から、通信フローごとの通信性能を取得する。続いてＳ１１２にて、通信フローごとにＳ１１０で取得した通信要件とＳ１１１で取得した通信性能を比較する。最後にＳ１１３にて、通信フローごとの通信要件充足状態を出力する。
　通信要件更新部５２は、通信性能監視部５１から得た通信フローごとの通信要件充足状態に応じて、通信フローごとの通信要件を更新する。図８に、通信要件更新部５２のフローチャートを示す。これは、図５の全体処理フローチャートのうち、Ｓ１０６の詳細を表す。通信要件更新部５２は、まずＳ１２０にて、通信要件記憶部５０から通信フローごとの通信要件を取得する。次にＳ１２１にて、通信性能監視部５１から通信フローごとの通信要件充足状態を取得する。続いてＳ１２２にて、通信要件を満たさない通信フローに対して、その通信要件の更新を行う（詳細は後で説明）。最後にＳ１２３にて、通信フローごとに更新後の通信要件を出力する。
　通信要件更新部５２におけるＳ１２２の詳細フローチャートを図９に示す。通信要件更新部５２は、まずＳ１３０にて、通信性能が通信要件を満たさない第一の通信があるかどうかを判定する。これは、通信性能監視部５１から取得した通信フローごとの通信要件充足状態を基に判定する。第一の通信がない場合（Ｎｏ）、処理を終了する。第一の通信がある場合（Ｙｅｓ）、Ｓ１３１に進む。Ｓ１３１では、前記第一の通信よりも優先度が低く、かつ通信要件を満たす第二の通信があるかどうかを判定する。つまり、第一の通信の優先度を取得し、通信要件を満たす通信フローの中でその優先度が第一の通信よりも小さいものを検索する。第二の通信がある場合（Ｓ１３１にてＹｅｓ）、Ｓ１３２にて、（第一の通信ではなく）第二の通信に対する通信要件を更新する。第二の通信がない場合（Ｓ１３１にてＮｏ）、Ｓ１３３にて、第一の通信に対する通信要件を更新する。言い換えれば、通信要件更新部５２は、通信性能が通信要件を満たさないと判定された第一の通信の優先度および通信性能が通信要件を満たすと判定された他の通信の優先度に基づいて、第一の通信に対する通信要件を更新するか否か、あるいは、（第一の通信でなく）他の通信に対する通信要件を更新するか否か、を判断する。ここでＳ１３２での通信要件の更新とは、通信要件を緩く設定することであり、例えば、伝送遅延の要件を持つ通信フローに対しては伝送遅延の要件をアプリケーション管理装置２２が設定した値よりも大きな値としたり、通信帯域の要件を持つ通信フローに対しては通信帯域の要件をアプリケーション管理装置２２が設定した値よりも小さな値とすることである。一方、Ｓ１３３での通信要件の更新とは、通信要件を厳しく設定することであり、例えば、伝送遅延の要件を持つ通信フローに対しては伝送遅延の要件をアプリケーション管理装置２２が設定した値よりも小さな値としたり、通信帯域の要件を持つ通信フローに対しては通信帯域の要件をアプリケーション管理装置２２が設定した値よりも大きな値とすることである。
　通信設定作成部５３は、通信要件更新部５２にて更新された通信要件を用いて、車載ネットワーク２０の通信設定を作成する。通信設定の作成は、特許文献１に記載の技術など、任意の公知技術を用いて実施することができる。
　設定部５４は、通信設定作成部５３で作成した通信設定を車載ネットワーク２０へ適用（設定）する。これには、ＮＥＴＣＯＮＦ（Internet Engineering Task Force, Request for Comments: 6241）やＳＮＭＰ（Simple Network Management Protocol; Internet Engineering Task Force, Request for Comments: 3411）など、任意の公知技術を用いて実施することができる。車載ネットワーク２０への通信設定の適用においては、性能取得部６０に対する性能取得条件の設定も行う。つまり、前記の送信元・宛先ＥＣＵ、送信元・宛先アプリケーションなどの組み合わせからなる通信識別情報に対して取得すべき通信性能の情報を設定する。
　通信制御装置２１は、設定部５４による通信設定完了後に、車載ネットワーク２０に対して走行時のアプリケーションに係る通信を模擬した通信テストを実施する。
　以上により、第１の実施例では、通信要件を更新することで挿入された通信フローごとの通信要件に対する通信設定の性能マージンを縮小し、単なる通信設計ではリソース不足により収容できなかった通信フローを収容可能とする。通信優先度１０３の値を、通信フローの車両走行における安全性に対応する値とすることで、車両走行の安全性を確保することができる。特に、第１の実施例では、通信設計を車両の走行前に完了させることで、ネットワーク設定変更による車両の走行安全性を確実に確保することができる。
［第２の実施例］
　次に、図１０および図１１を参照して、本発明による車載ネットワークシステムの第２の実施例を説明する。第２の実施例では、ＳＤＶにおいて車両の走行中にアプリ更新を可能とする場合に必要となる構成を示す。第２の実施例では、車両の走行中に追加されるアプリケーションに対してリアルタイムに通信設定の作成および通信性能の監視を行い、通信性能が通信要件を満たさない通信フローがある場合には、まず通信設定をアプリ追加前の状態に戻し、その後に通信要件を更新して通信設定を再度作成する。
　図１０は、第２の実施例におけるネットワークシステムの構成を表すブロック図である。第１の実施例における構成に加えて、通信制御装置２１に通信設定記憶部５５が追加されている。通信設定記憶部５５では、過去に作成した車載ネットワーク２０の通信設定を記憶し、必要に応じて読み出すことで、過去の通信設定に容易に戻すことを可能とする。
　図１１は、第２の実施例におけるネットワークシステム全体処理フローチャート（特に、通信制御装置２１の全体動作を表すフローチャート）である。第１の実施例と同様の処理ステップには同一の符号を付してある。ネットワークシステム１９は、アプリケーション管理装置２２によるアプリケーション追加Ｓ２００を契機としてその動作を開始する。次にＳ１０１にて、通信制御装置２１が、車載ネットワーク２０用の通信設定を作成し、車載ネットワーク２０へ適用する。続くＳ２０１では、実際に車載ネットワーク２０にて行われる通信に対してアプリケーション毎の通信性能を測定する。その後、Ｓ１０４にて、通信制御装置２１が、車載ネットワーク２０が測定したアプリケーション毎の通信性能を取得する。Ｓ１０５にて、通信制御装置２１が、取得したアプリケーション毎の通信性能と記憶している通信要件をアプリケーションの通信ごとに比較し、通信要件を満たさない通信がある場合は（Ｙｅｓ）、さらにＳ２０２にて、通信要件を満たさない通信がアプリケーション管理装置２２によって新規に追加されたアプリケーションによる新規通信であるかどうかを確認する。通信要件を満たさない通信が新規通信である場合（Ｓ２０２のＹｅｓ）、Ｓ２０３にて、通信制御装置２１が、車載ネットワーク２０の通信設定を、Ｓ２００におけるアプリケーション追加前の通信設定に切り戻す。すなわち、通信制御装置２１が、新規通信以外の通信が通信要件を満たした時点での過去の通信設定を通信設定記憶部５５より取得し、通信設定記憶部５５より取得した過去の通信設定を車載ネットワーク２０に対して設定する（過去の通信設定に容易に戻す）。切り戻し完了後または切り戻しと同時に、第１の実施例と同様に、Ｓ１０６にて、通信制御装置２１が通信要件を更新し、Ｓ１０１へと戻る。Ｓ２０２にて、通信要件を満たさない通信が新規通信でない場合（Ｓ２０２のＮｏ）、通信設定の切り戻しを行わずにＳ１０１へと戻る。その後は、車載ネットワーク２０用の通信設定を再度作成するなど、通信設定の作成以降を再実施する。Ｓ１０５にて、通信要件を満たさない通信がない場合（Ｎｏ）、処理を終了する。
　通信制御装置２１の各機能ブロックの動作は、第２の実施例にて追加した通信設定記憶部５５を除き、第１の実施例と同様である。
　第２の実施例により、車両走行中のアプリケーション追加時においても、車両の走行安全性を確保しながら、単なる通信設計ではリソース不足により収容できなかった通信フローを収容可能とする。
［第３の実施例］
　次に、図１２を参照して、本発明による車載ネットワークシステムの第３の実施例を説明する。第３の実施例では、車載ネットワーク２０中での突発的な通信状態変化に追従して通信設定を更新するために、通信状態をリアルタイムに監視して通信要件を更新することで通信設定を更新し、車両の走行安全性に影響の大きいアプリケーションの通信を確保する。さらに、通信状態が回復すれば通信設定を元に戻すことで、車両の走行安全性に影響の大きいアプリケーション以外の通信の可用性を向上する。
　第３の実施例におけるネットワークシステムの構成は、第１の実施例と同様である。第３の実施例では、図１２に示す全体処理フローチャートの動作により、ネットワークシステムの各機能ブロックの動作を変えずとも上記目的を達することができる。
　図１２では、同図に示すネットワークシステムの動作を短時間（例えば、車載システムの最短制御周期である１０ミリ秒程度）で動作させる。まずＳ２０１にて、車載ネットワーク２０がアプリケーション毎の通信性能を測定する。次にＳ１０４にて、通信制御装置２１が、車載ネットワーク２０が測定したアプリケーション毎の通信性能を取得する。続いてＳ３００にて、通信制御装置２１は、取得した通信性能が前回取得した通信性能と比較して変化があるかどうかを判定する。変化がない場合（Ｎｏ）は、今周期の動作を終了する。変化がある場合（Ｙｅｓ）、Ｓ１０５にて、通信制御装置２１が、通信要件を満たさない通信があるかどうかを判定する。通信要件を満たさない通信がある場合（Ｓ１０５にてＹｅｓ）、つまり、前周期まで通信要件を満たさない通信があったが今周期には通信要件を満たさない通信があったために通信状態変化として通信性能劣化が発生したと判断できる場合、Ｓ１０６にて、通信制御装置２１が通信要件を更新し、Ｓ１０１を実施する。通信要件を満たさない通信が無かった場合（Ｓ１０５にてＮｏ）、つまり、前周期では通信要件を満たさない通信があったが今周期では通信要件を満たさない通信がないために（通信要件の更新によって）通信性能劣化が解消して通信が復旧したと判断できる場合、Ｓ３０１にて、通信制御装置２１が通信要件を元（言い換えれば、更新前の通信要件）に戻し、Ｓ１０１を実施する。そしてＳ１０１では、通信制御装置２１が、車載ネットワーク２０用の通信設定を作成し、車載ネットワーク２０へ適用する。本フローはＳ１０１にて終了し、次周期の実行を待機する。
　第３の実施例により、車載ネットワーク２０中での突発的な通信状態変化が発生しても、車両の走行安全性に影響の大きい通信の通信性能劣化を防ぎ、車両の走行安全性を向上することができる。
［第４の実施例］
　次に、図１３～図１５を参照して、本発明による車載ネットワークシステムの第４の実施例を説明する。第４の実施例では、ＳＤＶにて追加されたアプリケーションの通信において、その通信要件に対して作成した通信設定を記憶し、その後に追加されるアプリケーションの通信要件に対して過去に作成した類似の通信要件に対する通信設定を検索して再利用することにより、通信設定の作成を効率化する。ここで類似の通信要件とは、例えば、追加されるアプリケーションにおける各通信要件の値に対して、過去に通信設定を作成したアプリケーションにおける通信要件が事前に設定した誤差範囲内（例えば５％以内）となる場合である。なお、アプリケーションによって通信要件のうち一部のみを重視する場合、例えば通信帯域を重視するが遅延時間を重視しない場合などは、重視する通信要件に対して事前に設定した誤差範囲内となる場合などと、検索対象の通信要件を限定してもよい。
　第４の実施例におけるネットワークシステムの構成を図１３に示す。第４の実施例では、第２の実施例と同様に通信設定記憶部５５を有するが、その接続関係が異なる。通信設定記憶部５５は、通信設定作成部５３より通信要件と通信要件に対して作成した通信設定の情報を受信し、記憶する。そして、通信設定記憶部５５は、通信要件更新部５２からの参照に対して通信要件に対して過去に作成した通信設定を提供する。また、ネットワークシステム１９の追加の構成として外部通信装置２３を有することができる。通信設定記憶部５５は、外部通信装置２３を介して記憶した通信要件と通信設定をクラウド等の外部に送信して保存し、さらにクラウド等の外部より類似の通信要件に対する通信設定を検索して受信し、自装置での通信設定の作成に使用することができる。この構成により、ある車両において作成した通信要件に対する通信設定を外部に送信して他の車両と共有し、他の車両においても利用することができる。
　図１４に、通信設定記憶部５５における通信設定記憶テーブル２００の概要を示す。通信設定記憶テーブル２００は、アプリケーション管理装置２２より受信した元の通信要件２０１、通信制御装置２１にて更新した更新後の通信要件２０２、および更新後の通信要件２０２に対する通信設定２０３を保持する。
　図１５に、第４の実施例における通信要件更新部５２のフローチャートを示す。通信要件更新部５２は、まずＳ１３０にて、通信性能が通信要件を満たさない第一の通信があるかどうかを判定する。第一の通信がない場合（Ｎｏ）、処理を終了する。第一の通信がある場合（Ｙｅｓ）、Ｓ１３１に進む。Ｓ１３１では、前記第一の通信よりも優先度が低く、かつ通信要件を満たす第二の通信があるかどうかを判定する。第二の通信がある場合（Ｓ１３１にてＹｅｓ）、Ｓ４００にて、通信設定記憶部５５より第二の通信の通信要件に類似する通信要件の有無を検索する。検索の結果、第二の通信の通信要件に類似する通信要件がある場合（Ｓ４００にてＹｅｓ）、Ｓ４０２にて、通信設定記憶部５５より第二の通信の通信要件に類似する通信要件に対する通信設定を取得してこれを使用する。検索の結果、第二の通信の通信要件に類似する通信要件がなかった場合（Ｓ４００にてＮｏ）、Ｓ１３２にて、第１の実施例と同様に（第一の通信ではなく）第二の通信の通信要件を更新する。
　第二の通信がない場合（Ｓ１３１にてＮｏ）、Ｓ４０１にて、通信設定記憶部５５より第一の通信の通信要件に類似する通信要件の有無を検索する。検索の結果、第一の通信の通信要件に類似する通信要件がある場合（Ｓ４０１にてＹｅｓ）、Ｓ４０３にて、通信設定記憶部５５より第一の通信の通信要件に類似する通信要件に対する通信設定を取得してこれを使用する。検索の結果、第一の通信の通信要件に類似する通信要件がなかった場合（Ｓ４０１にてＮｏ）、Ｓ１３３にて、第１の実施例と同様に第一の通信の通信要件を更新する。
　通信要件更新部５２にて通信設定記憶部５５より過去の通信設定を取得した場合は、通信設定作成部５３は何も行わない。
　第４の実施例により、通信設定の作成を効率化し、ＳＤＶにおけるアプリケーション追加時に、アプリケーション追加から動作開始までの時間を短縮することができる。
［第１～第４の実施例のまとめ］
　以上に説明したように、本実施例による通信制御装置２１は、複数の通信装置（ＥＣＵ）を含むネットワーク（車載ネットワーク２０）の通信を制御する通信制御装置２１であって、複数のアプリケーションに係る通信に関して、前記通信の通信性能に対する要件である通信要件、および、前記通信が前記ネットワークを含むシステムの動作に与える影響の度合いに応じて定められた優先度を、前記アプリケーション毎に記憶する通信要件記憶部５０と、前記通信（の通信性能）が前記通信要件を満たすか否か（通信要件充足状態）を判断する通信性能監視部５１と、前記通信性能監視部５１により前記通信要件を満たさないと判断された第一の通信の優先度および前記通信要件を満たすと判断された他の通信の優先度に基づいて、前記第一の通信に対する前記通信要件を更新する通信要件更新部５２と、前記通信要件更新部５２により更新された前記通信要件に基づいて、前記ネットワークに対する通信設定を作成する通信設定作成部５３と、前記通信設定作成部５３により作成された前記通信設定を前記ネットワークに対して設定する設定部５４と、を備える。
　また、本実施例による通信制御装置２１において、前記通信要件更新部５２は、前記第一の通信よりも優先度が低く、かつ前記通信要件を満たすと判断された第二の通信に対し、前記第二の通信の前記通信要件を更新する（図９のＳ１３２）。
　また、本実施例による通信制御装置２１は、前記アプリケーションの動作前に、前記通信設定作成部５３により作成された前記通信設定を用いて前記アプリケーションの通信を行い（通信テスト）、前記通信性能監視部５１により前記通信の通信性能を取得し、前記取得した前記通信の通信性能が前記通信要件を満たす場合には前記アプリケーションの動作を開始し（図５のＳ１０７）、前記取得した前記通信の通信性能が前記通信要件を満たさない場合には前記アプリケーションの動作を開始せず、前記通信要件を更新して前記ネットワークに対する前記通信設定を再度作成する（図５のＳ１０６以降）。
　また、本実施例による通信制御装置２１は、過去に作成した前記通信設定を記憶する通信設定記憶部５５をさらに有し、前記通信要件更新部５２は、前記通信要件を満たさないと判断された前記第一の通信が新規に追加されたアプリケーションに関する通信である場合に、前記新規に追加されたアプリケーションに関する通信以外の通信が前記通信要件を満たした時点での過去の通信設定を前記通信設定記憶部５５より取得し、前記設定部５４は、前記通信設定記憶部５５より取得した過去の通信設定を前記ネットワークに対して設定する（第２の実施例）。
　また、本実施例による通信制御装置２１において、前記通信性能監視部５１はさらに、通信性能劣化をリアルタイムで監視し、前記通信要件更新部５２は、前記通信性能劣化が発生した場合に前記通信要件を更新し、前記通信性能劣化が解消した場合に前記通信要件を元に戻す（第３の実施例）。
　また、本実施例による通信制御装置２１は、前記通信要件に対して過去に作成した前記通信設定を記憶する通信設定記憶部５５をさらに有し、前記通信要件更新部５２は、前記通信設定記憶部５５より、前記通信要件に類似の通信要件を検索し、前記通信要件に類似の通信要件が見つかった場合は、前記通信設定記憶部５５より前記通信要件に類似の通信要件に対する通信設定を取得し、前記設定部５４は、前記通信設定記憶部５５より取得した通信設定を用いて前記ネットワークを設定する（第４の実施例）。
　また、本実施例による通信制御装置２１において、前記通信設定記憶部５５は、記憶した前記通信要件および前記通信設定を外部に送信して他の通信制御装置と共有し、（例えば、前記通信要件に類似の通信要件が見つからなかった場合は）前記外部より前記他の通信制御装置にて記憶した前記通信要件および前記通信設定を受信し、自装置での前記通信設定の作成に使用する（第４の実施例）。
　また、本実施例による通信制御装置２１において、前記通信要件更新部５２は、前記通信性能監視部５１により前記通信要件を満たさないと判断された第一の通信の優先度および前記通信要件を満たすと判断された他の通信の優先度に基づいて、前記第一の通信の前記通信要件を更新するか否か、あるいは、前記他の通信の前記通信要件を更新するか否か、を判断する。
　また、本実施例による通信制御装置２１において、前記通信要件更新部５２は、前記第一の通信よりも優先度が低く、かつ前記通信要件を満たすと判断された第二の通信がある場合、前記第二の通信の前記通信要件を更新し、前記第一の通信よりも優先度が低く、かつ前記通信要件を満たすと判断された第二の通信がない場合、前記第一の通信の前記通信要件を更新する。
　また、本実施例によるネットワークシステム１９は、前述の通信制御装置２１を有するネットワークシステム１９であって、前記アプリケーションを追加（配信）するアプリケーション管理装置２２と、前記アプリケーションが通信を行うための通信路であって複数の通信装置（ＥＣＵ）から構成されるネットワーク（車載ネットワーク２０）と、をさらに有し、前記ネットワーク（車載ネットワーク２０）を構成する前記通信装置（ＥＣＵ）内に、前記アプリケーション毎の通信性能を取得する性能取得部６０をさらに有する。
　また、本実施例によるネットワークシステム１９において、前記優先度は、前記アプリケーション管理装置２２にて前記アプリケーションの前記通信装置（ＥＣＵ）への追加前に決定される。
　また、本実施例によるネットワークシステム１９において、前記優先度は、前記通信制御装置２１にて決定される。
　すなわち、本実施による通信制御装置２１は、車両の走行安全性へのアプリケーションの影響度に応じて通信要件を更新し、通信設定の更新、切り戻し等の管理を行う。
　本実施例によれば、通信装置であるＥＣＵへのアプリ配置の際に、ＥＣＵ内部のリソースおよびＥＣＵ間の通信リソースを考慮した配置を行い、アプリの実行性能および通信性能を確保することによりアプリの安定的な動作を確保することで、車両の走行安全性を確保しつつ、ＳＤＶにおけるアプリケーション追加を可能とする通信制御装置およびネットワークシステムを提供することができる。
　なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
　また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
１　車両
２　ゲートウェイ
３　ドメインＥＣＵ
４　センサ
５　アクチュエータ
６　バス
７　ＴＣＵ
８　セントラルＥＣＵ
９　ゾーンＥＣＵ
１０　共有バス
１１　ＣＰＵ
１２　メモリ
１３　ネットワークスイッチ
１９　ネットワークシステム
２０　車載ネットワーク
２１　通信制御装置
２２　アプリケーション管理装置
２３　外部通信装置
３０　アプリケーション
３１　ミドルウェア
３２　ハードウェア
１００　通信要件記憶テーブル
２００　通信設定記憶テーブル

Claims (14)

  1. 　複数の通信装置を含むネットワークの通信を制御する通信制御装置であって、
    　複数のアプリケーションに係る通信に関して、前記通信の通信性能に対する要件である通信要件、および、前記通信が前記ネットワークを含むシステムの動作に与える影響の度合いに応じて定められた優先度を、前記アプリケーション毎に記憶する通信要件記憶部と、
    　前記通信が前記通信要件を満たすか否かを判断する通信性能監視部と、
    　前記通信性能監視部により前記通信要件を満たさないと判断された第一の通信の優先度および前記通信要件を満たすと判断された他の通信の優先度に基づいて、前記第一の通信に対する前記通信要件を更新する通信要件更新部と、
    　前記通信要件更新部により更新された前記通信要件に基づいて、前記ネットワークに対する通信設定を作成する通信設定作成部と、
    　前記通信設定作成部により作成された前記通信設定を前記ネットワークに対して設定する設定部と、を備えることを特徴とする通信制御装置。
  2. 　請求項１に記載の通信制御装置であって、
    　前記通信要件更新部は、前記第一の通信よりも優先度が低く、かつ前記通信要件を満たすと判断された第二の通信に対し、前記第二の通信の前記通信要件を更新することを特徴とする通信制御装置。
  3. 　請求項１に記載の通信制御装置であって、
    　前記アプリケーションの動作前に、前記通信設定作成部により作成された前記通信設定を用いて前記アプリケーションの通信を行い、前記通信性能監視部により前記通信の通信性能を取得し、
    　前記取得した前記通信の通信性能が前記通信要件を満たす場合には前記アプリケーションの動作を開始し、
    　前記取得した前記通信の通信性能が前記通信要件を満たさない場合には前記アプリケーションの動作を開始せず、前記通信要件を更新して前記ネットワークに対する前記通信設定を再度作成することを特徴とする通信制御装置。
  4. 　請求項１に記載の通信制御装置であって、
    　過去に作成した前記通信設定を記憶する通信設定記憶部をさらに有し、
    　前記通信要件更新部は、前記通信要件を満たさないと判断された前記第一の通信が新規に追加されたアプリケーションに関する通信である場合に、前記新規に追加されたアプリケーションに関する通信以外の通信が前記通信要件を満たした時点での過去の通信設定を前記通信設定記憶部より取得し、
    　前記設定部は、前記通信設定記憶部より取得した過去の通信設定を前記ネットワークに対して設定することを特徴とする通信制御装置。
  5. 　請求項１に記載の通信制御装置であって、
    　前記通信性能監視部はさらに、通信性能劣化をリアルタイムで監視し、
    　前記通信要件更新部は、前記通信性能劣化が発生した場合に前記通信要件を更新し、前記通信性能劣化が解消した場合に前記通信要件を元に戻すことを特徴とする通信制御装置。
  6. 　請求項１に記載の通信制御装置であって、
    　前記通信要件に対して過去に作成した前記通信設定を記憶する通信設定記憶部をさらに有し、
    　前記通信要件更新部は、前記通信設定記憶部より、前記通信要件に類似の通信要件を検索し、前記通信要件に類似の通信要件が見つかった場合は、前記通信設定記憶部より前記通信要件に類似の通信要件に対する通信設定を取得し、
    　前記設定部は、前記通信設定記憶部より取得した通信設定を用いて前記ネットワークを設定することを特徴とする通信制御装置。
  7. 　請求項６に記載の通信制御装置であって、
    　前記通信設定記憶部は、記憶した前記通信要件および前記通信設定を外部に送信して他の通信制御装置と共有し、前記外部より前記他の通信制御装置にて記憶した前記通信要件および前記通信設定を受信し、自装置での前記通信設定の作成に使用することを特徴とする通信制御装置。
  8. 　請求項１に記載の通信制御装置であって、
    　前記通信要件更新部は、前記通信性能監視部により前記通信要件を満たさないと判断された第一の通信の優先度および前記通信要件を満たすと判断された他の通信の優先度に基づいて、前記第一の通信の前記通信要件を更新するか否か、あるいは、前記他の通信の前記通信要件を更新するか否か、を判断することを特徴とする通信制御装置。
  9. 　請求項１に記載の通信制御装置であって、
    　前記通信要件更新部は、前記第一の通信よりも優先度が低く、かつ前記通信要件を満たすと判断された第二の通信がある場合、前記第二の通信の前記通信要件を更新し、前記第一の通信よりも優先度が低く、かつ前記通信要件を満たすと判断された第二の通信がない場合、前記第一の通信の前記通信要件を更新することを特徴とする通信制御装置。
  10. 　請求項１に記載の通信制御装置を有するネットワークシステムであって、
    　前記アプリケーションを追加するアプリケーション管理装置と、
    　前記アプリケーションが通信を行うための通信路であって複数の通信装置から構成されるネットワークと、をさらに有し、
    　前記ネットワークを構成する前記通信装置内に、前記アプリケーション毎の通信性能を取得する性能取得部をさらに有することを特徴とするネットワークシステム。
  11. 　請求項１０に記載のネットワークシステムであって、
    　前記優先度は、前記アプリケーション管理装置にて前記アプリケーションの前記通信装置への追加前に決定されることを特徴とするネットワークシステム。
  12. 　請求項１０に記載のネットワークシステムであって、
    　前記優先度は、前記通信制御装置にて決定されることを特徴とするネットワークシステム。
  13. 　請求項１０に記載のネットワークシステムであって、
    　前記ネットワークシステムは車両に搭載され、
    　前記車両は前記車両を駆動するためのアクチュエータをさらに備え、
    　前記アクチュエータの制御に関する通信以外の優先度が、前記アクチュエータの制御に関する通信の優先度よりも低く設定されることを特徴とするネットワークシステム。
  14. 　請求項１３に記載のネットワークシステムであって、
    　前記車両は前記車両周辺の走行環境を認識するためのセンサをさらに備え、
    　前記アクチュエータの制御に関する通信の優先度よりも、前記センサのデータに関する通信の優先度が低く設定され、
    　前記アクチュエータの制御に関する通信および前記センサのデータに関する通信以外の通信の優先度が、前記アクチュエータの制御に関する通信および前記センサのデータに関する通信の優先度よりも低く設定されることを特徴とするネットワークシステム。
PCT/JP2025/017060 2024-06-18 2025-05-09 通信制御装置およびネットワークシステム Pending WO2025263148A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2024097855A JP2026000533A (ja) 2024-06-18 2024-06-18 通信制御装置およびネットワークシステム
JP2024-097855 2024-06-18

Publications (1)

Publication Number Publication Date
WO2025263148A1 true WO2025263148A1 (ja) 2025-12-26

Family

ID=98212822

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2025/017060 Pending WO2025263148A1 (ja) 2024-06-18 2025-05-09 通信制御装置およびネットワークシステム

Country Status (2)

Country Link
JP (1) JP2026000533A (ja)
WO (1) WO2025263148A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005130276A (ja) * 2003-10-24 2005-05-19 Kyocera Mita Corp 通信端末装置および通信調整装置
JP2022088980A (ja) * 2020-12-03 2022-06-15 株式会社デンソー 通信制御装置、通信制御方法、及び中継サーバ

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005130276A (ja) * 2003-10-24 2005-05-19 Kyocera Mita Corp 通信端末装置および通信調整装置
JP2022088980A (ja) * 2020-12-03 2022-06-15 株式会社デンソー 通信制御装置、通信制御方法、及び中継サーバ

Also Published As

Publication number Publication date
JP2026000533A (ja) 2026-01-06

Similar Documents

Publication Publication Date Title
JP7529321B2 (ja) 車両アップグレード方法および装置
US12155734B2 (en) Universal software communication bus
US11314501B2 (en) On-board update device, on-board update system, update process method, and update process program
CN112136106B (zh) 电子控制装置以及存储介质
JP2018120422A (ja) 車載通信システム、ドメインマスタ、及びファームウェア更新方法
Cakır et al. A QoS aware approach to service-oriented communication in future automotive networks
EP3945418B1 (en) Server, software updating device, vehicle, software updating system, control method, and non-transitory storage medium
CN113810270A (zh) 一种实现车载控制器局域网soa化的方法及装置
CN111742294A (zh) 传输用于至少一个机动车控制装置的至少一个更新包的系统以及方法
CN112583691A (zh) 中继装置及外部装置
Zhang et al. Schedule management framework for cloud-based future automotive software systems
US20110188520A1 (en) Method for operating a time-controlled bus system
CN117234187A (zh) 车辆的诊断方法、车辆、设备及存储介质
JP7845538B2 (ja) 車載制御装置および機器設定方法
JP2026000533A (ja) 通信制御装置およびネットワークシステム
CN116982024A (zh) 用于自动更新车辆的控制单元的通信单元的计算机实现的方法和设备
Takrouni et al. A new methodology for implementing the data distribution service on top of gigabit ethernet for automotive applications
JP7576134B2 (ja) 車両におけるネットワーク帯域幅管理のためのシステムと方法
CN118646747A (zh) 一种文件下载方法、装置以及车辆
Klein et al. Carisma: Car-integrated service mesh architecture
WO2024111175A1 (ja) ネットワークシステム、およびネットワーク管理方法
Ballesteros et al. SOAcom: Designing Service communication in adaptive automotive networks
CN117707570A (zh) 车载信息娱乐系统升级方法及装置
US20250211319A1 (en) Relay device, communication network system, relay method, and storage medium storing computer program
WO2024247884A1 (ja) 通信設計装置、通信設計方法

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: 25830274

Country of ref document: EP

Kind code of ref document: A1