Communication control device and network system

Abstract

Provided are a communication control device and a network system capable of increasing the number of communications that can be accommodated on a network while ensuring the traveling safety of a vehicle, in an SDV. According to the present invention, with regard to communications relating to a plurality of applications: a communication requirement, which is a requirement for the communication performance of communication, and a priority determined in accordance with the degree of impact of the communications on the operation of a system including a network, are stored for each application; a determination is made as to whether (the communication performance of) the communication satisfies the communication requirement (communication requirement satisfaction state); and, on the basis of the priority of a first communication determined not to satisfy the communication requirement and the priority of another communication determined to satisfy the communication requirement, the communication requirement for the first communication is updated.

Description

Communication control device and network system

[0001] The present invention relates to a communication control device and a network system, and more particularly to an in-vehicle communication control device that controls an in-vehicle network and an in-vehicle network system equipped with the same.

[0002] Autonomous driving and safe driving support technologies are advancing by leaps and bounds, and will continue to evolve in the future. Automakers are not only applying these technological advances to new models, but are also considering applying them to vehicles already on the market. One technology for this is over-the-air (OTA) update technology. Vehicles whose behavior can be changed by software, such as by installing software via OTA, are called software-defined vehicles (SDVs).

[0003] A vehicle system is composed of multiple electronic control units (ECUs) connected via a network. Here, ECU is used as a general term for sensors such as cameras, actuators that operate the engine and steering, and devices that perform calculations for control. The ECU sends and receives data via the in-vehicle network and obtains information for vehicle control by calculating the data using apps. Sending and receiving data places a load on the in-vehicle network, but the load on the in-vehicle network varies depending on the location of the apps.

[0004] To ensure the functionality of in-vehicle applications, it is necessary not only to secure processing time through application scheduling, but also to secure performance through communication scheduling for communication functions.Communication scheduling requires a network design that utilizes a Quality of Service (QoS) function that adjusts the data transmission priority of network switches, and a Time-Sensitive Network (TSN) function that controls the transmission timing and transmission bandwidth of transmitted data.

[0005] In network design, a method for designing network parameters based on communication requirements such as communication delay required by an application is disclosed, for example, in Patent Document 1. Patent Document 1 discloses a method for specifying, in a wireless communication system, traffic to be transmitted in each time slot based on the counter value, which is a counter value that takes into consideration, for example, transmission timing and allowable delay amount for traffic that each communication device is about to transmit.

[0006] Japanese Patent Application Laid-Open No. 2020-155857

[0007] In the technology described in Patent Document 1, variable-length packet transmission timing is scheduled for fixed-length time slots. Therefore, the time slots are longer than the maximum length of variable-length packets, and therefore, in principle, there are periods when packets are not transmitted. In other words, because communication performance is ensured by providing a margin for individual communications, communication bandwidth utilization cannot be improved. As a result, the number of applications that can be accommodated in SDVs reaches a plateau, which could prevent users from installing desired apps, especially in low-priced ECUs installed in mass-market cars. Furthermore, when reducing the communication setting margin in the in-vehicle network to increase the number of communications that can be accommodated in the network and enable app installation (addition) via SDVs, the degree to which applications affect vehicle driving safety varies. For example, communications related to vehicle driving control, such as 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 available. Therefore, simply increasing the number of applications used in SDVs could affect vehicle driving safety.

[0008] Therefore, an object of the present invention is to provide a communication control device and a network system that enable the addition of applications to an SDV while ensuring the driving safety of the vehicle.

[0009] In order to solve the above problem, the communication control device of the present invention is a communication control device that controls communication of a network including a plurality of communication devices, and is equipped with a communication requirement memory unit that stores, for each application, communication requirements that are requirements for the communication performance of the communication, and a priority determined according to the degree of impact that the communication has on the operation of a system including the network, for communications related to a plurality of applications; a communication performance monitoring unit that determines whether the communication satisfies the communication requirements; a communication requirement 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 another communication that is 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 to the network.

[0010] According to the present invention, when placing an app in an ECU, which is a communication device, 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 app, stable operation of the app is ensured, thereby providing a communication control device and network system that enables the addition of applications in an SDV while ensuring the driving safety of the vehicle.

[0011] Problems, configurations, and effects other than those described above will become apparent from the following description of the embodiments.

[0012] 1 is a diagram of an electrical and electronic architecture (architecture by domain) inside a vehicle equipped with an in-vehicle network system according to the present invention. 2 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. 3 is a hardware configuration diagram of a domain ECU. 4 is a hardware configuration diagram of a zone ECU. 5 is a hardware configuration diagram of a gateway. 6 is a hardware configuration diagram of a central ECU. 7 is a configuration diagram of an ECU and software executed on the ECU. 8 is a functional block diagram of a network system according to a first embodiment. 9 is a flowchart showing the overall operation of a communication control device 21 according to the first embodiment. 100 is stored in a communication requirement storage unit 50. 11 is a flowchart showing the operation of a communication performance monitoring unit 51. 12 is a flowchart showing the operation of a communication requirement update unit 52. 13 is a flowchart showing details of S122 of the operation of the communication requirement update unit 52. 14 is a functional block diagram of a network system according to a second embodiment. 15 is a flowchart showing the overall operation of a communication control device 21 according to the second embodiment. 16 is a flowchart showing the overall operation of a communication control device 21 according to a third embodiment. 17 is a functional block diagram of a network system according to a fourth embodiment. 18 is a flowchart showing the overall operation of a communication setting storage table 200 stored in a communication setting storage unit 55. 10 is a flowchart showing the operation of a communication requirement update unit 52 in the fourth embodiment.

[0013] First Embodiment A first embodiment of an in-vehicle network system according to the present invention will now be described with reference to FIGS. 1A to 9. FIG.

[0014] 1A and 1B are diagrams showing the electrical and electronic architecture inside 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.

[0015] FIG. 1A is a diagram showing the logical configuration of an electrical and electronic architecture called a domain architecture. This is a system in which ECUs within a vehicle 1 are classified into functional divisions called domains, and ECUs belonging to the same domain are systematically connected. Each domain is provided with a domain ECU 3a to 3d (hereinafter collectively referred to as domain ECU 3) that oversees that domain. Furthermore, the domain ECUs 3 are interconnected via a gateway 2 to enable communication between domains. Examples of domains include an ADAS (Advanced Driver Assistance System) domain that manages safe driving assistance, a PT / CH (Power Train / Chassis) domain that controls the vehicle's longitudinal and lateral movement, a BODY domain that controls electrical equipment such as power windows, and an Infotainment domain that controls navigation and audio. Each domain is equipped with an ADAS ECU 3a, a PT / CH ECU 3b, a BODY ECU 3c, and an Infotainment ECU 3d (hereinafter collectively referred to as 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. In some cases, multiple ECUs 4 and 5 are connected to a single bus 6. In addition, the gateway 2 is connected to a TCU (Telematics Control Unit) 7 that communicates with servers outside the vehicle, clouds, etc. via a wireless network.

[0016] The performance and functional requirements of domain ECUs may differ depending on the domain. For example, ADAS ECUs and Infotainment ECUs handle large volumes of data such as video, so they use hardware with high processing performance. On the other hand, PT / CH ECUs use highly reliable hardware to ensure safe direct connection.

[0017] FIG. 1B illustrates the physical configuration of an electrical and electronic architecture known as a zone architecture. This architecture classifies ECUs 4 and 5 according to their spatial location within the vehicle 1 and connects them to zone ECUs 9a to 9d (hereinafter collectively referred to as zone ECUs 9) that oversee these locations. The architecture includes one or more zone ECUs 9, a central ECU 8 that connects to the zone ECUs 9 and executes multiple applications across multiple domains, and sensors 4 and actuators 5 connected to the zone ECUs 9. As the name suggests, the zone ECUs 9 are positioned in positions corresponding to the front, rear, left, right, and right sides within the vehicle 1 and are connected to sensors 4, actuators 5, or both that are located near their installation positions. Furthermore, the zone ECUs 9 are connected to other zone ECUs 9 via a shared bus 10 that uses a common communication method between domains. The common communication method is assumed to be a switching network using Ethernet (registered trademark). Additionally, a TCU 7 is connected. The TCU 7 may be connected to the central ECU 8 or any zone ECU 9, but FIG. 1B illustrates an example in which the TCU 7 is connected to the central ECU 8.

[0018] 2A to 2D respectively show the hardware configurations of the domain ECU 3, the zone ECU 9, the gateway 2, and the central ECU 8. The thick lines in Fig. 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.

[0019] 2A shows the hardware configuration of the domain ECU 3 in the domain-specific architecture (FIG. 1A). The domain ECU 3 includes a CPU (Central Processing Unit) 11 for processing information received from the sensors 4 and actuators 5 or the gateway 2, and a memory 12 for storing data used for calculations by the CPU 11. A bus for connecting to the gateway 2 and a bus for connecting to the sensors 4 and actuators 5 extend from the CPU 11.

[0020] 2B shows the hardware configuration of a zone ECU 9 in the zone architecture (FIG. 1B). The zone ECU 9 includes a network switch 13 that accommodates 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 includes a CPU 11 that processes 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 a memory 12. If the sensors 4 and actuators 5 support a common communication method, the memory 12 may be directly connected 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.

[0021] 2C and 2D show the hardware configurations of the gateway 2 in the domain architecture (FIG. 1A) and the central ECU 8 in the zone architecture (FIG. 1B). These 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 the zone ECU 9.

[0022] FIG. 3 is a diagram showing the software configuration executed in a typical ECU. Each ECU, such as the domain ECU 3, gateway 2, zone ECU 9, or central ECU 8, includes hardware 32, which includes a CPU (Central Processing Unit) or MCU (Micro-Controller Unit), memory, and peripheral circuits for executing the software; middleware 31 (which may include an operating system, etc.) that runs on the hardware 32 and provides functions commonly used by various pieces of software; and an application 30 that implements functions necessary for controlling vehicle operation. Unless otherwise specified, the various functional blocks in this embodiment are implemented on the middleware 31. However, the effects obtained will not change even if some or all of the various functions in this embodiment are implemented as the hardware 32 or the application 30.

[0023] FIG. 4 is a functional block diagram of a network system according to 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 FIG. 1. The network system 19 in this embodiment comprises an in-vehicle network 20, a communication control device 21, and an application management device 22. These devices may be implemented as separate 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 or outside the vehicle. Examples of devices located outside the vehicle include an OTA server for software updates via OTA and rewriting tools for ECU rewriting at a dealer. The in-vehicle network 20 is a communication path for applications to communicate, and is configured by connecting multiple communication devices (ECUs) (such as the domain ECU 3, gateway 2, zone ECU 9, and central ECU 8) to transfer data from a source application to a destination application. The communication control device 21 controls communication of 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 updating 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). In addition, the application management device 22 transfers data related to application communication to the communication control device 21 as application metadata accompanying the application data itself. Here, the data related to application communication in this embodiment refers to all the data shown in FIG. 6, which will be described later.

[0024] 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 FIG. 5 (particularly the flowchart showing the overall operation of the communication control device 21). First, when the vehicle starts up and the network system begins its operation, steps S100 to S107 are performed, and the vehicle becomes ready to travel after completion. In S100, 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. Next, 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. In S102, the communication control device 21 performs a communication test on the in-vehicle network 20, simulating communication related to the application while the vehicle is traveling. In response to this communication test, in S103, the in-vehicle network 20 measures the communication performance of each application. Thereafter, in S104, the communication control device 21 acquires the communication performance of each application measured by the in-vehicle network 20. In S105, 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. Thereafter, the process returns to S101, and the process from the creation of the communication settings onwards is carried out again, for example, by creating the communication settings for the in-vehicle network 20 again. In S105, if there is no communication that does not satisfy the communication requirements (No), 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.

[0025] FIG. 4 also shows a functional block diagram of the communication control device 21 and the in-vehicle network 20 for implementing the process shown in FIG. 5 . The communication control device 21 further includes a communication requirement storage unit 50, a communication performance monitoring unit 51, a communication requirement update unit 52, a communication setting creation unit 53, and a setting unit 54. Each ECU included in the in-vehicle network 20 is provided with performance acquisition units 60a to 60c (hereinafter collectively referred to as performance acquisition unit 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, and the like. A communication flow can be identified by communication identification information, which is a combination of, for example, source and destination ECUs, source and destination applications, and the like. The performance acquisition unit 60 holds and stores the communication performance for each communication identification information and transmits it to the communication control device 21.

[0026] The communication requirement storage unit 50 stores communication requirements for an application based on metadata related to the application distributed from the application management device 22. The communication requirements are requirements for the communication performance of communication related to the application, including requirements for transmission delay time, communication bandwidth, packet loss rate, jitter, etc. In this embodiment, the communication requirements are communication delay requirements for transmission delay time and communication bandwidth requirements for communication bandwidth. FIG. 6 shows a communication requirement storage table 100 stored in the communication requirement storage unit 50. The communication requirement storage table 100 (also referred to as the application requirement storage table 100) stores, for each combination of a source 101 and a destination 102, which are communication identification information (i.e., for each application), information on communication parameters such as a communication priority 103, a communication cycle time 104, and a packet length 105, as well as information on communication requirements such as a transmission delay requirement 106 and a communication bandwidth requirement 107.

[0027] The communication priority 103 is set according to the degree of influence that communication has on the operation of a 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 driving, thereby ensuring the safety of vehicle driving. For example, a high priority ("3" in FIG. 6) is set for communications related to vehicle driving control, such as engine / motor, brakes, and steering, a medium priority ("2" in FIG. 6) is set for communications related to sensor data for recognizing the driving environment around the vehicle, and a low priority ("1" in FIG. 6) is set for communications related to information and entertainment systems, such as audio and video. In other words, the vehicle 1 equipped with this network system includes actuators for driving the vehicle and sensors for recognizing the driving environment around the vehicle. 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. Whether the communication flow is for driving control, sensor data, or information / entertainment communication can be determined by referring to 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.

[0028] 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). FIG. 7 shows a flowchart of the communication performance monitoring unit 51. This shows details of S104 in the overall processing flowchart of FIG. 5. First, in S110, the communication performance monitoring unit 51 acquires communication requirements for each communication flow from the communication requirement storage unit 50. In particular, it acquires information on communication requirements such as the transmission delay requirement 106 and the communication bandwidth requirement 107. Next, in S111, it acquires the communication performance for each communication flow from the performance acquisition unit 60 of the in-vehicle network 20. Next, in S112, it compares the communication requirements acquired in S110 with the communication performance acquired in S111 for each communication flow. Finally, in S113, it outputs the communication requirement fulfillment state for each communication flow.

[0029] The communication requirement update unit 52 updates the communication requirements for each communication flow in accordance with 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 details of S106 in the overall processing flowchart of Figure 5. First, in S120, the communication requirement update unit 52 obtains the communication requirements for each communication flow from the communication requirement storage unit 50. Next, in S121, it obtains the communication requirement fulfillment state for each communication flow from the communication performance monitoring unit 51. Subsequently, in S122, it updates the communication requirements for communication flows that do not fulfill the communication requirements (details will be explained later). Finally, in S123, it outputs the updated communication requirements for each communication flow.

[0030] 9 shows a detailed flowchart of S122 in the communication requirement update unit 52. The communication requirement 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 process 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. That is, 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. If there is a second communication (Yes in S131), the communication requirements for the second communication (rather than the first 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. In other words, the communication requirement update unit 52 determines whether to update the communication requirements for the first communication or whether to update the communication requirements for the other communications (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 communications whose communication performance is determined to satisfy the communication requirements. Here, updating the communication requirements in S132 means loosening the communication requirements, such as setting a transmission delay requirement that is greater than the value set by the application management device 22 for a communication flow having a transmission delay requirement, or setting a communication bandwidth requirement that is smaller than the value set by the application management device 22 for a communication flow having a communication bandwidth requirement. On the other hand, updating the communication requirements in S133 means tightening the communication requirements, such as setting a transmission delay requirement that is smaller than the value set by the application management device 22 for a communication flow having a transmission delay requirement, or setting a communication bandwidth requirement that is larger than the value set by the application management device 22 for a communication flow having a communication bandwidth requirement.

[0031] 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 creation of the communication settings can be performed using any known technology, such as the technology described in Patent Document 1.

[0032] 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 implemented 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). When applying the communication settings to the in-vehicle network 20, the setting unit 54 also sets performance acquisition conditions for the performance acquisition unit 60. That is, the setting unit 54 sets information on communication performance to be acquired for communication identification information formed by a combination of the source and destination ECUs, source and destination applications, etc.

[0033] After the setting unit 54 has completed the communication setting, the communication control device 21 performs a communication test on the in-vehicle network 20 that simulates communication related to an application during driving.

[0034] As described above, in the first embodiment, by updating the communication requirements, the performance margin of the communication settings for the communication requirements of each inserted communication flow is reduced, and it becomes possible to accommodate communication flows that could not be accommodated due to a lack of resources through simple communication design. By setting the value of the communication priority 103 to a value corresponding to the safety of the communication flow during vehicle travel, it is possible to ensure the safety of vehicle travel. In particular, in the first embodiment, by completing the communication design before the vehicle travels, it is possible to reliably ensure the safety of vehicle travel due to changes in the network settings.

[0035] Second Embodiment Next, a second embodiment of an in-vehicle network system according to the present invention will be described with reference to Figures 10 and 11. The second embodiment shows a configuration required for enabling application updates while the vehicle is traveling in an SDV. In the second embodiment, 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.

[0036] 10 is a block diagram showing the configuration of a network system according to the second embodiment. In addition to the configuration of the first embodiment, a communication setting storage unit 55 is added to the communication control device 21. The communication setting storage unit 55 stores communication settings of the in-vehicle network 20 that have been created in the past, and by reading these settings as needed, it is possible to easily restore the previous communication settings.

[0037] FIG. 11 is a flowchart illustrating the overall network system processing in the second embodiment (particularly, a flowchart illustrating the overall operation of the communication control device 21). Processing steps similar to those in the first embodiment are denoted by the same reference numerals. The network system 19 starts its operation when the application management device 22 adds an application (S200). Next, in S101, the communication control device 21 creates a communication setting for the in-vehicle network 20 and applies it to the in-vehicle network 20. In the following S201, the communication performance of each application is measured for communications actually performed in the in-vehicle network 20. Then, in S104, the communication control device 21 acquires the communication performance of each application measured by the in-vehicle network 20. In S105, the communication control device 21 compares the acquired communication performance of each application with the stored communication requirements for each communication of the application. If there is any communication that does not satisfy the communication requirements (Yes), the communication control device 21 further checks in S202 whether the communication that does not satisfy the communication requirements is new communication performed 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), 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. That is, the communication control device 21 acquires, from the communication setting storage unit 55, the past communication settings at the time when the communication other than the new communication satisfied the communication requirements, and sets the past communication settings acquired from the communication setting storage unit 55 for the in-vehicle network 20 (easily restoring to the past communication settings). After completing the switchback or simultaneously with the switchback, as in the first embodiment, in S106, 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), 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.

[0038] The operation of each functional block of the communication control device 21 is the same as that of the first embodiment, except for the communication setting storage unit 55 added in the second embodiment.

[0039] According to the second embodiment, even when an application is added while the vehicle is traveling, it is possible to accommodate a communication flow that could not be accommodated due to a lack of resources through simple communication design, while ensuring the safety of the vehicle's traveling.

[0040] [Third Example] Next, a third example of an in-vehicle network system according to the present invention will be described with reference to Fig. 12. In the third example, 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 recovers, 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.

[0041] The configuration of the network system in the third embodiment is the same as that in the first embodiment. In the third embodiment, the above object 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.

[0042] In FIG. 12 , the network system shown in the figure operates in a short time (for example, about 10 milliseconds, which is the shortest control period of the in-vehicle system). First, in S201, the in-vehicle network 20 measures the communication performance for each application. Next, in S104, the communication control device 21 acquires the communication performance for each application measured by the in-vehicle network 20. Next, in S300, the communication control device 21 determines whether the acquired communication performance has changed 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), the communication control device 21 determines in S105 whether there is any communication that does not satisfy the communication requirements. If there is any communication that does not satisfy the communication requirements (Yes in S105), that is, if there was any communication that did not satisfy the communication requirements up until the previous period but there was any communication that does not satisfy the communication requirements in the current period, and therefore it can be determined that communication performance degradation has occurred as a change in communication state, the communication control device 21 updates the communication requirements in S106 and executes S101. If there is no communication that does not satisfy the communication requirements (No in S105), that is, if there was communication that did not satisfy the communication requirements in the previous cycle but there is no communication that does not satisfy the communication requirements in the current cycle (due to the update of the communication requirements), and it can be determined that the communication performance degradation has been resolved and communication has been restored, in S301 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 execution of the next cycle.

[0043] According to the third embodiment, even if a sudden change in the communication state occurs in the in-vehicle network 20, it is possible to prevent degradation of communication performance of communications that have a significant impact on the driving safety of the vehicle, thereby improving the driving safety of the vehicle.

[0044] [Fourth Example] Next, a fourth example of an in-vehicle network system according to the present invention will be described with reference to Figures 13 to 15. In the fourth example, when an application is added to an SDV, communication settings created for the communication requirements of the application are stored, and communication settings previously created for similar communication requirements are searched for and reused for the communication requirements of a subsequently added application, thereby streamlining the creation of communication settings. Here, similar communication requirements refer to, for example, cases where the values ​​of each communication requirement in the application being added fall within a predetermined error range (e.g., within 5%) of the communication requirements for the application for which communication settings were previously created. Note that when only some of the communication requirements are prioritized depending on the application, for example, when priority is given to communication bandwidth but not latency, the search target communication requirements may be limited to those that fall within a predetermined error range for the prioritized communication requirement.

[0045] The configuration of the network system in the fourth embodiment is shown in FIG. 13 . The fourth embodiment includes a communication setting storage unit 55, similar to the second embodiment, 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 previously created communication settings for the communication requirements in response to a reference from the communication requirement update unit 52. The network system 19 may also include an external communication device 23 as an additional component. The communication setting storage unit 55 transmits and stores the stored communication requirements and communication settings via the external communication device 23 to an external location such as a cloud, and further searches for and receives communication settings for similar communication requirements from an external location such as a cloud, for use in creating communication settings for the vehicle itself. This configuration allows communication settings for communication requirements created in one vehicle to be transmitted to an external location, shared with other vehicles, and used in other vehicles.

[0046] 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 original communication requirements 201 received from the application management device 22, updated communication requirements 202 updated by the communication control device 21, and communication settings 203 for the updated communication requirements 202.

[0047] 15 shows a flowchart of the communication requirement update unit 52 in the fourth embodiment. The communication requirement 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 process ends. If there is a first communication (Yes), the process proceeds to S131. In S131, the unit 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), the unit searches the communication setting storage unit 55 for communication requirements similar to those of the second communication (S400). If the search results in communication requirements similar to those of the second communication (Yes in S400), the unit obtains communication settings for the communication requirements similar to those of the second communication from the communication setting storage unit 55 and uses them (S402). 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.

[0048] If there is no second communication (No in S131), in S401, the communication setting storage unit 55 is searched for communication requirements similar to the communication requirements of the first communication. If the search results in communication requirements similar to the communication requirements of the first communication (Yes in S401), in S403, communication settings for the communication requirements similar to the communication requirements 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 the communication requirements of the first communication (No in S401), in S133, the communication requirements of the first communication are updated as in the first embodiment.

[0049] When the communication requirement update unit 52 acquires past communication settings from the communication setting storage unit 55, the communication setting creation unit 53 does nothing.

[0050] According to the fourth embodiment, the creation of communication settings can be made more efficient, and when an application is added to an SDV, the time from adding the application to starting operation can be reduced.

[0051] [Summary of First to Fourth Embodiments] As described above, the communication control device 21 according to the present embodiment is a communication control device 21 that controls communication of a network (on-board 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 communication performance of the communication and priorities determined according to the degree of impact that the communication has on the operation of a system including the network, a communication performance monitoring unit 51 that determines whether or not the communication (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 by the communication setting creation unit 53 for the network.

[0052] In addition, in the communication control device 21 according to this embodiment, the communication requirement update unit 52 updates the communication requirements of the second communication that has a lower priority than the first communication and is determined to satisfy the communication requirements (S132 in FIG. 9).

[0053] In addition, in this embodiment, before the application operates, the communication control device 21 performs communication of the application using the communication settings created by the communication setting creation unit 53 (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 Figure 5), and if the acquired communication performance of the communication does not satisfy the communication requirements, does not start operation of the application, updates the communication requirements, and recreates the communication settings for the network (S106 and subsequent steps in Figure 5).

[0054] In addition, the communication control device 21 according to this embodiment further has a communication setting memory unit 55 that stores the communication settings created in the past, and when the first communication that is determined not to satisfy the communication requirements is a communication related to a newly added application, the communication requirement update unit 52 obtains from the communication setting memory unit 55 the past communication settings at the time when a 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 memory unit 55 to the network (second embodiment).

[0055] Furthermore, in the communication control device 21 according to this 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 the communication performance degradation occurs, and restores the communication requirements to their original state when the communication performance degradation is resolved (third embodiment).

[0056] In addition, the communication control device 21 according to this embodiment further has a communication setting memory unit 55 that stores the communication settings previously created for the communication requirements, and the communication requirement update unit 52 searches the communication setting memory unit 55 for communication requirements similar to the communication requirements, and if a communication requirement similar to the communication requirement is found, obtains the communication settings for the communication requirement similar to the communication requirement from the communication setting memory unit 55, and the setting unit 54 configures the network using the communication settings obtained from the communication setting memory unit 55 (fourth embodiment).

[0057] In addition, in the communication control device 21 according to this embodiment, the communication setting memory 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 its own device (fourth embodiment).

[0058] Furthermore, in the communication control device 21 according to this embodiment, the communication requirement update unit 52 determines whether to update the communication requirements of the first communication or whether to update the communication requirements of the other communication based on the priority of the first communication that is determined by the communication performance monitoring unit 51 not to satisfy the communication requirements and the priority of the other communication that is determined to satisfy the communication requirements.

[0059] Furthermore, in the communication control device 21 according to this embodiment, if there is a second communication that has a lower priority than the first communication and that is determined to satisfy the communication requirements, the communication requirement update unit 52 updates the communication requirements for the second communication, and if there is no second communication that has a lower priority than the first communication and that is determined to satisfy the communication requirements, the communication requirement update unit 52 updates the communication requirements for the first communication.

[0060] Furthermore, the network system 19 according to this embodiment 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 a plurality of 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 communication performance for each of the applications.

[0061] In the network system 19 according to this embodiment, the priority is determined by the application management device 22 before the application is added to the communication device (ECU).

[0062] In the network system 19 according to this embodiment, the priority is determined by the communication control device 21 .

[0063] That is, the communication control device 21 according to this embodiment updates the communication requirements according to the degree of influence of the application on the driving safety of the vehicle, and manages the updating of communication settings, switching back, and the like.

[0064] According to this embodiment, when placing an application in an ECU, which is a communication device, the placement is performed taking into consideration the resources within the ECU and the communication resources between ECUs, and by ensuring the execution performance and communication performance of the application, stable operation of the application is ensured, thereby providing a communication control device and network system that enables the addition of applications in an SDV while ensuring the driving safety of the vehicle.

[0065] The present invention is not limited to the above-described embodiments, but includes various modifications. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to those including all of the described configurations. Furthermore, it is possible to replace part of the configuration of one embodiment with the configuration of another embodiment, or to add the configuration of another embodiment to the configuration of one embodiment. Furthermore, it is possible to add, delete, or replace part of the configuration of each embodiment with other configurations.

[0066] In addition, the control lines and information lines shown are those that are considered necessary for the explanation, and do not necessarily show all the control lines and information lines in the product. In reality, it can be assumed that almost all components are interconnected.

[0067] REFERENCE SIGNS LIST 1 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

Claims

1. A communication control device that controls communication on a network including multiple communication devices, comprising: a communication requirement storage unit that stores, for each application, communication requirements that are requirements for the communication performance of the communication regarding communications related to multiple applications, and priorities determined according to the degree of impact that the communication has on the operation of a system including the network; a communication performance monitoring unit that determines whether the communication satisfies the communication requirements; a communication requirement 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 to the network.

2. A communication control device according to claim 1, characterized in that the communication requirement update unit updates the communication requirements of a second communication that has a lower priority than the first communication and is determined to satisfy the communication requirements.

3. A communication control device as described in claim 1, characterized in that before the application operates, the application communicates using the communication settings created by the communication setting creation unit, the communication performance of the communication is acquired by the communication performance monitoring unit, the operation of the application is started if the acquired communication performance of the communication satisfies the communication requirements, and the operation of the application is not started if the acquired communication performance of the communication does not satisfy the communication requirements, the communication requirements are updated, and the communication settings for the network are recreated.

4. A communication control device as described in claim 1, further comprising a communication setting storage unit that stores the communication settings created in the past, wherein when the first communication determined not to satisfy the communication requirements is a communication related to a newly added application, the communication requirement update unit acquires from the communication setting storage unit the past communication settings at the time when a communication other than the communication related to the newly added application satisfied the communication requirements, and the setting unit sets the past communication settings acquired from the communication setting storage unit to the network.

5. A communication control device according to claim 1, wherein the communication performance monitoring unit further monitors communication performance degradation in real time, and the communication requirement update unit updates the communication requirements when the communication performance degradation occurs, and restores the communication requirements to their original state when the communication performance degradation is resolved.

6. A communication control device as described in claim 1, further comprising a communication setting storage unit that stores the communication settings previously created for the communication requirements, wherein the communication requirement update unit searches the communication setting storage unit for communication requirements similar to the communication requirements, and when a communication requirement similar to the communication requirement is found, acquires from the communication setting storage unit the communication settings for the communication requirement similar to the communication requirement, and wherein the setting unit configures the network using the communication settings acquired from the communication setting storage unit.

7. A communication control device as described in claim 6, wherein the communication setting storage unit transmits the stored communication requirements and communication settings to the outside to share them with other communication control devices, receives the communication requirements and communication settings stored in the other communication control devices from the outside, and uses them to create the communication settings in the device itself.

8. A communication control device as described in claim 1, characterized in that the communication requirement update unit determines whether to update the communication requirements of the first communication or whether to update the communication requirements of the other communication based on the priority of the first communication that is determined by the communication performance monitoring unit to not satisfy the communication requirements and the priority of the other communication that is determined to satisfy the communication requirements.

9. A communication control device as described in claim 1, characterized in that the communication requirement update unit updates the communication requirements for the second communication when there is a second communication that has a lower priority than the first communication and is determined to satisfy the communication requirements, and updates the communication requirements for the first communication when there is no second communication that has a lower priority than the first communication and is determined to satisfy the communication requirements.

10. A network system having the communication control device according to claim 1, further comprising an application management device to which the application is added, and a network comprising a plurality of communication devices as a communication path for the application to communicate, and further comprising a performance acquisition unit within the communication devices constituting the network for acquiring communication performance for each of the applications.

11. A network system according to claim 10, wherein the priority is determined by the application management device before the application is added to the communication device.

12. A network system according to claim 10, wherein the priority is determined by the communication control device.

13. A network system as described in claim 10, wherein the network system is mounted on a vehicle, the vehicle further comprising an actuator for driving the vehicle, and the priority of communications other than those relating to control of the actuator is set lower than the priority of communications relating to control of the actuator.

14. A network system as described in claim 13, wherein the vehicle further comprises a sensor for recognizing the driving environment around the vehicle, the priority of communication relating to data from the sensor is set lower than the priority of communication relating to control of the actuator, and the priority of communications other than communication relating to control of the actuator and communication relating to data from the sensor is set lower than the priority of communication relating to control of the actuator and communication relating to data from the sensor.

Images