Network with prioritized data streams loaded in a vehicle

Abstract

This invention relates to a data network installed in a vehicle, the network including a first device (ECU1) and at least one second device (ECU2, ECU3, ECU4), the first device and the at least one second device being connected via at least one data link, the devices (ECU1, ECU2, ECU3, ECU4) being capable of transmitting multiple data streams (F1, ..., F10), characterized in that: - the first device (ECU1) is configured to determine a criticality level based on network monitoring data and transmit the criticality level to the second devices (ECU2, ECU3, ECU4); - the second devices (ECU2, ECU3, ECU4) are configured to load a predefined stream configuration table associated with the criticality level in response to the receipt of the criticality level, the table indicating which data streams are transmitted by the second devices (ECU2, ECU3, ECU4).

Description

Technical Field

[0001] This invention claims priority to French application 2008728, filed on August 27, 2020, the contents of which (text, drawings and claims) are incorporated herein by reference.

[0002] This invention relates to data networks, and more particularly to networks installed in vehicles. Background Technology

[0003] With the development of driving systems (especially new autonomous driving functions that require the use of high-resolution cameras), the amount of information exchanged through in-vehicle networks has increased significantly. Traditional in-vehicle networks (CAN, LIN, etc.) are unable to meet this new demand for information exchange due to their bandwidth limitations.

[0004] Therefore, Ethernet networks are used in vehicle networks to take advantage of greater bandwidth and more standardized and available services / protocols. However, for economic reasons and because this new technology is not yet mature in the automotive field, traditional in-vehicle networks continue to coexist with Ethernet in automotive network architectures.

[0005] Autonomous driving functions utilize numerous high-resolution cameras and generate high traffic on the vehicle's data network. In some situations, this traffic can become critical. For example, this might occur in urban environments with a large number of bicycles and vehicles.

[0006] One of the drawbacks of the current system is that it is not designed to manage such high traffic, so the autonomous driving function may no longer be nominally functioning. Summary of the Invention

[0007] The purpose of this invention is to provide a solution to allow the nominal operation of functions that generate high-traffic networks (including under high-traffic conditions) on vehicle data networks.

[0008] Therefore, the present invention aims to provide a data network installed in a vehicle, the network including a first device (ECU1) and at least one second device (ECU2, ECU3, ECU4), the first device and the at least one second device being connected via at least one data link of the network, the devices (ECU1, ECU2, ECU3, ECU4) being capable of transmitting multiple data streams (F1, ..., F10), characterized in that:

[0009] - The first device (ECU1) is configured to determine the criticality level based on network monitoring data and transmit the criticality level to the second devices (ECU2, ECU3, ECU4).

[0010] - The second device (ECU2, ECU3, ECU4) is configured to load (charger) a predefined flow configuration table associated with the criticality level in response to the reception of the criticality level, the table indicating which data streams are transmitted by the second device (ECU2, ECU3, ECU4).

[0011] Through this invention, the first device determines a criticality level reflecting the traffic level on the network. This criticality level is transmitted to devices on the network, which can then adapt the transmitted data stream by loading an appropriate flow configuration table.

[0012] The present invention allows for the convenient removal, for example, of some data streams deemed unnecessary (e.g., data streams related to infotainment systems) to reduce network traffic and thereby free up more bandwidth for data streams related to critical functions (e.g., driver assistance functions).

[0013] Advantageously, the second device (ECU2) includes multiple interfaces, and a configuration table indicates which interface transmits which data stream for a given criticality level.

[0014] Advantageously, the first device (ECU1) is a conversion device (équipement de commutation) that includes multiple data links.

[0015] Advantageously, the network monitoring data originates from the local network of the first device (ECU1).

[0016] Advantageously, the network includes at least one data link, which is selected from CAN, Ethernet, FlexRay, or LIN.

[0017] The present invention relates to a vehicle comprising a network according to the present invention. Attached Figure Description

[0018] Other features and advantages of the invention will become more apparent from the following detailed description and accompanying drawings of non-limiting embodiments, in which:

[0019] - Figure 1 A vehicle data network configured according to a first criticality level is schematically illustrated according to a specific embodiment of the present invention;

[0020] - Figure 2 The diagram illustrates the configuration based on the second criticality level. Figure 1 The network;

[0021] - Figure 3 The diagram illustrates the configuration based on the third criticality level. Figure 1 The network. Detailed Implementation

[0022] This invention defines different criticality levels for the network and corresponding configurations on all configurable ECUs based on different operating scenarios. The configurations reference a predefined flow configuration table associated with each criticality level.

[0023] The following paragraphs provide examples of criticality levels and associated configurations:

[0024] The first criticality level (level 0, normal scenario) represents the normal scenario, in which all critical and non-critical data streams are transmitted without restriction.

[0025] The second criticality level (Level 1) is identified when the latency of a critical data stream exceeds a certain threshold. This criticality level leads to the removal of several non-critical data streams from the transmission, in order to provide more network resources for other data streams and improve latency performance.

[0026] The third criticality level (Level 2) is identified when frames are removed from buffer memory due to network congestion. This criticality level only allows critical data flows to pass through the Ethernet network, and copies of some critical data flows must be transmitted via access paths from redundant networks (such as CAN networks). This relates to the most severe level in the example and indicates environmental degradation.

[0027] The number of criticality levels and the expected delivery behavior at each level can be limited according to application requirements. The above limitations are merely non-limiting examples.

[0028] Based on each criticality level, each configurable device needs to configure a flow configuration table to define each path of the transmitted data flow.

[0029] Figure 1 The vehicle's data network is illustrated schematically. The network includes four devices (ECU1, ECU2, ECU3, ECU4).

[0030] The first device, ECU1, is, for example, an Ethernet converter (or router). This first device is directly connected to three other devices. The second device, ECU2, is, for example, a calculator dedicated to driver assistance functions. The third device is, for example, an antenna that enables the vehicle to communicate with external infrastructure, for example, via a wide area network of the Internet type. The fourth device, ECU4, is, for example, another computer in the vehicle.

[0031] The arrows numbered 1 to 10 represent data streams. A distinction is made between data streams corresponding to so-called critical applications (clear arrows, such as applications related to driver assistance functions) and data streams corresponding to so-called non-critical applications (black arrows, such as applications related to entertainment functions (e.g., music playback or movie playback)).

[0032] For example, when at criticality level 0, ECU2 transmits two critical Ethernet data streams (F1 and F2) and three non-critical Ethernet data streams (F3, F4 and F5) to ECU3 via ECU1, and transmits two non-critical CAN data streams (F6 and F7) directly to ECU3 via the CAN network.

[0033] In this example, the ECU2 flow configuration table associated with criticality level 0 is as follows:

[0034] [Table 1]

[0035] Key 0 CAN interface Ethernet interface F6 F1 F7 F2 F3 F4 F5

[0036] The table indicates which interface is used for each transmitted data stream. Each ECU can have different configuration strategies based on different criticality levels. Another example is ECU4, which has a critical data stream F8 and two non-critical data streams F9 and F10. ECU4 shares an Ethernet link with ECU1 and does not have a CAN network interface.

[0037] The configuration table for ECU 4 flow at Critical Level 0 is similar to the following table:

[0038] [Table 2]

[0039] Key 0 Ethernet interface F8 F9 F10

[0040] The change in the criticality level is managed by a specific computer (called a monitor) and is based on monitoring of network performance.

[0041] The monitor needs to monitor network performance (e.g., buffer memory latency or frame loss). To reduce and simplify the monitoring process and to ensure real-time processing, the monitor is preferably located in a central Ethernet device (e.g., a converter) that handles data traffic with different criticality levels.

[0042] Advantageously, the monitor monitors local network performance, rather than all Ethernet links. This means the monitor does not need to send additional data traffic to other Ethernet devices and does not need to wait for a response with latency associated with the monitoring. This also provides real-time, lightweight monitoring.

[0043] Based on the monitored network performance, the monitor determines the network's criticality level during execution. In the event of a change in criticality level, the monitor sends a configuration frame to the affected devices to notify them of the change. The transmission of the configuration frame can be performed using standard communication protocols such as MQTT, WebSocket, SOME / IP, DDS, HTTP, etc. No additional development for the communication protocol is required.

[0044] If a detected surveillance exceeds a time limit and the surveillance decides to change the network's criticality level from 0 to 1, the monitor then sends a configuration frame to all other devices with flow configuration tables. This configuration frame carries information about the criticality level (critical element 1). When a device receives a configuration frame indicating a change in criticality level, the device reconfigures the data flow transmission based on a predefined flow configuration table associated with the received criticality level.

[0045] This invention enables the device to distinguish between critical and non-critical data streams within the transmitted data stream. This distinction is expressed at the location of the stream configuration table. The stream configuration table is predefined (in other words, hard-coded) to accelerate processing time. For example, if the redundant backup network is a CAN network, the execution of the CAN communication software stack (pile) takes into account the Ethernet critical data stream (which can be transmitted by the CAN backup network at a higher criticality level). In the above example of the ADAS device, data streams F1 and F2 are Ethernet data streams. However, since their copies can be transmitted by the CAN network at a higher criticality level, these copies need to be implemented in the CAN communication software stack.

[0046] Figure 2 The data stream transmission is shown after the criticality level becomes 1. To improve the network performance (especially in terms of latency), data stream transmissions F5 and F10 have been removed.

[0047] The ECU2 flow configuration table for Critical Level 1 is similar to the following table:

[0048] [Table 3]

[0049] Key 1 CAN interface Ethernet interface F6 F1 F7 F2 F3 F4

[0050] The ECU 4-flow configuration table for Critical Level 1 is similar to the following table:

[0051] [Table 4]

[0052] Key 1 Ethernet interface F8 F9

[0053] In the same example, if the monitor detects frame deletion due to a buffer memory overflow, the monitor decides to change the network's criticality level from 1 to 2. The monitor then sends a configuration frame to all other devices with flow configuration tables, the configuration frame carrying information about the criticality level (Level 2). When a device receives the configuration frame for the criticality level change, the device reconfigures the data flow transmission based on a predefined table associated with the criticality level.

[0054] Figure 3 The diagram illustrates the transmission of data streams after the criticality level becomes 2. In degraded environments, due to frame loss, in addition to the deletion of non-critical data stream transmissions, for security reasons, copies of some critical data streams (ADAS) are transmitted via another network of a different network type than Ethernet. In this example, a copy of data stream F1 is transmitted via a CAN network.

[0055] The ECU2 flow configuration table for Critical Level 2 is similar to the following table:

[0056] [Table 5]

[0057] Key 2 CAN interface Ethernet interface F1 F1 F6 F2 F7

[0058] The ECU 4-flow configuration table for Critical Level 2 is similar to the following table:

[0059] [Table 6]

[0060] Key 2 Ethernet interface F8

[0061] This invention provides dynamic, lightweight management of critical data stream transmission to ensure quality of service in vehicular networks with different characteristics.

[0062] This invention is not limited to CAN networks or Ethernet networks; it can relate to any other network (e.g., FlexRay or LIN).

[0063] The monitoring application of the first device is at the application level of the ISO model.

[0064] The predefined table for the second device is applied at the data link level (i.e., Layer 2) of the ISO model.

Claims

1. A data network installed in a vehicle, the data network comprising a first device (ECU1) and at least one second device (ECU2, ECU3, ECU4), the first device and the at least one second device being connected via at least one data link of the data network, the first device (ECU1) and the at least one second device (ECU2, ECU3, ECU4) being capable of transmitting multiple data streams (F1, ..., F10), characterized in that: - The first device (ECU1) is configured to determine a criticality level based on network monitoring data and transmit the criticality level to the second devices (ECU2, ECU3, ECU4). - The second device (ECU2, ECU3, ECU4) is configured to load a predefined flow configuration table associated with the criticality level in response to the receipt of the criticality level. The predefined flow configuration table indicates which data streams are transmitted by the second device (ECU2, ECU3, ECU4), wherein the second device (ECU2) includes multiple interfaces, and the configuration table indicates which interface transmits which data stream for a given criticality level.

2. The data network of claim 1, wherein, The first device (ECU1) is a conversion device, which includes multiple data links.

3. The data network of claim 1 or 2, wherein, The network monitoring data comes from the local network of the first device (ECU1).

4. The data network according to claim 1 or 2, wherein the data network includes at least one data link, the at least one data link being selected from: CAN, Ethernet, FlexRay or LIN.

5. A vehicle comprising a data network according to any one of claims 1 to 4.

Images