Communication control device and network system

Abstract

In an SDV, a communication control device and a network system capable of increasing the number of communications that can be accommodated in a network while ensuring the running safety of a vehicle are provided. With respect to communications involving a plurality of applications, a communication requirement, which is a requirement for a communication performance of a communication, and a priority, which is determined in accordance with the degree of influence of the communication on the operation of a system including the network, are stored for each application, it is determined whether the communication (communication performance) satisfies the communication requirement (communication requirement satisfaction state), and the communication requirement for a first communication that is determined not to satisfy the communication requirement is updated based on the priority of the first communication and the priorities of other communications that are determined to satisfy the communication requirement.

Description

Technical Field

[0001] This invention relates to communication control devices and network systems, and particularly to an in-vehicle communication control device for controlling an in-vehicle network and an in-vehicle network system having the same. Background Technology

[0002] Autonomous driving and driver assistance technologies are advancing rapidly and will continue to develop in the future. Automakers are exploring applying these technological advancements not only to new vehicles but also to those already on the market. One technology for this purpose is OTA (Over-the-Air) upgrades. Vehicles that can perform software changes through OTA updates are called SDVs (Software-Defined Vehicles).

[0003] The vehicle system is configured with multiple Electronic Control Units (ECUs) connected via a network. Here, the ECU is used collectively as a device that controls sensors such as cameras, actuators such as the engine and steering gear, and performs calculations for control. Within the ECU, data is transmitted and received via the vehicle network, and applications process this data to obtain information for vehicle control. The transmission and reception of data places a load on the vehicle network, but the load condition of the vehicle network varies depending on the application configuration.

[0004] For in-vehicle applications to function, not only is application scheduling necessary to ensure processing time, but communication scheduling is also required to ensure performance. Communication scheduling necessitates a network design that flexibly utilizes QoS (Quality of Service) functions to adjust data transmission priorities from network switches, and TSN (Time-Sensitive Network) functions to control data transmission timing and bandwidth.

[0005] In network design, for example, Patent Document 1 discloses a method for designing network parameters based on communication requirements such as communication delays required by the application. Patent Document 1 discloses the following method: In a wireless communication system, regarding the traffic that each communication device intends to transmit, for example, a counter value is set considering transmission timing and allowable delay, and this counter value is represented by an integer value in units of time slot length; based on this counter value, the traffic that should be transmitted in each time slot is determined.

[0006] Existing technical documents

[0007] Patent documents

[0008] Patent Document 1: Japanese Patent Application Publication No. 2020-155857 Summary of the Invention

[0009] The problem the invention aims to solve

[0010] In the technology described in Patent Document 1, since the timing of sending variable-length data packets is scheduled for fixed-length time slots, the time slots become periods exceeding the maximum length of the variable-length data packets, and in principle, there are periods during which data packets are not sent. That is, since independent communication margins are given to ensure communication performance, the utilization rate of communication bandwidth cannot be improved. Therefore, the number of applications that can be accommodated in the SDV reaches its limit, especially in low-priced ECUs installed in Volkswagen vehicles, raising concerns that the applications desired by users cannot be installed. Furthermore, when installing (adding) applications in the SDV by reducing the communication margin in the in-vehicle network and increasing the number of communications that can be accommodated in the network, the degree to which the applications (applications) affect the driving safety of the vehicle varies. For example, communication related to the vehicle's driving control, such as the engine / motor, brakes, and steering system, is prioritized; communication related to sensor data used to identify the driving environment around the vehicle is prioritized as much as possible; and information and entertainment communications such as audio and video are only allowed when there is sufficient margin. Therefore, simply increasing the number of applications used in SDV may have an impact on vehicle driving safety.

[0011] Therefore, the purpose of this invention is to provide a communication control device and network system that can be added to SDV while ensuring the driving safety of the vehicle.

[0012] means for solving problems

[0013] To address the aforementioned problems, the communication control device of the present invention is a communication control device for controlling the communication of a network including multiple communication devices, comprising: a communication request storage unit that stores communication requests and priorities for each of multiple applications, wherein the communication request is a requirement for the communication performance of the communication, and the priority is determined based on the degree of impact of the communication on the operation of a system including the network; a communication performance monitoring unit that determines whether the communication meets the communication requirements; a communication request updating unit that updates the communication request for the first communication based on the priority of a first communication determined by the communication performance monitoring unit to not meet the communication requirements and the priorities of other communications determined to meet the communication requirements; a communication setting generation unit that generates a communication setting for the network based on the communication request updated by the communication request updating unit; and a setting unit that sets the communication setting generated by the communication setting generation unit for the network.

[0014] The effects of the invention

[0015] According to the present invention, when configuring an application to an ECU as a communication device, the configuration takes into account the resources inside the ECU and the communication resources between ECUs. By ensuring the execution performance and communication performance of the application, the stable operation of the application is ensured. This provides a communication control device and network system that can add applications to an SDV while ensuring the driving safety of the vehicle.

[0016] Other issues, structures, and effects not mentioned above will be clarified through the following description of the implementation methods. Attached Figure Description

[0017] Figure 1A This is a diagram illustrating the electronic and electrical architecture (domain architecture) inside a vehicle equipped with the in-vehicle network system of the present invention.

[0018] Figure 1B This is a diagram illustrating the electronic and electrical architecture (regional architecture) inside a vehicle equipped with the in-vehicle network system of the present invention.

[0019] Figure 2A This is a hardware configuration diagram of the domain ECU.

[0020] Figure 2B This is a hardware configuration diagram showing the area ECU.

[0021] Figure 2C This is a diagram showing the hardware configuration of the gateway.

[0022] Figure 2D This is a hardware configuration diagram showing the central ECU.

[0023] Figure 3 This is a diagram showing the configuration of the ECU and the software running on the ECU.

[0024] Figure 4 This is a functional block diagram illustrating the network system in the first embodiment.

[0025] Figure 5 This is a flowchart illustrating the overall operation of the communication control device 21 in the first embodiment.

[0026] Figure 6 This is a diagram showing the application requirement storage table 100 maintained by the communication requirement storage unit 50.

[0027] Figure 7 This is a flowchart illustrating the operation of the communication performance monitoring unit 51.

[0028] Figure 8 This is a flowchart illustrating the operation of the communication request update unit 52.

[0029] Figure 9 This is a flowchart showing the details of S122 in the operation of the communication request update unit 52.

[0030] Figure 10 This is a functional block diagram illustrating the network system in the second embodiment.

[0031] Figure 11 This is a flowchart illustrating the overall operation of the communication control device 21 in the second embodiment.

[0032] Figure 12 This is a flowchart illustrating the overall operation of the communication control device 21 in the third embodiment.

[0033] Figure 13 This is a functional block diagram illustrating the network system in the fourth embodiment.

[0034] Figure 14 This is a diagram showing the communication setting storage table 200 maintained by the communication setting storage unit 55.

[0035] Figure 15 This is a flowchart illustrating the operation of the communication request update unit 52 in the fourth embodiment. Detailed Implementation

[0036] [First Embodiment]

[0037] The following is for reference Figures 1A to 9 The first embodiment of the vehicle network system of the present invention will be described.

[0038] Figure 1A as well as Figure 1B The figures illustrate the electronic and electrical architecture inside a vehicle equipped with the in-vehicle network system of the present invention. Two representative electronic and electrical architectures are listed here, but the scope of the present invention is not limited thereto.

[0039] Figure 1AThis diagram illustrates the logical structure of an electronic and electrical architecture known as a domain architecture. It shows how the ECUs within vehicle 1 are categorized into functional classes called domains, and how ECUs belonging to the same domain are systematically connected. Each domain has domain ECUs 3a to 3d (hereinafter referred to as domain ECU 3) that govern that domain. Furthermore, to facilitate communication between domains, the domain ECUs 3 are interconnected via gateway 2. Domains may include, for example, an ADAS (Advanced Driver Assistance System) domain responsible for safe driving assistance, a PT / CH (Power Train / Chassis) domain controlling the vehicle's forward and backward and left and right movements, a BODY domain controlling electrical equipment such as power windows, and an Infotainment domain controlling navigation and audio. For each domain, there are ADAS ECU 3a, PT / CH ECU 3b, BODY ECU 3c, and Infotainment ECU 3d (hereinafter referred to as domain ECU 3). On ECUs 3a to 3d, sensors 4a to 4d (hereinafter referred to as sensor 4) and actuators 5a to 5d (hereinafter referred to as actuator 5), etc., are connected via buses 6a to 6d (hereinafter referred to as bus 6) suitable for each domain, such as CAN (Controller Area Network) or LIN (Local Interconnect Network). Multiple ECUs 4 and 5 may be connected on a single bus 6. Additionally, on gateway 2, a TCU (Telematics Control Unit) 7 is connected, which communicates with external servers and the cloud via a wireless network.

[0040] The performance and functional requirements of domain ECUs can vary depending on the domain. For example, ADAS ECUs and Infotainment ECUs, due to their handling of large volumes of data such as video, utilize high-performance hardware. On the other hand, PT / CH ECUs, being directly related to safety, employ highly reliable hardware.

[0041] Figure 1BThis diagram illustrates the physical structure of an electronic and electrical architecture known as a regional architecture. It shows how ECUs 4 and 5 are categorized according to their spatial location within the vehicle 1 and connected to regional ECUs 9a to 9d (hereinafter also referred to as regional ECUs 9) that govern that location. The system consists of one or more regional ECUs 9, a central ECU 8 connected to the regional ECUs 9 and executing multiple applications across multiple domains, sensors 4 connected to the regional ECUs 9, and actuators 5, etc. As its name suggests, each regional ECU 9 is configured corresponding to a position within the vehicle 1, such as front, rear, left, or right, and is connected to sensors 4 or actuators 5, or both, located near its position. Furthermore, each regional ECU 9 connects to other regional ECUs 9 via a shared bus 10 that uses a common communication method between domains. This common communication method is envisioned as an Ethernet-based (registered trademark) exchange network. Additionally, a TCU 7 is connected. The TCU 7 connects to the central ECU 8 or any of the regional ECUs 9, but... Figure 1B The image shows an example of connection to the central ECU 8.

[0042] Figures 2A to 2D These are the hardware structures of Domain ECU 3, Area ECU 9, Gateway 2, and Central ECU 8. Figures 2A to 2D The thick lines in the diagram represent the connection methods between communication devices in the regional architecture, i.e., the general communication methods, while the thin lines represent other communication methods.

[0043] Figure 2A In the domain architecture ( Figure 1A The hardware structure of the domain ECU 3 in the ) is as follows. The domain ECU 3 has a CPU (Central Processing Unit) 11 for processing information received from the sensor 4 and the actuator 5 or the gateway 2, and a memory 12 for holding the data used by the CPU 11 for calculation. Buses for connecting to the gateway 2 and for connecting to the sensor 4 and the actuator 5 are led out from the CPU 11.

[0044] Figure 2B In the regional architecture ( Figure 1BThe hardware structure of the regional ECU 9 in the diagram is described below. The regional ECU 9 has a network switch 13 that houses a shared bus 10, which is used to connect to other regional ECUs 9, or to sensors 4 and actuators 5. Additionally, the regional ECU 9 has a CPU 11 for processing information received from sensors 4 and actuators 5, or from the shared bus 10, and is connected to the network switch 13. The CPU 11 is also connected to a memory 12. If sensors 4 and actuators 5 correspond to a common communication method, the memory 12 can also be directly connected to the network switch 13. If sensors 4 and actuators 5 do not correspond to a common communication method, the memory 12 can be converted to a common communication method based on its connection to the CPU 11.

[0045] Figure 2C as well as Figure 2D It is a domain architecture ( Figure 1A Gateway 2 and region architecture in ) Figure 1B The hardware structure of the central ECU 8 in the ) is largely the same, with a CPU 11, a memory 12, and a network switch 13 for connecting to the domain ECU 3 or the area ECU 9.

[0046] Figure 3 This diagram illustrates the structure of software running in a typical ECU. In ECUs such as Domain ECU 3, Gateway 2, Area ECU 9, and Central ECU 8, a system consists of hardware 32, middleware 31, and applications 30. Hardware 32 comprises a CPU (Central Processing Unit) or MCU (Micro-Controller Unit) for running the software, memory, peripheral circuitry, etc. Middleware 31 operates on hardware 32 and provides functions shared by various software programs (which may also include an operating system). Applications 30 contain the functions required for controlling vehicle movement. Unless otherwise specified, the various functional modules in this embodiment are installed on middleware 31. However, even if some or all of the various functions in this embodiment are installed as hardware 32 or applications 30, the resulting effect remains unchanged.

[0047] Figure 4This is a functional block diagram of the network system in the first embodiment of the present invention. This function, acting as middleware 31, runs 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 can be installed as different ECUs, or some or all of them can be installed as a single ECU. Furthermore, some or all of the functions of the application management device 22 can be located inside the vehicle or outside the vehicle. An example of this external location is an OTA server for OTA-based software updates and a rewriting tool for ECU rewriting at a dealership. The in-vehicle network 20 is a communication path for applications to communicate, connecting multiple ECUs (domain ECU 3, gateway 2, area ECU 9, central ECU 8, etc.) that act as communication devices, transmitting data from the source application to the target application. The communication control device 21 controls the communication of the in-vehicle network 20, which includes multiple ECUs (domain ECU 3, gateway 2, area ECU 9, central ECU 8, etc.). The application management device 22 is a device for managing the distribution, updates, and other aspects of applications in the SDV (Software for Vehicles). The application management device 22 transmits application data to the ECU at the deployment destination, enabling the new application to run on the ECU (not shown). Furthermore, the application management device 22 transmits communication data related to the application as application metadata accompanying the application data body to the communication control device 21. Here, the communication data related to the application in this embodiment is described later. Figure 6 All the data shown.

[0048] While referring to Figure 5The overall processing flowchart of the network system (particularly showing the flowchart of the overall operation of the communication control device 21) will be used to explain the various functional modules of the network system in the first embodiment of the present invention. First, when the vehicle starts and the network system begins its operation, processes S100 to S107 are performed, and after completion, the vehicle becomes capable of driving. In S100, during the vehicle's parking period, the application management device 22 generates an application configuration plan for the ECU. The application configuration plan refers to the plan in which ECU the application will be implemented based on ECU performance and available resources. Next, in S101, the communication control device 21 generates communication settings for the vehicle network 20 and applies them to the vehicle network 20. In the following S102, the communication control device 21 performs a communication test simulating communication related to applications during driving for the vehicle network 20. For this communication test, in S103, the vehicle network 20 measures the communication performance of each application. Subsequently, in S104, the communication control device 21 acquires the communication performance of each application measured by the 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. If there is a communication that does not meet the communication requirements ("Yes"), in S106, the communication control device 21 updates the communication requirements. Afterwards, it returns to S101 and regenerates the communication settings for the vehicle network 20, thus re-implementing the processing following the generation of the communication settings. In S105, if there is no communication that does not meet the communication requirements ("No"), because the communication of the application meets the communication requirements, the operation of the application becomes possible. Therefore, in S107, the application management device 22 starts the operation of the application and ends the processing.

[0049] exist Figure 4 The middle section also shows the methods used to implement Figure 5 The functional block diagram of the communication control device 21 and the vehicle network 20 is shown below. The communication control device 21 is further composed of a communication request storage unit 50, a communication performance monitoring unit 51, a communication request updating unit 52, a communication setting generation unit 53, and a setting unit 54. A performance acquisition unit 60a-60c (hereinafter also referred to as performance acquisition unit 60) is provided in the ECU included in the vehicle network 20 to measure the communication performance of each communication stream, which is used as a unit of performance measurement. Communication performance includes, for example, transmission delay time, communication bandwidth, packet loss rate, jitter, etc. Communication streams can be identified, for example, by communication identification information composed of a combination of a source ECU, a destination ECU, a source application, etc. The performance acquisition unit 60 maintains and stores the communication performance based on this communication identification information and sends it to the communication control device 21.

[0050] The communication requirement storage unit 50 stores the application's communication requirements based on application-related metadata distributed from the application management device 22. These communication requirements are performance requirements related to the application's communication, including requirements for transmission latency, communication bandwidth, packet loss rate, jitter, etc. In this embodiment, the communication requirements are defined as communication latency requirements for transmission latency and communication bandwidth requirements for communication bandwidth. Figure 6 The communication requirement storage table 100 maintained by the communication requirement storage unit 50 is shown. The communication requirement storage table 100 (also known as the application requirement storage table 100) maintains information related to communication parameters such as communication priority 103, communication period 104 or data packet length 105, transmission delay requirement 106 and communication bandwidth requirement 107, for the combination of the sending source 101 and destination 102 as communication identification information (i.e., for each application).

[0051] Communication priority 103 is set based on the degree to which the communication affects the operation of the network system, including the in-vehicle network 20. By setting the communication priority 103 to a value corresponding to the safety of the communication flow during vehicle operation, vehicle operation safety can be ensured. For example, the priority of communication related to vehicle driving control, such as the engine / motor, brakes, and steering system, is set to high (in... Figure 6 In the middle "3"), the priority of communication related to sensor data used to identify the driving environment around the vehicle is set to medium (in Figure 6 In section "2"), the priority of informational and entertainment communications such as audio and video is set to low (in... Figure 6 (1) In other words, the vehicle 1 equipped with this network system has actuators for driving the vehicle, sensors for recognizing the driving environment around the vehicle, etc. The priority of sensor data-related communication is set lower than the priority of actuator control-related communication (the priority of actuator control-related communication is set higher than the priority of sensor data-related communication), and the priority of communication other than actuator control-related communication and sensor data-related communication is set lower than the priority of actuator control-related communication and sensor data-related communication. Which type of communication flow is driving control, sensor data, information-type, or entertainment-type communication can be determined by referring to the information of the sending source 101. In addition, the setting subject of the communication priority 103 can also be set by the application management device 22 before adding the application to the ECU (before being processed by the communication control device 21), or can be set by the communication control device 21 for each vehicle application.

[0052] The communication performance monitoring unit 51 obtains the communication performance of each communication from the performance acquisition unit 60 of the vehicle network 20, and monitors whether the communication performance meets the communication requirements (communication requirement met status). Figure 7 A flowchart of the communication performance monitoring unit 51 is shown. This shows... Figure 5 The details of S104 in the overall processing flowchart are as follows: First, in S110, the communication performance monitoring unit 51 obtains the communication requirements for each communication stream from the communication requirement storage unit 50. Specifically, it obtains information regarding communication requirements such as transmission delay requirement 106 and communication bandwidth requirement 107. Next, in S111, it obtains the communication performance of each communication stream from the performance acquisition unit 60 of the vehicle network 20. Then, in S112, for each communication stream, it compares the communication requirements obtained in S110 with the communication performance obtained in S111. Finally, in S113, it outputs the communication requirement fulfillment status for each communication stream.

[0053] The communication requirement update unit 52 updates the communication requirements of each communication flow based on the communication requirement fulfillment status of each communication flow obtained from the communication performance monitoring unit 51. Figure 8 A flowchart of the communication request update unit 52 is shown. This shows... Figure 5 The details of S106 in the overall processing flowchart are as follows: First, in S120, the communication requirement update unit 52 retrieves the communication requirements for each communication flow from the communication requirement storage unit 50. Next, in S121, it retrieves the communication requirement fulfillment status for each communication flow from the communication performance monitoring unit 51. Then, in S122, for communication flows that do not meet their communication requirements, the communication requirements are updated (details described later). Finally, in S123, for each communication flow, the updated communication requirements are output.

[0054] Figure 9The flowchart below shows the details of S122 in the communication request update unit 52. In S130, the communication request update unit 52 first determines whether there is a first communication whose communication performance does not meet the communication requirements. This determination is based on the communication requirement fulfillment status of each communication stream 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"), proceed to S131. In S131, it is determined whether there is a second communication with a lower priority than the first communication that meets the communication requirements. That is, the priority of the first communication is obtained, and a communication with a lower priority than the first communication is retrieved from the communication streams that meet the communication requirements. If there is a second communication ("Yes" in S131), in S132, the communication requirements for the second communication (not the first communication) are updated. If there is no second communication ("No" in S131), in S133, the communication requirements for the first communication are updated. 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 other communications (not the first communication), based on the priority of the first communication whose communication performance is determined to be unsatisfactory and the priority of other communications whose communication performance is determined to be satisfactory. Here, updating the communication requirements in S132 means setting the communication requirements more leniently; for example, setting the transmission delay requirement for a communication stream with a transmission delay requirement to a value greater than the value set by the application management device 22, or setting the communication bandwidth requirement for a communication stream with a communication bandwidth requirement to a value less than the value set by the application management device 22. On the other hand, updating the communication requirements in S133 means setting the communication requirements more strictly; for example, setting the transmission delay requirement for a communication stream with a transmission delay requirement to a value less than the value set by the application management device 22, or setting the communication bandwidth requirement for a communication stream with a communication bandwidth requirement to a value greater than the value set by the application management device 22.

[0055] The communication setting generation unit 53 generates the communication settings for the vehicle network 20 using the communication requirements updated by the communication requirement update unit 52. The generation of the communication settings can be implemented using any known technology, such as the technology described in Patent Document 1.

[0056] The setting unit 54 applies (sets) the communication settings generated by the communication setting generation unit 53 to the vehicle network 20. This can be implemented using any known technology such as NETCONF (Internet Engineering Task Force, Request for Comments: 6241) and SNMP (Simple Network Management Protocol; Internet Engineering Task Force, Request for Comments: 3411). When applying the communication settings to the vehicle network 20, the performance acquisition conditions for the performance acquisition unit 60 are also set. That is, information on the communication performance that should be acquired is set for the communication identification information composed of the source and destination ECUs, the source and destination applications, etc.

[0057] After the communication settings are completed by the setting unit 54, the communication control device 21 performs a communication test on the vehicle network 20, simulating the communication of applications during driving.

[0058] As described above, in the first embodiment, by updating the communication requirements, the performance margin of the communication settings for each inserted communication stream is reduced, thereby accommodating communication streams that cannot be accommodated due to insufficient resources under simple communication design alone. By setting the value of communication priority 103 to a value corresponding to the safety of the communication stream during vehicle operation, vehicle operation safety can be ensured. In particular, in the first embodiment, by completing the communication design before vehicle operation, vehicle operation safety achieved through network setting changes can be reliably ensured.

[0059] [Second Embodiment]

[0060] Next, refer to Figure 10 as well as Figure 11 A second embodiment of the in-vehicle network system of the present invention will be described. In this second embodiment, the structure required for application updates in the SDV while the vehicle is in motion is shown. In this second embodiment, communication settings are generated and communication performance is monitored in real time for applications added while the vehicle is in motion. If a communication flow exists where the communication performance does not meet 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 generated again.

[0061] Figure 10This is a block diagram illustrating the configuration of the network system in the second embodiment. In addition to the configuration in the first embodiment, a communication setting storage unit 55 is added to the communication control device 21. The communication setting storage unit 55 stores previously generated communication settings of the vehicle network 20, which can be easily restored to previous communication settings by reading them as needed.

[0062] Figure 11 This is a flowchart of the overall network system processing in the second embodiment (specifically, a flowchart showing the overall operation of the communication control device 21). The same symbols are used to label the same processing steps as in the first embodiment. The network system 19 begins its operation with the application addition S200 via the application management device 22. Next, in S101, the communication control device 21 generates communication settings for the vehicle network 20 and applies them to the vehicle network 20. In the following S201, the communication performance of each application is measured for actual communication within the vehicle network 20. Subsequently, in S104, the communication control device 21 acquires the communication performance of each application measured via the 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 communication that does not meet the communication requirements ("Yes"), further in S202, it is determined whether the communication that does not meet the communication requirements is a new communication resulting from a newly added application via the application management device 22. If the communication that does not meet the communication requirements is a new communication (S202 "Yes"), in S203, the communication control device 21 reverts the communication settings of the vehicle network 20 to the communication settings before the application was added in S200. That is, the communication control device 21 retrieves the past communication settings from the communication setting storage unit 55 at the time when the communication requirements were met by a communication other than the new communication, and sets the vehicle network 20 to the past communication settings retrieved from the communication setting storage unit 55 (easily reverting to the past communication settings). After the reversion is completed or at the same time as the reversion, similarly to the first embodiment, in S106, the communication control device 21 updates the communication requirements and returns to S101. In S202, if the communication that does not meet the communication requirements is not a new communication (S202 "No"), the communication settings are not reverted, and the process returns to S101. Thereafter, the communication settings for the vehicle network 20 are generated again, and the processing after the generation of the communication settings is performed again. In S105, if there is no communication that does not meet the communication requirements ("No"), the process ends.

[0063] The operation of each functional module 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.

[0064] According to the second embodiment, even when additional applications are added while the vehicle is in motion, it is possible to accommodate communication flows that would otherwise be unacceptable due to insufficient resources under a simple communication design, while ensuring the vehicle's driving safety.

[0065] [Third Embodiment]

[0066] Next, refer to Figure 12 A third embodiment of the vehicle network system of the present invention will be described. In this third embodiment, in order to update the communication settings in response to sudden changes in the communication state in the vehicle network 20, the communication settings are updated by monitoring the communication state in real time and updating the communication requirements, thereby ensuring communication for applications that have a significant impact on vehicle driving safety. Furthermore, if the communication state recovers, the communication settings are restored, thereby improving the availability of communication other than applications that have a significant impact on vehicle driving safety.

[0067] The network system structure in the third embodiment is the same as that in the first embodiment. In the third embodiment, through... Figure 12 The actions shown in the overall processing flowchart can achieve the above objectives even without changing the actions of the individual functional modules of the network system.

[0068] exist Figure 12In this process, the network system shown in the diagram is activated for a short period (e.g., approximately 10 milliseconds, which is the shortest control cycle for the vehicle system). First, in S201, the vehicle network 20 measures the communication performance of each application. Next, in S104, the communication control device 21 acquires the communication performance of each application measured by the vehicle network 20. Then, in S300, the communication control device 21 determines whether the acquired communication performance has changed compared to the previously acquired communication performance. If there is no change ("No"), the operation of this cycle ends. If there is a change ("Yes"), in S105, the communication control device 21 determines whether there is any communication that does not meet the communication requirements. If there is communication that does not meet the communication requirements ("Yes" in S105), that is, if there was no communication that did not meet the communication requirements until the previous cycle, but there is communication that does not meet the communication requirements in the current cycle, and it can be determined that communication performance has deteriorated due to a change in communication state, then in S106, the communication control device 21 updates the communication requirements and executes S101. If there is no communication that does not meet the communication requirements ("No" in S105), that is, if there was communication that did not meet the communication requirements in the previous cycle, but there is no communication that does not meet the communication requirements in the current cycle, and it can be determined that (by updating the communication requirements) the communication performance deterioration has been eliminated and communication has been restored, then in S301, the communication control device 21 restores the communication requirements (in other words, the communication requirements before the update) and executes S101. Furthermore, in S101, the communication control device 21 generates communication settings for the vehicle network 20 and applies them to the vehicle network 20. This process ends in S101, awaiting execution of the next cycle.

[0069] According to the third embodiment, even if a sudden change in communication status occurs in the vehicle network 20, it is possible to prevent the communication performance degradation of communications that have a significant impact on vehicle driving safety and improve vehicle driving safety.

[0070] [Fourth Embodiment]

[0071] Next, refer to Figures 13-15A fourth embodiment of the in-vehicle network system of the present invention will be described. In the fourth embodiment, in the communication of applications added to the SDV, communication settings generated for their communication requirements are stored. For communication requirements of subsequently added applications, communication settings generated in the past for similar communication requirements are retrieved and reused, thereby improving the efficiency of communication setting generation. Here, "similar communication requirements" refers to, for example, a situation where, relative to the values ​​of various communication requirements in the added application, the communication requirements of the application for which the communication settings were previously generated fall within a predetermined error range (e.g., within 5%). Furthermore, in cases where only a portion of the communication requirements is considered based on the application, such as prioritizing communication bandwidth but not latency, the communication requirements to be retrieved can be limited to those within a predetermined error range relative to the important communication requirements.

[0072] Figure 13 The structure of the network system in the fourth embodiment is shown. In the fourth embodiment, a communication setting storage unit 55 is included similarly to that in the second embodiment, but its connection relationship differs. The communication setting storage unit 55 receives and stores information about communication requests and communication settings generated for those requests from the communication setting generation unit 53. Furthermore, the communication setting storage unit 55 provides previously generated communication settings for communication requests based on references from the communication request update unit 52. Additionally, an external communication device 23 can be included as an additional structure to the network system 19. The communication setting storage unit 55 sends the communication requests and communication settings stored via the external communication device 23 to an external source such as the cloud for storage, and then retrieves and receives communication settings for similar communication requests from the cloud or other external source, enabling its use in generating communication settings for its own devices. With this structure, communication settings generated in one vehicle for communication requests can be sent externally for sharing with other vehicles, making them usable in other vehicles as well.

[0073] Figure 14 The diagram shows an overview of the communication setting storage table 200 in the communication setting storage unit 55. The communication setting storage table 200 stores the original communication request 201 received from the application management device 22, the communication request 202 updated by the communication control device 21, and the communication settings 203 for the updated communication request 202.

[0074] Figure 15The flowchart of the communication request update unit 52 in the fourth embodiment is shown. In S130, the communication request update unit 52 first determines whether there is a first communication whose communication performance does not meet 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, it determines whether there is a second communication with a lower priority than the first communication that meets the communication requirements. If there is a second communication ("Yes" in S131), in S400, it searches the communication setting storage unit 55 to see if there is a communication request similar to the communication requirements of the second communication. As a result of the search, if there is a communication request similar to the communication requirements of the second communication ("Yes" in S400), in S402, it retrieves the communication settings for the communication request similar to the communication requirements of the second communication from the communication setting storage unit 55 and uses them. As a result of the search, if there is no communication requirement similar to the communication requirement of the second communication ("No" in S400), in S132, the communication requirement of the second communication (not the first communication) is updated in the same way as in the first embodiment.

[0075] If no second communication exists ("No" in S131), in S401, a search is performed on the communication setting storage unit 55 to determine if a communication request similar to the communication request of the first communication exists. If, as a result of the search, a communication request similar to the communication request of the first communication exists ("Yes" in S401), in S403, a communication setting for the communication request similar to the communication request of the first communication is obtained from the communication setting storage unit 55 and used. If, as a result of the search, no communication request similar to the communication request of the first communication exists ("No" in S401), in S133, the communication request of the first communication is updated in the same manner as in the first embodiment.

[0076] If the communication setting has been obtained from the communication setting storage unit 55 by the communication request update unit 52, the communication setting generation unit 53 does nothing.

[0077] According to the fourth embodiment, the generation efficiency of communication settings is improved, and when adding applications to SDV, the time from application addition to action start can be shortened.

[0078] [Summary of the First to Fourth Embodiments]

[0079] As explained above, the communication control device 21 of this embodiment is a communication control device 21 that controls the communication of a network (vehicle network 20) ​​including multiple communication devices (ECUs). It includes: a communication request storage unit 50, which stores communication requests and priorities for each of the multiple applications, wherein the communication request is a requirement for the communication performance of the communication, and the priority is determined according to the degree of impact of the communication on the operation of the system including the network; a communication performance monitoring unit 51, which determines whether the communication (communication performance) meets the communication request (communication request met state); a communication request updating unit 52, which updates the communication request for the first communication based on the priority of the first communication determined by the communication performance monitoring unit 51 as not meeting the communication request and the priorities of other communications determined as meeting the communication request; a communication setting generation unit 53, which generates a communication setting for the network based on the communication request updated by the communication request updating unit 52; and a setting unit 54, which sets the network settings generated by the communication setting generation unit 53.

[0080] Furthermore, in the communication control device 21 of this embodiment, the communication request update unit 52 updates the communication request of the second communication that has a lower priority than the first communication and is determined to meet the communication request. Figure 9 (S132).

[0081] Furthermore, before the application operates, the communication control device 21 of this embodiment performs a communication test on the application using the communication settings generated by the communication setting generation unit 53, acquires the communication performance of the communication by the communication performance monitoring unit 51, and starts the application operation if the acquired communication performance meets the communication requirements. Figure 5 In step S107, if the acquired communication performance does not meet the communication requirements, the application's operation is not initiated; the communication requirements are updated; and the communication settings for the network are regenerated. Figure 5 (S106 and later).

[0082] Furthermore, the communication control device 21 of this embodiment further includes a communication setting storage unit 55 that stores the previously generated communication settings. When the first communication that is determined to not meet the communication requirements is a communication about a newly added application, the communication request update unit 52 retrieves the past communication settings from the communication setting storage unit 55 at the time when the communication other than the communication about the newly added application meets the communication requirements. The setting unit 54 sets the network settings to the past communication settings retrieved from the communication setting storage unit 55 (second embodiment).

[0083] Furthermore, in the communication control device 21 of this embodiment, the communication performance monitoring unit 51 further monitors the communication performance degradation in real time, and the communication request updating unit 52 updates the communication request when the communication performance degradation occurs, and restores the communication request when the communication performance degradation is eliminated (third embodiment).

[0084] Furthermore, the communication control device 21 in this embodiment further includes a communication setting storage unit 55 that stores the communication settings generated in the past for the communication request. The communication request update unit 52 retrieves communication requests similar to the communication request from the communication setting storage unit 55. If a communication request similar to the communication request is found, the communication setting for the communication request similar to the communication request is obtained from the communication setting storage unit 55. The setting unit 54 uses the communication setting obtained from the communication setting storage unit 55 to set the network (fourth embodiment).

[0085] In addition, in the communication control device 21 of this embodiment, the communication setting storage unit 55 sends the stored communication request and the communication setting to the outside for sharing with other communication control devices (for example, if no communication request similar to the communication request is found), and receives the communication request and the communication setting stored by the other communication control device from the outside for use in the generation of the communication setting in this device (fourth embodiment).

[0086] Furthermore, in the communication control device 21 of this embodiment, the communication request update unit 52 determines whether to update the communication request of the first communication or the communication request of the other communication based on the priority of the first communication determined by the communication performance monitoring unit 51 as not meeting the communication request and the priority of the other communication determined as meeting the communication request.

[0087] Furthermore, in the communication control device 21 of this embodiment, the communication request update unit 52 updates the communication request of the second communication when there is a second communication with a lower priority than the first communication and is determined to meet the communication request, and updates the communication request of the first communication when there is no second communication with a lower priority than the first communication and is determined to meet the communication request.

[0088] Furthermore, the network system 19 of 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 (vehicle network 20) ​​which is a communication path for the application to communicate and is composed of multiple communication devices (ECUs). Within the communication devices (ECUs) constituting the network (vehicle network 20), a performance acquisition unit 60 for acquiring the communication performance of each application is further included.

[0089] Furthermore, in the network system 19 of this embodiment, the priority is determined by the application management device 22 before adding the application to the communication device (ECU).

[0090] In addition, in the network system 19 of this embodiment, the priority is determined by the communication control device 21.

[0091] That is, the communication control device 21 in this embodiment updates the communication requirements according to the impact of the application on the driving safety of the vehicle, and performs management such as updating and rolling back the communication settings.

[0092] According to this embodiment, a communication control device and network system can be provided as follows: when configuring an application to an ECU, which is a communication device, the configuration takes into account the resources inside the ECU and the communication resources between ECUs. By ensuring the execution performance and communication performance of the application, the stable operation of the application is ensured. Thus, while ensuring the driving safety of the vehicle, applications can be added to the SDV.

[0093] Furthermore, the present invention is not limited to the embodiments described above, but includes various modifications. For example, the embodiments described above have been detailed for ease of understanding and illustration of the present invention, and are not limited to necessarily possessing all the described structures. Moreover, a portion of the configuration of one embodiment can be replaced with the configuration of another embodiment; furthermore, the configuration of another embodiment can be added to the configuration of one embodiment. Furthermore, for a portion of the configuration of each embodiment, other configurations can be added, deleted, or replaced.

[0094] Furthermore, the control lines and information lines shown are only those deemed necessary for the description; not all control lines and information lines may be displayed on the actual product. In fact, it can be assumed that almost all components are interconnected.

[0095] Symbol Explanation

[0096] 1 vehicle

[0097] 2 Gateway

[0098] 3-Domain ECU

[0099] 4 sensors

[0100] 5. Actuator

[0101] 6-bus

[0102] 7 TCU

[0103] 8 Central ECU

[0104] 9-zone ECU

[0105] 10 Shared Bus

[0106] 11 CPU

[0107] 12 Memory

[0108] 13 Network Switches

[0109] 19 Network Systems

[0110] 20. In-vehicle network

[0111] 21 Communication control device

[0112] 22 Application Management Device

[0113] 23 External communication device

[0114] 30 Applications

[0115] 31 Middleware

[0116] 32 Hardware

[0117] 100 Communication Requirements Storage Table

[0118] 200 Communication settings storage table.

Claims

1. A communication control device for controlling communication in a network comprising multiple communication devices, characterized in that, have: The communication requirements storage unit stores communication requirements and priorities for each application related to communication involving multiple applications. The communication requirements are communication performance requirements for the communication, and the priorities are determined based on the degree to which the communication affects the operation of the system containing the network. A communication performance monitoring unit determines whether the communication meets the communication requirements. The communication requirement update unit updates the communication requirement for the first communication based on the priority of the first communication determined by the communication performance monitoring unit to not meet the communication requirement and the priority of other communications determined to meet the communication requirement. A communication setting generation unit generates communication settings for the network based on the communication requirements updated by the communication requirement update unit. as well as The setting unit sets the network settings based on the communication settings generated by the communication setting generation unit.

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

3. The communication control device according to claim 1, characterized in that, Before the application is activated, the application communicates using the communication settings generated by the communication setting generation unit, and the communication performance is obtained by the communication performance monitoring unit. If the communication performance of the acquired communication meets the communication requirements, the application operation begins. If the communication performance obtained does not meet the communication requirements, the application will not start its operation, the communication requirements will be updated, and the communication settings for the network will be generated again.

4. The communication control device according to claim 1, characterized in that, It further includes a communication setting storage unit, which stores the communication settings generated in the past. If the communication request update unit determines that the first communication that does not meet the communication requirement is a communication about a newly added application, it retrieves from the communication setting storage unit the past communication settings at the time when the communication requirement was met for communications other than the communication about the newly added application. The setting unit obtains past communication settings from the communication setting storage unit for the network settings.

5. The communication control device according to claim 1, characterized in that, The communication performance monitoring unit further monitors communication performance degradation in real time. The communication request updating unit updates the communication request when the communication performance deteriorates, and restores the communication request when the communication performance deterioration is eliminated.

6. The communication control device according to claim 1, characterized in that, It further includes a communication setting storage unit, which stores the communication settings previously generated for the communication request. The communication request update unit retrieves communication requests similar to the communication request from the communication setting storage unit. If a communication request similar to the communication request is found, the unit obtains the communication settings for the communication request similar to the communication request from the communication setting storage unit. The setting unit uses the communication settings obtained from the communication setting storage unit to set the network.

7. The communication control device according to claim 6, characterized in that, The communication setting storage unit sends the stored communication requirements and communication settings to the outside and shares them with other communication control devices, receives the communication requirements and communication settings stored by the other communication control devices from the outside, and uses them to generate the communication settings in this device.

8. The communication control device according to claim 1, characterized in that, The communication requirement update unit determines whether to update the communication requirement of the first communication or the communication requirement of the other communications based on the priority of the first communication determined by the communication performance monitoring unit as not meeting the communication requirement and the priority of the other communications determined as meeting the communication requirement.

9. The communication control device according to claim 1, characterized in that, The communication request updating unit updates the communication request of the second communication if there is a second communication with a lower priority than the first communication and is determined to meet the communication request; and updates the communication request of the first communication if there is no second communication with a lower priority than the first communication and is determined to meet the communication request.

10. A network system, characterized in that, The network system having the communication control device of claim 1 further comprises: Application management device, which adds the application; and A network is a communication path used by the application for communication and is composed of multiple communication devices. The communication device constituting the network further includes a performance acquisition unit for acquiring the communication performance of each application.

11. The network system according to claim 10, characterized in that, The priority is determined by the application management device before the application is added to the communication device.

12. The network system according to claim 10, characterized in that, The priority is determined by the communication control device.

13. The network system according to claim 10, characterized in that, The network system is mounted on the vehicle. The vehicle further includes actuators for driving the vehicle. Communications other than those concerning the control of the actuator are set to a lower priority than those concerning the control of the actuator.

14. The network system according to claim 13, characterized in that, The vehicle is further equipped with sensors for identifying the driving environment around the vehicle. The priority of communication regarding data from the sensor is set lower than the priority of communication regarding control of the actuator. The priority of communications other than those concerning the control of the actuator and the data of the sensor is set lower than that of communications concerning the control of the actuator and the data of the sensor.

Images