WO2023036494A1 - Steuervorrichtung und verfahren zum steuern eines datenverkehrs eines fahrzeugs und fahrzeugsystem - Google Patents

Steuervorrichtung und verfahren zum steuern eines datenverkehrs eines fahrzeugs und fahrzeugsystem Download PDF

Info

Publication number
WO2023036494A1
WO2023036494A1 PCT/EP2022/069073 EP2022069073W WO2023036494A1 WO 2023036494 A1 WO2023036494 A1 WO 2023036494A1 EP 2022069073 W EP2022069073 W EP 2022069073W WO 2023036494 A1 WO2023036494 A1 WO 2023036494A1
Authority
WO
WIPO (PCT)
Prior art keywords
capacity
functional
signal
future
data
Prior art date
Application number
PCT/EP2022/069073
Other languages
English (en)
French (fr)
Inventor
Johannes Morgenroth
Philip Wette
Original Assignee
Robert Bosch Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch Gmbh filed Critical Robert Bosch Gmbh
Priority to CN202280074241.3A priority Critical patent/CN118202704A/zh
Publication of WO2023036494A1 publication Critical patent/WO2023036494A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/26—Resource reservation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0226—Traffic management, e.g. flow control or congestion control based on location or mobility
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices

Definitions

  • the invention is based on a control device and a method for controlling data traffic of a vehicle and a vehicle system according to the species of the independent claims.
  • Various software functions can be distributed in a vehicle, which can be executed while driving and can define specific requirements for communication with remote stations external to the vehicle. If the current driving situation of the vehicle changes, it may be necessary to reallocate the available network resources to different vehicle sensors.
  • control device By means of the control device presented here, compliance with the communication requirements of the software components in a Vehicle are running, be optimized. Overload situations can be avoided and vehicle and mobile phone resources can be conserved.
  • resource distribution can be specifically influenced in order to prioritize important functions and prevent individual applications from starving. Starvation can be understood to mean that, due to prioritization, an individual application is no longer used at all and is thus effectively deactivated.
  • a control device for controlling data traffic generated by functional units of a vehicle via a radio device of the vehicle includes a functional interface for connecting the control device to a first functional unit and a second functional unit and for reading in a first request signal, which represents a first requirement of the first functional unit for a future required capacity for data traffic to transmit first functional data, and a second one Request signal that represents a second requirement of the second functional unit to a future required capacity for data traffic to transmit second functional data.
  • the control device has a transmission interface for connecting the control device to the radio device.
  • control device comprises a determination device, which is designed to use a network signal, which represents a maximum capacity for data traffic along a probable future route of the vehicle and is dependent on radio network coverage, the first request signal and the second request signal to determine a first to determine a capacity signal that represents a first partial capacity that will be available in the future for the first functional unit, and to determine a second capacity signal that represents a second partial capacity that will be available in the future for the second functional unit, in order to allow the functional units to adapt the capacities required in the future to the partial capacities that will be available in the future make possible.
  • a network signal which represents a maximum capacity for data traffic along a probable future route of the vehicle and is dependent on radio network coverage
  • control device can be designed to determine the capacity signals using a route signal that represents the probable future route of the vehicle. Identifying a Channel capacity can thus take place with or without a route signal, for example directly from a “short-term prediction” or directly from the mobile operator.
  • distributed software can be executed in vehicle devices, the functional units of which can define different requirements for communication, such as data rate, latencies, maximum jitter, acceptable packet loss rate, etc., with remote stations external to the vehicle. These requirements can then be recorded at a central point in the vehicle and used to distribute the communication resources available to the vehicle, such as communication via one or more radio networks, for example LTE mobile radio networks or WLAN networks, to the individual software components in such a way that that the individual requirements of all components can be served in their entirety in the best possible way.
  • Said capacity can be a transmission capacity of a transmission channel via which the data traffic is sent. Examples of requirements made by a software component can be, for example:
  • a file download from the URL www.my.url/file.zip will start in 5 seconds.
  • the file size is 50MB. This download must be completed in 300 seconds at the latest.
  • the video stream from 10.0.1.2:17236 to 1.2.3.4:5000 needs less than 100ms latency. It is a constant data rate stream that is transmitted at either 3MBit/s (high quality) or IMBit/s (low quality).
  • the requirements can also be far more complex. If it is known which route the vehicle will most likely take, for example because navigation to a specific destination is active or a most probable route, also known as Most Probable Path (MPP), has been learned, it can also be estimated at any point in time in the future which properties, such as maximum data rate, packet loss rate, latency, jitter, etc., the radio transmission from or to the vehicle can have. With this estimate, along with those provided by the components Requirements for the communication can not only be carried out an optimal distribution of the communication resources to the individual functional units, it can also be determined whether and when the requirements can probably be met.
  • MPP Most Probable Path
  • This information can then be returned to the functional units, so that they can know in advance when their requirements need to be adjusted, or when they can expect which properties of the communication.
  • the functional units can thus advantageously initiate measures at an early stage in order to continue to work correctly. Without such an optimal distribution, the system performance could deviate from the optimal operating point. In concrete terms, either the available capacity could not be used although the system would be able to achieve better performance, or an overload could be created at the bottleneck, usually the cellular modem. The latter would be particularly fatal. Because an overload of the data rate could have a negative impact on other channel properties such as latency, jitter and packet loss. With the control device presented here, such packet losses can advantageously be minimized or completely avoided.
  • the central component that calculates the optimal distribution of communication resources can be enabled by the proposed method to control the so-called quality of service for all functions performed in the vehicle, to influence it positively and even to prioritize individual data streams .
  • This can be done, for example, by a weighting function that can change dynamically depending on time or user needs. Due to the technical proximity to mobile radio technologies, implementation on a connectivity control unit (CCU) is appropriate for such a control device.
  • CCU connectivity control unit
  • the determination device can be designed to calculate an allocation of the partial capacities for the data traffic to the functional units and to provide the capacity signals to the functional units via the functional interface. For example, using the request signals and calculate the route signal which capacitive power can be available for the individual functional units during a future section of the route of the vehicle.
  • the control device can be relieved overall as a result. If the applications know in advance when they are allowed to send how much data, the buffers can be smaller, for example. In addition, the execution of possibly CPU-intensive QoS algorithms for classifying and prioritizing traffic can be reduced or completely avoided. In addition, the so-called buffer bloat problem in long-distance networks can be countered by allocating partial capacities that will be available in the future.
  • a buffer bloat occurs when packets accumulate at an Internet router. So-called buffers fill up until the router finally has no choice but to discard packets. In the light case, this only increases the communication latency. Most of the time, however, it doesn't stay that way and packet loss is inevitable. This problem can always arise when more data arrives at a router than can be sent. This effect can already occur in the vehicle. Inbound, the cellular base can be the router. It can be the CCU or the modem it contains, and all devices connected to it can produce data packets according to a pattern that is difficult to predict. In order to avoid an overload and thus to keep properties such as latency and packet loss constant, the control device presented here can already take into account the respective quantity when generating the data packets.
  • the determining device can be designed to read in the route signal via the functional interface.
  • the control device can be connected via the function interface to a navigation device for navigating the vehicle.
  • the navigation device can be designed to calculate a current route for the vehicle to a specific destination and to provide it in the form of the route signal. Additionally or alternatively, a probable route, also called Most Probable Path (MPP), may have been learned.
  • MPP Most Probable Path
  • the determination device can use the route signal to determine the future route of the Identify the vehicle at an early stage and adjust the generated data traffic accordingly.
  • the determination device can be designed to read in the network signal, which represents a maximum capacity for data traffic along the route and is dependent on radio network coverage, via the transmission interface.
  • the network signal can be provided via the radio device connected to the control device.
  • the radio device can be designed to detect the radio network coverage along the route and to provide it to the determination device using the network signal.
  • this makes it possible to optimally calculate the point in time at which a specific size of capacity for the data traffic for functional units of the vehicle can be available.
  • the determination device can include an optimization device, which can be designed to calculate the first partial capacity and the second partial capacity using the route signal, the network signal, the first request signal and the second request signal and to assign the partial capacities to the functional units.
  • the optimization device which can also be referred to as an optimizer, can receive data about what properties (data rate, latency, etc.) the radio connection will have in the future. This can be achieved, for example, by combining a calculated MPP (Most Probable Path) and a cellular coverage map.
  • MPP Mobile Packed Probable Path
  • the optimizer can get all the requirements of the software components for their data flows. Based on this, the optimizer can calculate how and when the available resources are divided between the different data flows.
  • This allocation can be calculated, for example, by optimizing an objective function.
  • This target function can, for example, link, weight and prioritize the different requirements.
  • This target function can be chosen arbitrarily by the optimizer and, in particular, can also change over time in order to be able to express the changing importance and urgency of individual functions.
  • the allocation of resources to data streams can be calculated in different ways using the target function.
  • a rigorous mathematical description and subsequent optimal solution using linear programming can be used.
  • heuristics or approximations can also be used for the calculation.
  • the control device can be optimally implemented using an optimization device.
  • the optimization device can be designed to compare the route with a mobile radio coverage map provided by the transmission interface and depicting the radio network coverage, in order to determine a time profile of the size of the future maximum capacity for the data traffic.
  • the cellular coverage map may be a cloud service that provides predictions of expected connection characteristics at a location at a specific time.
  • MPP most probable route
  • the connection properties to be expected such as maximum data rate, packet loss rate, latency, jitter, etc.
  • methods such as predictive quality of service (pQoS) or a local short-term prediction for the communication channel can also be used.
  • the determination device can include a prognosis device, which can be designed to provide the first and the second capacity signal.
  • the predictor which can also be referred to as the predictor, can get the computed result of the optimizer and distribute it to those functional units that have made requests. These functional units can advantageously deduce from this at what time an adjustment of their own data flows is necessary in order to achieve optimal performance.
  • the determination device can be designed to receive a first function signal, which includes the first function data, and a second function signal, which includes the second function data Read in the function signal via the function interface and make it available to the transmission interface.
  • the determination device can include a traffic shaping device which can be designed to output the first function data using the first capacity signal and the second function data using the second capacity signal via the transmission interface.
  • the traffic shaper can also be referred to as traffic shaping or queue management.
  • the traffic shaping can get information about how the individual data flows should be treated by the optimizer.
  • the traffic shaping device can be designed to shape the data flows according to a calculated schedule. For example, if there is so-called legacy software in the vehicle that has not made any demands on the determination device, it can be assumed, for example, that this software has a lower priority than the software that made demands. As a result, the legacy software can only use the remaining communication resources that remain after this process. This is enforced through the process of traffic shaping.
  • the generated data traffic can be shaped according to a currently available capacity.
  • the first requirement and additionally or alternatively the second requirement can comprise a utility function, with the utility function describing the utility of certain properties of the data traffic.
  • the requirements of the functional units can be expressed in the form of utility functions via communication properties.
  • the utility functions provided by the respective functional unit can be multidimensional, for example. The dimensions used and their number can be arbitrary.
  • the utility functions can be used to map the utility experienced by the entity from the communication.
  • the functional units can, for example, proactively state their requirements for future communication properties in Communicate the form of utility functions both to the CCUs installed in the vehicle and to the other software applications running in the vehicle. Utility functions can change over time.
  • an application can, for example, have a different utility function for a time segment to -ti than for a time segment ti - tj.
  • an application X may require map data to run.
  • This map data can be available on an external server in two qualities: high and low.
  • with high quality can have a large file size s Hl , but X allow to work in full functionality.
  • the low quality M Lo map may have a small file size s Lo but only allow limited functionality of X. The download of the map should be completed at a time t + öt, since X needs the data at this point.
  • an average data rate of s Hl / öt may be required for application X in the next öt seconds.
  • an average data rate of s Lo / öt may be required for application X in the next öt seconds. This can be included in the utility function for application X.
  • the utility function can be determinable using an allocation plan. For example, as soon as several functional units in the sense of a distributed system offer a service whose quality can depend on the utility of its individual components, defining the corresponding utility functions, for example manually, can be very time-consuming. It is therefore also possible to generate such dependent utility functions from an allocation plan.
  • An allocation plan to a distributed system can indicate how resources should be allocated to individual data streams so that the distributed system as a whole can provide some benefit.
  • a utility function can now also be defined for an allocation plan, which in turn calculates the utility of the distributed system can specify.
  • utility functions can thereby be generated in a time-saving manner.
  • the first request and additionally or alternatively the second request can include an expiration time for defining an end time of the transmission of functional data.
  • a functional unit request may be that a software download or software upload should be completed by a specific time.
  • the determination device can advantageously be used to carry out an optimal prioritization for the allocation of partial capacities to the individual functional units.
  • a vehicle system that has a variant of the previously presented control device.
  • the vehicle system includes a plurality of functional units that are designed to provide request signals that represent the requirements of the functional units for a capacity of data traffic required in the future for transmitting functional data, to receive capacity signals that represent partial capacities available for the functional units in the future, and to provide functional signals , which represent the function data.
  • the vehicle system also includes a radio device, which has at least one means of communication for sending and receiving data via a radio network, a radio interface for connecting the means of communication to the radio network, and a transmission interface for connecting the radio device to the control device, the radio device being designed to transmit function signals read in via the transmission interface.
  • a radio device which has at least one means of communication for sending and receiving data via a radio network, a radio interface for connecting the means of communication to the radio network, and a transmission interface for connecting the radio device to the control device, the radio device being designed to transmit function signals read in via the transmission interface.
  • a means of communication can be understood as an interface, such as an LTE modem.
  • the radio network can be understood to mean, for example, a mobile radio network or a WLAN network.
  • a method for controlling data traffic generated by functional units of a vehicle via a radio device of the vehicle is presented.
  • the method comprises a step of reading in a first request signal and a second request signal via a function interface to a first functional unit and a second functional unit, the first request signal representing a first request from the first functional unit to a future required capacity for data traffic to transmit first functional data and the second request signal represents a second request from the second functional unit for a future required capacity for the data traffic for the transmission of second functional data.
  • the method includes a step of determining a first capacity signal and a second capacity signal, optionally using a route signal that represents a probable future route of the vehicle, a network signal that has a maximum capacity along the route and is dependent on radio network coverage represents data traffic, the first request signal and the second request signal, the first capacity signal representing a first partial capacity that will be available in the future for the first functional unit, and the second capacity signal representing a second partial capacity that will be available in the future for the second functional unit, in order for the functional units to adapt the future required capacity To enable capacities to the partial capacities that will be available in the future.
  • the central component that calculates the optimal distribution of the communication resources is advantageously enabled by the proposed method to control the quality of service for all functions performed in the vehicle, to influence it positively and even to prioritize individual data streams.
  • This method can be implemented, for example, in software or hardware or in a mixed form of software and hardware, for example in a control unit.
  • a computer program product or computer program with program code which can be stored on a machine-readable carrier or storage medium such as a semiconductor memory, a hard disk memory or an optical memory and for carrying out, implementing and/or controlling the steps of the method according to one of the embodiments described above, is also advantageous used, especially when the program product or program is run on a computer or device.
  • FIG. 1 shows a block diagram of a control device according to an embodiment
  • FIG. 2 shows a block diagram of a vehicle system according to an embodiment
  • FIG. 3 shows a diagram of an embodiment of a utility function
  • FIG. 5 shows a diagram of an exemplary embodiment of a further multidimensional utility function
  • FIG. 6 is a diagram of an allocation plan according to an embodiment
  • FIG. 7 is a diagram of another utility function according to an embodiment
  • FIG. 8 is a diagram of an embodiment of a utility function
  • 9 shows a flowchart of a method for controlling data traffic generated by functional units of a vehicle according to an embodiment
  • FIG. 11 shows a flowchart of an embodiment of a step of the method for controlling data traffic.
  • Control device 100 is designed to control data traffic generated by functional units 105, 110 of a vehicle 115 via at least one radio device 120 of vehicle 115.
  • the vehicle 115 is configured as an automated vehicle or an automated vehicle that can be controlled by a driver who is outside the vehicle 115 .
  • the vehicle 115 can be a non-automated vehicle or a vehicle that is only partially automated.
  • compliance with various communication requirements of software components of the vehicle 115 is particularly relevant in order to avoid overload situations in data traffic and to conserve vehicle and mobile phone resources.
  • the control device 100 can be used to influence the resource distribution in a targeted manner in order to prioritize important functions and prevent individual applications from starving.
  • the control device 100 includes a functional interface 125 for connecting the control device 100 to a first functional unit 105 and a second Functional unit 110.
  • the functional units 105, 110 which can also be referred to as software functions or software modules, are designed in this exemplary embodiment to communicate by means of the control device 100 with communication partners external to the vehicle.
  • a first request signal 130 can be read in via the functional interface 125, which represents a first requirement of the first functional unit 105 for a future required capacity for data traffic to transmit first functional data.
  • a second request signal 135 can be read in, which represents a second request from the second functional unit 110 for a future required capacity for the data traffic for the transmission of second functional data.
  • the first request is a video stream that can be transmitted to the driver outside the vehicle 115 in order to enable so-called tele-operated driving.
  • the second requirement is the reloading of highly up-to-date map sections that are required for automatic driving.
  • the second requirement includes, merely by way of example, an expiration period for defining an end point in time for the transmission of functional data.
  • this expiry period which can also be referred to as a deadline, indicates that the loading of the card data must be completed by a specific point in time.
  • control device can also be used, for example, to control the monitoring of automatically driving vehicles or to regulate other external intervention options in order to optimally control the vehicle remotely. This requires a reliable cellular-based function to give the vehicle 115 the appropriate command.
  • control device 100 has a transmission interface 140 for connecting the control device 100 to the at least one radio device 120 .
  • the at least one radio device 120 enables communication with external participants via a radio network. Since the probable course of the route is also important for the optimal control of vehicle 115, in one exemplary embodiment control device 100 is designed to read in a route signal 145 via function interface 125, which represents a probable future route 146 of vehicle 115. For this purpose, control device 100 is connected to a navigation device 147 via functional interface 125, which is designed to calculate probable route 146 of vehicle 115 to a specific destination using map data stored in navigation device 147. In another exemplary embodiment, a probable route, also called Most Probable Path (MPP), can also have been learned.
  • MPP Most Probable Path
  • the control device 100 is designed in this exemplary embodiment to read in a network signal 150 via the radio interface 140, the network signal 150 representing a maximum capacity for data traffic along the route 146 and dependent on radio network coverage.
  • the radio device 120 receives a radio signal 155 by means of radio masts 157 arranged along the route 146. Since the probable route 146 of the vehicle 115 is therefore known, the network signal 150 can be used to estimate properties such as maximum data rate, packet loss rate, latency or jitter, which will have a radio transmission from or to the vehicle 115, is possible at any point in time in the future.
  • the control device 100 is designed to determine a first capacity signal 165 and a second capacity signal 170 using the route signal 145, the network signal 150, the first request signal 130 and the second request signal 135 by means of a determination device 160.
  • the first capacity signal 165 represents a first partial capacity that will be available in the future for the first functional unit 105
  • the second capacity signal 170 represents a second partial capacity that will be available in the future for the second functional unit 110 .
  • the control device 100 is designed to determine the capacity signals without using the route signal 145 .
  • the determination device 160 is designed to calculate an allocation of the partial capacities for the data traffic to the functional units 105 , 110 and to provide the capacity signals 165 , 170 to the functional units 105 , 110 via the functional interface 125 .
  • the determination unit 160 is designed to inform the functional units 105, 110 whether and when their communication requirements will be met in the future, so that they can proactively adjust their behavior accordingly. This enables an early prediction as to when functions in the vehicle 115 that depend on communication with external participants are no longer available and allows the functional units 105, 110 to adapt the capacities required in the future to the partial capacities that will be available in the future.
  • the functional units 105, 110 in this exemplary embodiment are designed to provide a first functional signal 180 comprising the first functional data and a second functional signal 185 comprising the second functional data.
  • the control device 100 is designed to read in these function signals 180 , 185 via the function interface 125 and to make them available to the transmission interface 140 .
  • the two functional units 105, 110 are only shown as examples.
  • Corresponding further functional units can be connected to the control device 100 and the data traffic generated by these further functional units can be controlled in a corresponding manner using the control device.
  • FIG. 2 shows a block diagram of a vehicle system 200 according to an embodiment.
  • the vehicle system 200 is applicable in a vehicle as described in the previous figure and comprises a control device 100 corresponding or similar to the control device described in the previous figure.
  • vehicle system 200 includes a plurality of functional units 105, 110, 205.
  • Functional units 105, 110, 205 are designed to provide request signals, the requirements of the functional units 105, 110, 205 to a future required capacity of data traffic to transmit functional data.
  • functional units 105, 110, 205 are designed to receive capacity signals that represent partial capacities available for functional units 105, 110, 205 in the future.
  • functional units 105, 110, 205 are designed to provide functional signals that represent the functional data.
  • the vehicle system 200 has a radio device 120 .
  • the radio device 120 includes a means of communication 210, for example a modem, for sending and receiving data via a radio network 215, for example a mobile network, and a radio interface 220 for connecting the means of communication 210 to the radio network 215.
  • the means of communication 220 is only an example as an LTE Modem trained and connected to the Internet 222 via a radio mast 157, which can also be referred to as a mobile radio base station.
  • radio device 120 is connected to control device 100 via transmission interface 140 , radio device 120 being designed to read in function signals via transmission interface 140 .
  • control device 100 which can also be referred to as a connectivity control unit (CCU)
  • CCU connectivity control unit
  • All of the vehicle's data traffic with communication partners 225 external to the vehicle runs via the CCU in order to carry out software uploads or software downloads, for example.
  • the determination device 160 of the control device 100 comprises an optimization device 230, which is designed to use the optional route signal, the network signal, the first request signal and the second request signal to calculate the first partial capacity and the second partial capacity and to calculate the partial capacities for the functional units 105, 110, 205.
  • the optimization device 230 which can also be referred to as an optimizer, receives data about which properties, for example with regard to data rate, latency, etc., the radio link will have in the future.
  • Optimization device 230 is designed to compare the probable route of the vehicle with a mobile radio coverage map 235 that is provided by transmission interface 140 and depicts the radio network coverage, in order to determine a time profile of the size of the future maximum capacity for data traffic.
  • the cellular coverage map 235 is a cloud service that provides predictions of expected connection characteristics at a location at a specific time.
  • the connection properties to be expected along the route of the vehicle can thus be retrieved with the aid of the most probable route MPP.
  • the probable route can be determined using the navigation device 147 .
  • the optimization device 230 receives all the requirements of the software components for their data flows. On this basis, the optimization device 230 calculates how and when the available resources are divided between the different data flows. In this exemplary embodiment, this allocation can be calculated by optimizing a target function. This target function links, weights and prioritizes the different requirements (utility functions) of the functions with one another.
  • the optimization device 230 is designed to select this target function arbitrarily, with the target function being changeable over time in order to express the changing importance and urgency of individual functions.
  • the allocation of resources to data streams can be calculated in different ways using the objective function.
  • the optimization device 230 in this exemplary embodiment is designed purely by way of example in order to use a rigorous mathematical description and subsequent optimal solution by means of linear programming. In another exemplary embodiment, heuristics or approximations can also be used for the calculation in addition or as an alternative.
  • the route with the mobile radio coverage map 235 By comparing the route with the mobile radio coverage map 235, it is possible to estimate at any point in time in the future which properties, such as maximum data rate, packet loss rate, latency or jitter, the radio transmission from or to the vehicle will have.
  • methods such as predictive quality of Service (pQoS) or a local short-term prediction can be used for the communication channel.
  • pQoS predictive quality of Service
  • a local short-term prediction can be used for the communication channel.
  • this information can be made available to functional units 105, 110, 205 by means of a prognosis device 240 using capacity signals, so that they know in advance when their requirements need to be adjusted, or when they can expect which properties of the communication.
  • the prognosis device 240 which can also be referred to as a prognosis, receives the calculated result from the optimization device 230 and distributes it to those software modules that have made requirements. From this, these software modules can derive when an adjustment of their own data flows is necessary in order to achieve optimal performance. This enables the functional units 105, 110, 205 to initiate measures at an early stage in order to continue to work correctly. Without such an optimal distribution, the system performance moves away from the optimal operating point.
  • either the available capacity is not used, although the system would be able to achieve better performance, or an overload is created at the bottleneck, usually the mobile radio modem. The latter is particularly fatal. Because overloading the data rate has a negative impact on other channel properties, such as latency, jitter and packet loss.
  • the determination device 160 includes, in addition to the optimization device 230 and the forecast device 240, a traffic shaping device 250 which is designed to output the first function data using the first capacity signal and the second function data using the second capacity signal via the transmission interface 140.
  • the traffic shaper 250 may also be referred to as traffic shaping or queue management become.
  • the traffic shaper 250 gets information about how the individual data flows should be treated by the optimizer.
  • traffic shaping the communication resources of the vehicle can be used in the best possible way (in terms of the requirements).
  • the actual traffic shaping is outsourced, ie it is away from the router and towards the application or the communication libraries used in it, such as the transport layer protocols QUI IC or TCP, just for example.
  • the system can also be connected to a number of mobile radio networks and WLAN networks at the same time.
  • the CCU can have connections to several LTE modems and additional or alternative WLAN cards.
  • each software component can calculate the optimization locally.
  • each software function can have its own traffic shaping, so that functions cannot send more data to the CCU than defined by the calculated schedule.
  • This traffic shaping can be implemented directly in the software stack of the transport protocol used, such as TCP, UDP or QUIC. This would result in far less data accumulating on the CCU, since the applications themselves only generate or request as much data as can be exchanged with the mobile phone connection.
  • the computing load on the CCU which is caused by traffic shaping, is also significantly reduced.
  • the schedule can also be calculated in a vehicle-external component, for example in the cloud.
  • FIG. 3 shows a diagram of an exemplary embodiment of a utility function 300, with the data rate plotted on the x-axis in M bits/s and the utility on the y-axis.
  • Functional unit requirements may contain utility functions that determine the utility of certain properties for the describe functional units.
  • the benefit function 300 shown here describes that the communication with the external communication partner in the upload must be at least 2 Mbit/s (otherwise the benefit is 0) and no additional benefit can be drawn from it if more than 5 Mbit/s is available. Between 2 MBit/s and 5 MBit/s, the benefit for the function increases linearly.
  • Software functions can use any utility functions to describe the communication requirements. Utility functions can depend not only on the data rate, but also on latency, jitter, packet loss, etc. The utility functions thus become multidimensional. If the benefit for an implemented communication property is zero, the corresponding requirement is considered not to have been met.
  • multidimensional utility functions UA, UB can be used to express the rivalry between these applications.
  • These multidimensional functions have an axis for utility, represented as the y-axis in the figures shown here, and an axis for each resource (data rate, latency, error rate, etc.). In the figures shown here, the data rate is shown on the x-axis.
  • an additional axis is introduced in this exemplary embodiment in order to connect two utility functions with one another.
  • FIG. 4 describes the utility function UA of a front camera
  • FIG. 5 describes the utility function UB of a rear camera purely as an example, all of which require a specific data rate for the distributed application to function.
  • Each sensor requires a certain amount of data rate to function properly, and the application is only of any use if each sensor is allocated a certain fraction of the data rate.
  • at least 4 Mbit/s are required for the front video and at least 0.5 Mbit/s for the rear video.
  • the front and rear video may be combined using separate and non-dependent two-dimensional utility functions for each sensor Uf rO nt and U re ar and then, for example, a third utility function for the overall application.
  • the third utility function can be in 3D, with a utility axis, an axis Uf rO nt and an axis U re ar. But in this case, a single sensor can't be of much use because it's useless without the other. Therefore, these sensor-independent utility functions cannot really be used alone in the optimizer because their utility is not "real". They should be connected by the utility function of the overall application.
  • FIG. 6 shows a diagram of an allocation plan 600 according to an embodiment.
  • An allocation plan for a distributed system specifies how resources must be distributed to individual data streams so that the distributed system as a whole can provide a certain benefit.
  • Such a plan can be seen as an example in the figure shown here for three different data streams. This is merely an example of an allocation plan 600 for three sensors 605, 610, 615, or the distribution of the available data rate over three data streams.
  • the plan includes three different sensors and defines how much data rate is allocated to each sensor (y-axis) given a certain amount of data rate available to the application (x-axis). For example, if the application gets a total of 4 Mbit/s data rate, all 4 Mbit/s are assigned to the first sensor 605. However, if the application gets 5 Mbit/s, 4.5 Mbit/s is assigned to the first sensor 605 and 0.5 Mbit/s to the second sensor 610, just by way of example. In the figure shown here only the available data rate is shown, but the same principle can also be used in a multi-dimensional case, for example with data rate, latency and bit error rate.
  • Allocation plans generally solve the problem of allocating available resources to a known set of data-generating entities, such as sensors or data storage. However, they cannot be used unless all consumers are known in advance, that is, in a system where several different applications are used that are not from the same developers, or where new applications come and go over time.
  • Utility functions can be generated from an allocation plan.
  • the definition of an allocation plan for two sensors, for example, and the resulting utility function for an application can be started.
  • Linear utility functions can then be created for each sensor separately by assigning an artificial utility to each assigned data rate.
  • the benefit of an allocated data rate can be defined, for example, by the allocated data rate itself divided by the maximum allocated data rate for that particular sensor.
  • FIG. 7 shows a diagram of another utility function 700 according to an embodiment.
  • the other utility function 700 shown here can only be defined as an example for an allocation plan, as was described in the previous FIG. 6, and indicates the utility of the distributed system.
  • the benefit is shown on the y-axis and the data rate on the x-axis.
  • FIG. 8 shows a diagram of an exemplary embodiment of a utility function 300.
  • the utility function 300 shown here corresponds or is similar to the utility function described in the previous FIG. 3, with the difference that the utility function 300 shown here is only shown in three dimensions as an example.
  • the benefit is given on the z-axis, the packet error rate on the x-axis and the data rate on the y-axis.
  • the dimensions used and their number can be arbitrary. These can be used to map the benefit experienced by the application from the communication.
  • video and audio codecs can allow video and audio to be encoded at different data rates.
  • the lower the data rate the lower the quality or the benefit of the video.
  • this relationship is by no means linear.
  • some codecs may contain redundancies, allowing them to deal with packet loss. But here, too, losses in audio or video quality are to be expected in the event of packet loss.
  • a video telephony application can have multiple codecs or multiple configurations of the same codec, each of which can handle different communication conditions and can be switched at runtime.
  • the resulting utility function can be very application-specific and also depend on which of the available codecs are also supported by the other terminal. A meaningful optimization of the allocation of communication resources to applications cannot take place without knowledge of this utility function.
  • FIG. 9 shows a flow diagram of a method 900 for controlling data traffic according to an embodiment. Acts solely as an example it is an iterative process that runs in several steps 905, 910, 915, 920, 925, 930.
  • a first request signal and a second request signal are read in via a functional interface to a first functional unit and a second functional unit.
  • the first request signal represents a first request from the first functional unit for a future capacity required for data traffic to transmit first functional data
  • the second request signal represents a second request from the second functional unit for a future required capacity for data traffic for transmitting second functional data.
  • requirements for the communication properties are collected from the software functions. In this exemplary embodiment, these requirements consist of deadlines and utility functions. In this case, not only the functions within the vehicle can make requirements, but also the communication partners outside the vehicle in which the control device is operated.
  • the step 905 of reading is followed by an optional step 910 of receiving a route signal.
  • the probable future route or the current MPP is received. This describes the path that the vehicle will take in the future.
  • the method 900 further includes a step 915 of reading in a network signal, which represents a size of a maximum capacity for the data traffic that exists along the route and is dependent on a radio network coverage.
  • a cellular coverage map along the MPP is queried.
  • the mobile radio coverage map provides a forecast of which communication properties, i.e. which available data rate, latency, packet error rate, jitter, etc., can be expected at each point of the MPP.
  • a step 920 of calculation follows, in which a schedule is calculated which specifies which software function is allowed to send or receive how much data via a modem, for example an LTE modem, at what time.
  • This schedule is calculated by way of example only in such a way that the target function selected by an optimization device of the control device is maximized.
  • the schedule is found in this exemplary embodiment by means of mathematical optimization.
  • the control device in this exemplary embodiment begins again with step 905 of reading in the first and second request signals.
  • the step 925 of determining and an exemplary step 930 of shaping are performed simultaneously.
  • step 925 of determining a first capacity signal and a second capacity signal are determined. The determining is performed using the optional route signal, the network signal, the first request signal, and the second request signal.
  • the first capacity signal represents a first partial capacity that will be available in the future for the first functional unit
  • the second capacity signal represents a second partial capacity that will be available in the future for the second functional unit, in order to enable the functional units to adapt the capacities required in the future to the partial capacities that will be available in the future.
  • each software component that has made requests is informed as to when it can expect which communication properties.
  • step 930 of shaping in this exemplary embodiment, a traffic shaper of the control device is instructed to shape the data flows according to the calculated schedule.
  • legacy software is located in the vehicle merely by way of example. If the legacy application generates a lot of data that cannot be transported due to the scarcity of resources, the generated data is discarded by traffic shaping.
  • FIG. 10 shows a flowchart of an embodiment of a step 905 of the method 900 controlling data traffic. Step 905 described here corresponds to or is similar to the step of reading in a request signal described in the preceding FIG. The reading step 905 shown here is divided into four sub-steps. In the first partial step 1000, the parameters of a vehicle-internal sensor are determined.
  • an internal, multidimensional utility function is determined from the parameters.
  • a specific request from a functional unit to a future required capacity for the data traffic for the transmission of functional data is created.
  • this requirement in the form of a requirement signal is read in by a determination device of the control device and a partial capacity corresponding to the requirement is calculated by an optimization device of the determination device.
  • the internal utility function has higher dimensions, some of these dimensions being so-called internal parameters, which are merely examples of the current driving speed and the distance to the nearest object.
  • Such internal utility functions are used to derive the actual utility functions that are passed to the central optimizer of the network system.
  • FIG. 10 shows a flowchart of an embodiment of a step 905 of the method 900 controlling data traffic.
  • Step 905 described here corresponds to or is similar to the step of reading in a request signal described in previous FIGS.
  • the internal utility function in this exemplary embodiment comprises three dimensions, one of which is the vehicle condition. Since the vehicle state is an internal parameter of the vehicle and outside the domain for the participatory network, the current vehicle speed is used to extract a two-dimensional utility function consisting of the utility and data rate axes, which is then passed to the central optimizer. Each time the vehicle speed changes, the vehicle sends an updated utility function to the optimizer.
  • n-dimensional internal utility functions and m-dimensional utility functions can be used in exemplary embodiments. In order not to send constantly updated utility functions to the optimizer, the application should only do so when the utility function update is significant.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Eine Steuervorrichtung (100) zum Steuern eines von Funktionseinheiten (105, 110) eines Fahrzeugs (115) generierten Datenverkehrs über eine Funkeinrichtung (120) umfasst eine Funktionsschnittstelle (125) zum Verbinden der Steuervorrichtung (100) mit Funktionseinheiten (105, 110) und zum Einlesen von Anforderungssignalen (130, 135), die Anforderungen der Funktionseinheiten (105, 110) an eine zukünftig benötigte Kapazität für den Datenverkehr zum Übertragen von Funktionsdaten repräsentiert. Zudem umfasst die Steuervorrichtung (100) eine Übertragungsschnittstelle (140) zum Verbinden der Steuervorrichtung (100) mit der Funkeinrichtung (120) und eine Bestimmungseinrichtung (160), die ausgebildet ist, um unter Verwendung eines Routensignals (145), eines Netzsignals (150) und der Anforderungssignale (130, 135) Kapazitätssignale (165, 170) zu bestimmen, die für die Funktionseinheiten (105, 110) zukünftig bereitstehende Teilkapazitäten repräsentieren.

Description

Beschreibung
Titel
Steuervorrichtung und Verfahren zum Steuern eines Datenverkehrs eines Fahrzeugs und Fahrzeugsystem
Stand der Technik
Die Erfindung geht von einer Steuervorrichtung und einem Verfahren zum Steuern eines Datenverkehrs eines Fahrzeugs sowie einem Fahrzeugsystem nach Gattung der unabhängigen Ansprüche aus.
In einem Fahrzeug können verschiedene Software- Funktionen verteilt sein, die während der Fahrt ausgeführt werden können und hierfür bestimmte Anforderungen an eine Kommunikation mit fahrzeugexternen Gegenstellen definieren können. Wenn sich die aktuelle Fahrsituation des Fahrzeugs ändert, kann eine Neuzuweisung der verfügbaren Netzwerkressourcen auf verschiedene Fahrzeugsensoren notwendig sein.
Offenbarung der Erfindung
Vor diesem Hintergrund werden mit dem hier vorgestellten Ansatz eine verbesserte Steuervorrichtung und ein verbessertes Verfahren zum Steuern eines Datenverkehrs eines Fahrzeugs sowie ein verbessertes Fahrzeugsystem gemäß den Hauptansprüchen vorgestellt. Durch die in den abhängigen Ansprüchen aufgeführten Maßnahmen sind vorteilhafte Weiterbildungen und Verbesserungen der im unabhängigen Anspruch angegebenen Vorrichtung möglich.
Mittels der hier vorgestellten Steuervorrichtung kann ein Einhalten der Kommunikationsanforderungen der Softwarekomponenten, die in einem Fahrzeug ausgeführt werden, optimiert werden. Dabei können Überlastsituationen vermieden sowie Fahrzeug- und Mobilfunkressourcen geschont werden. Außerdem kann gezielt Einfluss auf die Ressourcenverteilung genommen werden, um wichtige Funktionen zu priorisieren und ein Verhungern von einzelnen Anwendungen zu verhindern. Unter Verhungern kann dabei verstanden werden, dass auf Grund von Priorisierung eine einzelne Anwendung überhauptnichtmehr zum Zug kommt und dadurch faktisch deaktiviert wird.
Es wird eine Steuervorrichtung zum Steuern eines von Funktionseinheiten eines Fahrzeugs generierten Datenverkehrs über eine Funkeinrichtung des Fahrzeugs vorgestellt. Dabei umfasst die Steuervorrichtung eine Funktionsschnittstelle zum Verbinden der Steuervorrichtung mit einer ersten Funktionseinheit und einer zweiten Funktionseinheit und zum Einlesen eines ersten Anforderungssignals, das eine erste Anforderung der ersten Funktionseinheit an eine zukünftig benötigte Kapazität für den Datenverkehr zum Übertragen von ersten Funktionsdaten repräsentiert, und eines zweiten Anforderungssignals, das eine zweite Anforderung der zweiten Funktionseinheit an eine zukünftig benötigte Kapazität für den Datenverkehr zum Übertragen von zweiten Funktionsdaten repräsentiert. Zudem weist die Steuervorrichtung eine Übertragungsschnittstelle zum Verbinden der Steuervorrichtung mit der Funkeinrichtung auf. Weiterhin umfasst die Steuervorrichtung eine Bestimmungseinrichtung, die ausgebildet ist, um unter Verwendung eines Netzsignals, das eine entlang einer wahrscheinlichen zukünftigen Route des Fahrzeugs bestehende und von einer Funknetzabdeckung abhängige Größe einer maximalen Kapazität für den Datenverkehr repräsentiert, des ersten Anforderungssignals und des zweiten Anforderungssignals ein erstes Kapazitätssignal zu bestimmen, das eine für die erste Funktionseinheit zukünftig bereitstehende erste Teilkapazität repräsentiert, und ein zweites Kapazitätssignal zu bestimmen, das eine für die zweite Funktionseinheit zukünftig bereitstehende zweite Teilkapazität repräsentiert, um den Funktionseinheiten eine Anpassung der zukünftig benötigten Kapazitäten an die zukünftig bereitstehenden Teilkapazitäten zu ermöglichen.
Optional kann die Steuervorrichtung ausgebildet sein, um die Kapazitätssignale unter Verwendung eines Routensignals zu bestimmen, das die wahrscheinliche zukünftige Route des Fahrzeugs repräsentiert. Die Ermittlung einer Kanalkapazität kann somit mit als auch ohne Routensignal erfolgen, beispielsweise direkt aus einer „Kurzzeitvorhersage“ (Short-term prediction) oder direkt vom Mobilfunkbetreiber.
Beispielsweise kann in Einrichtungen des Fahrzeugs verteilte Software ausgeführt werden, deren Funktionseinheiten verschiedene Anforderungen an die Kommunikation, wie zum Beispiel Datenrate, Latenzen, maximaler Jitter, akzeptable Paketverlustrate, etc., mit fahrzeugexternen Gegenstellen definieren können. Diese Anforderungen können anschließend an zentraler Stelle im Fahrzeug erfasst und verwendet werden, um die dem Fahrzeug zur Verfügung stehenden Kommunikationsressourcen, wie zum Beispiel Kommunikation über ein oder mehrere Funknetze, beispielsweise LTE-Mobilfunknetze oder WLAN- Netze, so auf die einzelnen Softwarekomponenten zu verteilen, dass die individuellen Anforderungen aller Komponenten in ihrer Gesamtheit bestmöglich bedient werden können. Bei der genannten Kapazität kann es sich um eine Übertragungskapazität eines Übertragungskanals handeln, über den der Datenverkehr gesendet wird. Beispiele für Anforderungen, die von einer Softwarekomponente gestellt werden, können zum Beispiel sein:
Ein Dateidownload von der URL www.meine.url/datei.zip wird in 5 Sekunden starten. Die Dateigröße beträgt 50MB. Dieser Download muss in spätestens 300 Sekunden abgeschlossen sein.
Der Video-Stream von 10.0.1.2:17236 zu 1.2.3.4:5000 benötigt eine Latenz von weniger als 100ms. Es ist ein Stream mit konstanter Datenrate der entweder mit 3MBit/s (hohe Qualität) oder IMBit/s (niedrige Qualität) übertragen wird.
Die Anforderungen können jedoch auch weitaus komplexer sein. Ist bekannt, auf welcher Route das Fahrzeug höchstwahrscheinlich fahren wird, zum Beispiel, weil eine Navigation zu einem bestimmten Ziel aktiv ist oder ein wahrscheinlichsten Fahrtwegs, auch Most Probable Path (MPP) genannt, erlernt wurde, kann zusätzlich zu jedem Zeitpunkt in der Zukunft geschätzt werden, welche Eigenschaften, wie maximale Datenrate, Paketverlustrate, Latenz, Jitter, etc., die Funkübertragung vom beziehungsweise zum Fahrzeug besitzen kann. Mit dieser Schätzung, zusammen mit den von den Komponenten gestellten Anforderungen an die Kommunikation, kann nicht nur eine optimale Verteilung der Kommunikationsressourcen auf die einzelnen Funktionseinheiten durchgeführt werden, es kann auch ermittelt werden, ob und wann die Anforderungen wahrscheinlich erfüllt werden können. Diese Information kann anschließend zurück zu den Funktionseinheiten gegeben werden, sodass diese bereits im Vorfeld wissen können, wann deren Anforderungen angepasst werden müssen, beziehungsweise wann diese mit welchen Eigenschaften der Kommunikation rechnen können. Die Funktionseinheiten können so vorteilhafterweise bereits frühzeitig Maßnahmen einleiten, um weiterhin korrekt zu arbeiten. Ohne eine solche optimale Verteilung könnte sich die Systemleistung vom optimalen Arbeitspunkt entfernen. Das heißt konkret, entweder könnte die verfügbare Kapazität nicht ausgenutzt werden, obwohl das System in der Lage wäre eine bessere Leistung zu erzielen, oder es könnte eine Überlast am Engpass, üblicherweise dem Mobilfunkmodem, erzeugt werden. Letzteres wäre besonders fatal. Denn eine Überlast der Datenrate könnte negative Auswirkungen auf andere Kanaleigenschaften wie zum Beispiel Latenz, Jitter und Paketverlust haben. Mit der hier vorgestellten Steuervorrichtung können solche Paketverluste vorteilhafterweise minimiert oder ganz vermieden werden. Darüber hinaus kann durch Einsatz des beschriebenen Verfahrens die zentrale Komponente, welche die optimale Verteilung der Kommunikationsressourcen berechnet, durch das vorgeschlagene Verfahren befähigt werden, die sogenannte Quality of Service für alle im Fahrzeug ausgeführten Funktionen zu steuern, positiv zu beeinflussen und sogar einzelne Datenströme zu priorisieren. Dies kann zum Beispiel durch eine Gewichtungsfunktion geschehen, die sich abhängig von der Zeit oder Nutzerbedürfnissen dynamisch verändern kann. Für eine solche Steuervorrichtung bietet sich, aufgrund der technischen Nähe zu Mobilfunktechnologien, eine Realisierung auf einer Connectivity Control Unit (CCU) an.
Gemäß einer Ausführungsform kann die Bestimmungseinrichtung ausgebildet sein, um eine Zuteilung der Teilkapazitäten für den Datenverkehr zu den Funktionseinheiten zu berechnen und die Kapazitätssignale über die Funktionsschnittstelle an die Funktionseinheiten bereitzustellen. Beispielsweise kann die Bestimmungseinheit unter Verwendung der Anforderungssignale und des Routensignals berechnen, welche kapazitive Leistung für die einzelnen Funktionseinheiten während eines zukünftigen Abschnitts der Route des Fahrzeugs zur Verfügung stehen kann. Vorteilhafterweise kann dadurch die Steuervorrichtung insgesamt entlastet werden. Wissen die Applikationen bereits im Vorfeld, wann diese wie viele Daten senden dürfen, können zum Beispiel Buffer kleiner ausfallen. Zudem kann eine Ausführung von möglicherweise CPUintensiven QoS Algorithmen zum Klassifizieren und Priorisieren von Traffic vermindert oder ganz vermieden werden. Darüber hinaus kann durch das Zuteilen zukünftig bereitstehender Teilkapazitäten dem sogenannten Buffer Bloat Problem in Fernverkehrsnetzen begegnet werden. Von einem Buffer Bloat spricht man, wenn Pakete sich an einem Internet- Router anstauen. Dabei füllen sich sogenannte Buffer bis der Router schließlich keine andere Wahl hat als Pakete zu verwerfen. Im leichten Fall erhöht sich dabei lediglich die Kommunikationslatenz. Meistens bleibt es aber nicht dabei und es kommt zwangsläufig zu Paketverlust. Dieses Problem kann immer dann entstehen, wenn mehr Daten an einem Router eintreffen als versendet werden können. Dieser Effekt kann bereits im Fahrzeug eintreten. Eingehend kann die Mobilfunkbasis der Router sein. Ausgehend kann es die CCU beziehungsweise das darin enthaltene Modem sein und alle daran angeschlossenen Geräte können Datenpakete nach einem schlecht vorhersagbaren Muster produzieren. Um nun eine Überlast zu vermeiden und damit die Eigenschaften wie Latenz und Paketverlust konstant zu halten, kann mit der hier vorgestellten Steuervorrichtung bereits bei der Erzeugung der Datenpakete auf die jeweilige Menge geachtet werden.
Gemäß einer weiteren Ausführungsform kann die Bestimmungseinrichtung ausgebildet sein, um das Routensignal über die Funktionsschnittstelle einzulesen. Beispielsweise kann die Steuervorrichtung über die Funktionsschnittstelle mit einer Navigationseinrichtung zum Navigieren des Fahrzeugs verbunden sein. Die Navigationseinrichtung kann ausgebildet sein, um eine aktuelle Route für das Fahrzeug zu einem bestimmten Ziel zu berechnen und in Form des Routensignals bereitzustellen. Zusätzlich oder alternativ kann ein wahrscheinlicher Fahrtweg, auch Most Probable Path (MPP) genannt, erlernt worden sein. Vorteilhafterweise kann die Bestimmungseinrichtung mittels des Routensignals die zukünftige Route des Fahrzeugs frühzeitig bestimmen und den generierten Datenverkehr entsprechend anpassen.
Gemäß einer weiteren Ausführungsform kann die Bestimmungseinrichtung ausgebildet sein, um das Netzsignal, das eine entlang der Route bestehende und von einer Funknetzabdeckung abhängige Größe einer maximalen Kapazität für den Datenverkehr repräsentiert, über die Übertragungsschnittstelle einzulesen. Beispielsweise kann das Netzsignal über die mit der Steuervorrichtung verbundene Funkeinrichtung bereitgestellt werden. Die Funkeinrichtung kann ausgebildet sein, um die Funknetzabdeckung entlang der Route zu erfassen und unter Verwendung des Netzsignals an die Bestimmungseinrichtung bereitzustellen. Vorteilhafterweise kann dadurch optimal berechnet werden, zu welchem Zeitpunkt eine bestimmte Größe einer Kapazität für den Datenverkehr für Funktionseinheiten des Fahrzeugs verfügbar sein kann.
Gemäß einer weiteren Ausführungsform kann die Bestimmungseinrichtung eine Optimierungseinrichtung umfassen, die ausgebildet sein kann, um unter Verwendung des Routensignals, des Netzsignals, des ersten Anforderungssignals und des zweiten Anforderungssignals die erste Teilkapazität und die zweite Teilkapazität zu berechnen und die Teilkapazitäten den Funktionseinheiten zuzuordnen. Beispielsweise kann die Optimierungseinrichtung, die auch als Optimierer bezeichnet werden kann, Daten darüber bekommen, welche Eigenschaften (Datenrate, Latenz, etc.) die Funkverbindung in der Zukunft haben wird. Dies kann zum Beispiel durch die Kombination eines berechneten MPP (Most Probable Path) und einer Mobilfunkabdeckungskarte erreicht werden. Zusätzlich kann der Optimierer alle Anforderungen der Softwarekomponenten an deren Datenflüsse bekommen. Die Optimierungseinrichtung kann auf dieser Grundlage berechnen, wie und wann die verfügbaren Ressourcen auf die unterschiedlichen Datenflüsse aufgeteilt werden. Diese Zuteilung kann beispielsweise berechnet werden, indem eine Zielfunktion optimiert wird. Diese Zielfunktion kann beispielsweise die unterschiedlichen Anforderungen miteinander verknüpfen, gewichten und priorisieren. Diese Zielfunktion kann beliebig vom Optimierer gewählt werden und sich insbesondere auch über die Zeit verändern, um damit die veränderliche Wichtigkeit und Dringlichkeit von einzelnen Funktionen ausdrücken zu können. Dabei kann die Zuteilung der Ressourcen auf Datenströme anhand der Zielfunktion auf unterschiedliche Arten berechnet werden. Hierbei kann zum Beispiel eine rigorose mathematische Beschreibung und anschließende optimale Lösung mittels linearer Programmierung genutzt werden. Darüber hinaus können aber auch Heuristiken oder Approximationen zur Berechnung herangezogen werden. Vorteilhafterweise kann die Steuervorrichtung unter Verwendung einer Optimierungseinrichtung optimal ausgeführt werden.
Zudem kann die Optimierungseinrichtung ausgebildet sein, die Route mit einer mittels der Übertragungsschnittstelle bereitgestellten und die Funknetzabdeckung abbildenden Mobilfunkabdeckungskarte abzugleichen, um einen zeitlichen Verlauf der Größe der zukünftigen maximalen Kapazität für den Datenverkehr zu bestimmen. Bei der Mobilfunkabdeckungskarte kann es sich zum Beispiel um einen Clouddienst handeln, der Vorhersagen zu erwarteten Verbindungseigenschaften an einem Ort zu einer bestimmten Zeit bereitstellt. Mit Hilfe des wahrscheinlichsten Fahrtwegs (MPP) können somit vorteilhafterweise die zu erwartenden Verbindungseigenschaften, wie maximale Datenrate, Paketverlustrate, Latenz, Jitter, etc., entlang des Fahrtweges des Fahrzeugs, zu jedem Zeitpunkt in der Zukunft abgefragt werden. Anstelle oder zusätzlich zu einer Mobilfunkabdeckungskarte können hierbei auch Verfahren wie predictive Quality of Service (pQoS) oder auch eine lokale Short-term Prediction für den Kommunikationskanal genutzt werden.
Gemäß einer weiteren Ausführungsform kann die Bestimmungseinrichtung eine Prognoseeinrichtung umfassen, die ausgebildet sein kann, um das erste und das zweite Kapazitätssignal bereitzustellen. Die Prognoseeinrichtung, die auch als Prognose bezeichnet werden kann, kann zum Beispiel das berechnete Ergebnis des Optimierers bekommen und dieses an jene Funktionseinheiten verteilen, die Anforderungen gestellt haben. Diese Funktionseinheiten können vorteilhafterweise daraus ableiten, zu welcher Zeit eine Anpassung der eigenen Datenflüsse notwendig ist, um die optimale Leistung zu erzielen.
Gemäß einer weiteren Ausführungsform kann die Bestimmungseinrichtung ausgebildet sein, um ein die ersten Funktionsdaten umfassendes erstes Funktionssignal und ein die zweiten Funktionsdaten umfassendes zweites Funktionssignal über die Funktionsschnittstelle einzulesen und an die Übertragungsschnittstelle bereitzustellen.
Gemäß einer weiteren Ausführungsform kann die Bestimmungseinrichtung eine Verkehrsformungseinrichtung umfassen, die ausgebildet sein kann, um unter Verwendung des ersten Kapazitätssignals die ersten Funktionsdaten und unter Verwendung des zweiten Kapazitätssignals die zweiten Funktionsdaten über die Übertragungsschnittstelle auszugeben. Die Verkehrsformungseinrichtung kann auch als Traffic Shaping oder Warteschlangenverwaltung bezeichnet werden. Das Traffic Shaping kann Informationen darüber bekommen, wie die einzelnen Datenflüsse von dem Optimierer behandelt werden sollen. Dabei kann die Verkehrsformungseinrichtung ausgebildet sein, die Datenflüsse gemäß eines berechneten Zeitplans zu formen. Befindet sich beispielsweise sogenannte legacy Software im Fahrzeug, die keine Anforderungen an die Bestimmungseinrichtung gestellt hat, kann beispielsweise angenommen werden, dass diese Software niedrigere Priorität besitzt als die Software, die Anforderungen gestellt hat. In der Folge kann die legacy Software nur die restlichen Kommunikationsressourcen nutzen, die nach diesem Prozess übrig bleiben. Dies wird durch den Prozess des Traffic Shapings durchgesetzt.
Vorteilhafterweise kann durch den Einsatz der Verkehrsformungseinrichtung der generierte Datenverkehr entsprechend einer aktuell verfügbaren Kapazität geformt werden.
Gemäß einer weiteren Ausführungsform kann die erste Anforderung und zusätzlich oder alternativ die zweite Anforderung eine Nutzenfunktion umfassen, wobei die Nutzenfunktion den Nutzen bestimmter Eigenschaften des Datenverkehrs beschreibt. Beispielsweise können die Anforderungen der Funktionseinheiten in Form von Nutzenfunktionen, über Kommunikationseigenschaften, ausgedrückt werden. Die von der jeweiligen Funktionseinheit zur Verfügung gestellten Nutzenfunktionen können beispielsweise mehrdimensional sein. Die verwendeten Dimensionen und deren Anzahl können dabei beliebig sein. Die Nutzenfunktionen können verwendet werden, um den von der Funktionseinheit erfahrenen Nutzen aus der Kommunikation abzubilden. Die Funktionseinheiten können dabei zum Beispiel proaktiv ihre Anforderungen an die zukünftigen Kommunikationseigenschaften in Form von Nutzenfunktionen sowohl an die im Fahrzeug verbauten CCUs als auch an die anderen im Fahrzeug ausgeführten Software-Anwendungen kommunizieren. Nutzenfunktionen können sich über die Zeit ändern. Das heißt, eine Applikation kann zum Beispiel für einen Zeitabschnitt to -ti eine andere Nutzenfunktion besitzen, als für einen Zeitabschnitt ti - tj. Beispielsweise kann eine Applikation X für deren Ausführung Kartendaten benötigen. Diese Kartendaten können auf einem externen Server in zwei Qualitäten bereitliegen: Hoch und Niedrig. Die Karte MH| mit hoher Qualität kann eine hohe Dateigröße sHl haben, aber X erlauben im vollen Funktionsumfang zu arbeiten. Die Karte MLo mit niedriger Qualität kann eine geringe Dateigröße sLo haben, aber nur eingeschränkte Funktionalität von X erlauben. Der Download der Karte sollte zu einem Zeitpunkt t + öt abgeschlossen sein, da hier X die Daten benötigt. Um bis dahin MH| zu laden, kann in den nächsten öt Sekunden eine mittlere Datenrate von sHl / öt für Applikation X benötigt werden. Um bis dahin MLo zu laden, kann in den nächsten öt Sekunden eine mittlere Datenrate von sLo / öt für Applikation X benötigt werden. Dies kann in die Nutzenfunktion für Applikation X eingehen. Nach der Optimierung kann entschieden werden, ob mit den zugeteilten Ressourcen entweder MH| oder MLo geladen wird, da X nun Informationen zur Verfügung stehen können, welche Datenrate in der Zukunft erzielt wird. Dadurch, dass die Steuervorrichtung von allen teilnehmenden Anwendungen die entsprechenden Nutzenfunktionen zur Verfügung gestellt bekommt, kann diese vorteilhafterweise hoch optimierte Verteilungen der Kommunikationsressourcen berechnen, ohne die Anwendungen selbst kennen zu müssen.
Gemäß einer weiteren Ausführungsform kann die Nutzenfunktion unter Verwendung eines Allokationsplans bestimmbar sein. Sobald beispielsweise mehrere Funktionseinheiten im Sinne eines verteilten Systems einen Dienst anbieten, dessen Qualität von dem Nutzen seiner Einzelkomponenten abhängig sein kann, kann das, zum Beispiel händische, Definieren der entsprechenden Nutzenfunktionen sehr zeitintensiv sein. Daher ist es auch möglich, solche abhängigen Nutzenfunktionen aus einem Allokationsplan zu generieren. Ein Allokationsplan zu einem verteilten System kann dabei angeben, wie Ressourcen auf einzelne Datenströme verteilt werden sollten, damit das verteilte System insgesamt einen gewissen Nutzen spenden kann. Zu einem Allokationsplan kann nun ebenso eine Nutzenfunktion definiert werden, die wiederum den Nutzen des verteilten Systems angeben kann. Vorteilhafterweise können Nutzenfunktionen dadurch zeitsparend generiert werden.
Gemäß einer weiteren Ausführungsform kann die erste Anforderung und zusätzlich oder alternativ die zweite Anforderung eine Ablauffrist zum Definieren eines Endzeitpunkts des Übertragens von Funktionsdaten umfassen. Beispielsweise kann eine Anforderung einer Funktionseinheit sein, dass ein Softwaredownload oder ein Softwareupload bis zu einem bestimmten Zeitpunkt abgeschlossen werden soll. Anhand einer solchen Ablauffrist oder Deadline kann mittels der Bestimmungseinrichtung vorteilhafterweise eine optimale Priorisierung für die Zuteilung von Teilkapazitäten an die einzelnen Funktionseinheiten durchgeführt werden.
Zudem wird ein Fahrzeugsystem vorgestellt, das eine Variante der zuvor vorgestellten Steuervorrichtung aufweist. Zudem umfasst das Fahrzeugsystem eine Mehrzahl von Funktionseinheiten, die ausgebildet sind, um Anforderungssignale bereitzustellen, die Anforderungen der Funktionseinheiten an eine zukünftig benötigte Kapazität von Datenverkehr zum Übertragen von Funktionsdaten repräsentieren, Kapazitätssignale zu empfangen, die für die Funktionseinheiten zukünftig bereitstehende Teilkapazitäten repräsentieren, und Funktionssignale bereitzustellen, die die Funktionsdaten repräsentieren.
Weiterhin umfasst das Fahrzeugsystem eine Funkeinrichtung, die mindestens ein Kommunikationsmittel zum Senden und Empfangen von Daten über ein Funknetz, eine Funkschnittstelle zum Verbinden des Kommunikationsmittels mit dem Funknetz, und eine Übertragungsschnittstelle zum Verbinden der Funkeinrichtung mit der Steuervorrichtung, wobei die Funkeinrichtung ausgebildet ist, um Funktionssignale über die Übertragungsschnittstelle einzulesen. In einem solchen Fahrzeugsystem sind vorteilhafterweise alle zuvor genannten Vorteile der Steuereinrichtung optimal umsetzbar.
Unter einem Kommunikationsmittel kann eine Schnittstelle, wie beispielsweise ein LTE Modem verstanden werden. Unter dem Funknetz kann beispielsweise ein Mobilfunknetz oder ein WLAN-Netz verstanden werden. Zudem wird ein Verfahren zum Steuern eines von Funktionseinheiten eines Fahrzeugs generierten Datenverkehrs über eine Funkeinrichtung des Fahrzeugs vorgestellt. Beispielsweise kann das Verfahren unter Verwendung einer Variante der zuvor vorgestellten Steuervorrichtung ausgeführt werden. Das Verfahren umfasst einen Schritt des Einlesens eines ersten Anforderungssignals und eines zweiten Anforderungssignals über eine Funktionsschnittstelle zu einer ersten Funktionseinheit und einer zweiten Funktionseinheit, wobei das erste Anforderungssignal eine erste Anforderung der ersten Funktionseinheit an eine zukünftig benötigte Kapazität für den Datenverkehr zum Übertragen von ersten Funktionsdaten repräsentiert und das zweite Anforderungssignals eine zweite Anforderung der zweiten Funktionseinheit an eine zukünftig benötigte Kapazität für den Datenverkehr zum Übertragen von zweiten Funktionsdaten repräsentiert. Zudem umfasst das Verfahren einen Schritt des Bestimmens eines ersten Kapazitätssignals und eines zweiten Kapazitätssignals unter Verwendung optional eines Routensignals, das eine wahrscheinliche zukünftige Route des Fahrzeugs repräsentiert, eines Netzsignals, das eine entlang der Route bestehende und von einer Funknetzabdeckung abhängige Größe einer maximalen Kapazität für den Datenverkehr repräsentiert, des ersten Anforderungssignals und des zweiten Anforderungssignals, wobei das erste Kapazitätssignal eine für die erste Funktionseinheit zukünftig bereitstehende erste Teilkapazität repräsentiert, und wobei das zweite Kapazitätssignal eine für die zweite Funktionseinheit zukünftig bereitstehende zweite Teilkapazität repräsentiert, um den Funktionseinheiten eine Anpassung der zukünftig benötigten Kapazitäten an die zukünftig bereitstehenden Teilkapazitäten zu ermöglichen. Vorteilhafterweise wird durch Einsatz des vorgestellten Verfahrens die zentrale Komponente, welche die optimale Verteilung der Kommunikationsressourcen berechnet, durch das vorgeschlagene Verfahren befähigt, die Quality of Service für alle im Fahrzeug ausgeführten Funktionen zu steuern, positiv zu beeinflussen und sogar einzelne Datenströme zu priorisieren.
Dieses Verfahren kann beispielsweise in Software oder Hardware oder in einer Mischform aus Software und Hardware beispielsweise in einem Steuergerät implementiert sein. Von Vorteil ist auch ein Computerprogrammprodukt oder Computerprogramm mit Programmcode, der auf einem maschinenlesbaren Träger oder Speichermedium wie einem Halbleiterspeicher, einem Festplattenspeicher oder einem optischen Speicher gespeichert sein kann und zur Durchführung, Umsetzung und/oder Ansteuerung der Schritte des Verfahrens nach einer der vorstehend beschriebenen Ausführungsformen verwendet wird, insbesondere wenn das Programmprodukt oder Programm auf einem Computer oder einer Vorrichtung ausgeführt wird.
Ausführungsbeispiele des hier vorgestellten Ansatzes sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt:
Fig. 1 ein Blockschaltbild einer Steuervorrichtung gemäß einem Ausführungsbeispiel;
Fig. 2 ein Blockschaltbild eines Fahrzeugsystems gemäß einem Ausführungsbeispiel;
Fig. 3 ein Diagramm eines Ausführungsbeispiels einer Nutzenfunktion;
Fig. 4 ein Diagramm eines Ausführungsbeispiels einer mehrdimensionalen
Nutzenfunktion;
Fig. 5 ein Diagramm eines Ausführungsbeispiels einer weiteren mehrdimensionalen Nutzenfunktion;
Fig. 6 ein Diagramm eines Allokationsplans gemäß einem Ausführungsbeispiel;
Fig. 7 ein Diagramm einer anderen Nutzenfunktion gemäß einem Ausführungsbeispiel;
Fig. 8 ein Diagramm eines Ausführungsbeispiels einer Nutzenfunktion; Fig. 9 ein Ablaufdiagramm eines Verfahrens zum Steuern eines von Funktionseinheiten eines Fahrzeugs generierten Datenverkehrs gemäß einem Ausführungsbeispiel;
Fig. 10 ein Ablaufdiagramm eines Ausführungsbeispiels eines Schritts des Verfahrens zum Steuern eines Datenverkehrs; und
Fig. 11 ein Ablaufdiagramm eines Ausführungsbeispiels eines Schritts des Verfahrens zum Steuern eines Datenverkehrs.
In der nachfolgenden Beschreibung günstiger Ausführungsbeispiele der vorliegenden Erfindung werden für die in den verschiedenen Figuren dargestellten und ähnlich wirkenden Elemente gleiche oder ähnliche Bezugszeichen verwendet, wobei auf eine wiederholte Beschreibung dieser Elemente verzichtet wird.
Fig. 1 zeigt ein Blockschaltbild einer Steuervorrichtung 100 gemäß einem Ausführungsbeispiel. Die Steuervorrichtung 100 ist ausgebildet, um einen von Funktionseinheiten 105, 110 eines Fahrzeugs 115 generierten Datenverkehr über zumindest eine Funkeinrichtung 120 des Fahrzeugs 115 zu steuern. In diesem Ausführungsbeispiel ist das Fahrzeug 115 als automatisiert fahrendes Fahrzeug oder als automatisch fahrendes Fahrzeug ausgebildet, das von einem Fahrer steuerbar ist, der sich außerhalb des Fahrzeugs 115 befindet. Alternativ kann es sich bei dem Fahrzeug 115 um ein nicht- oder nur teil-automatisiert fahrendes Fahrzeug handeln. Bei einem automatisiert oder automatisch fahrenden Fahrzeug ist das Einhalten verschiedener Kommunikationsanforderung von Softwarekomponenten des Fahrzeugs 115 besonders relevant, um Überlastungssituationen im Datenverkehr zu vermeiden sowie Fahrzeug- und Mobilfunkressourcen zu schonen.
Mittels der Steuervorrichtung 100 ist eine gezielte Einflussnahme auf die Ressourcenverteilung möglich, um wichtige Funktion zu priorisieren und ein Verhungern von einzelnen Anwendungen zu verhindern. Hierfür umfasst die Steuervorrichtung 100 eine Funktionsschnittstelle 125 zum Verbinden der Steuervorrichtung 100 mit einer ersten Funktionseinheit 105 und einer zweiten Funktionseinheit 110. Die Funktionseinheiten 105, 110, die auch als Softwarefunktionen oder Softwaremodule bezeichnet werden können, sind in diesem Ausführungsbeispiel ausgebildet, um mittels der Steuervorrichtung 100 mit fahrzeugexternen Kommunikationspartnern zu kommunizieren. Um die Anforderungen der Funktionseinheiten 105, 110 an eine solche Kommunikation mitzuteilen, ist über die Funktionsschnittstelle 125 ein erstes Anforderungssignals 130 einlesbar, das eine erste Anforderung der ersten Funktionseinheit 105 an eine zukünftig benötigte Kapazität für den Datenverkehr zum Übertragen von ersten Funktionsdaten repräsentiert. Gleichermaßen ist ein zweites Anforderungssignals 135 einlesbar, das eine zweite Anforderung der zweiten Funktionseinheit 110 an eine zukünftig benötigte Kapazität für den Datenverkehr zum Übertragen von zweiten Funktionsdaten repräsentiert. Lediglich beispielhaft handelt es sich bei der ersten Anforderung um einen Video-Stream, der zum Fahrer außerhalb des Fahrzeugs 115 übertragbar ist, um ein sogenanntes Tele- Operated Driving zu ermöglichen. Bei der zweiten Anforderung handelt es sich in diesem Ausführungsbeispiel um das Nachladen von hochaktuellen Kartenausschnitten, die zum automatischen Fahren benötigt werden. Dabei umfasst die zweite Anforderung lediglich beispielhaft eine Ablauffrist zum Definieren eines Endzeitpunkts des Übertragens von Funktionsdaten. Diese Ablauffrist, die auch als Deadline bezeichnet werden kann, gibt in diesem Ausführungsbeispiel an, dass Laden der Kartendaten zu einem bestimmten Zeitpunkt abgeschlossen sein muss.
In einem anderen Ausführungsbeispiel können mittels der Steuervorrichtung beispielsweise auch die Überwachung von automatisch fahrenden Fahrzeugen gesteuert oder weitere externe Eingriffsmöglichkeiten reguliert werden, um das Fahrzeug aus der Ferne optimal zu steuern. Dazu benötigt es eine verlässliche mobilfunkbasierte Funktion, um dem Fahrzeug 115 den passenden Befehl zu erteilen.
Entsprechend weist die Steuervorrichtung 100 eine Übertragungsschnittstelle 140 zum Verbinden der Steuervorrichtung 100 mit der zumindest einen Funkeinrichtung 120 auf. Mittels der zumindest einen Funkeinrichtung 120 ist eine Kommunikation mit externen Teilnehmern über ein Funknetz ermöglicht. Da für die optimale Steuerung des Fahrzeugs 115 zudem der wahrscheinliche Verlauf des Fahrtwegs von Bedeutung ist, ist die Steuervorrichtung 100 in einem Ausführungsbeispiel ausgebildet, um über die Funktionsschnittstelle 125 ein Routensignal 145 einzulesen, das eine wahrscheinliche zukünftige Route 146 des Fahrzeugs 115 repräsentiert. Hierfür ist die Steuervorrichtung 100 lediglich beispielhaft über die Funktionsschnittstelle 125 mit einer Navigationseinrichtung 147 verbunden, die ausgebildet ist, um mittels in der Navigationseinrichtung 147 hinterlegten Kartendaten die wahrscheinliche Route 146 des Fahrzeugs 115 zu einem bestimmten Ziel zu berechnen. In einem anderen Ausführungsbeispiel kann ein wahrscheinlicher Fahrtweg, auch Most Probable Path (MPP) genannt, auch erlernt worden sein.
Zugleich ist die Steuervorrichtung 100 in diesem Ausführungsbeispiel ausgebildet, um ein Netzsignal 150 über die Funkschnittstelle 140 einzulesen, wobei das Netzsignal 150 eine entlang der Route 146 bestehende und von einer Funknetzabdeckung abhängige Größe einer maximalen Kapazität für den Datenverkehr repräsentiert. Hierbei empfängt die Funkeinrichtung 120 ein Funksignal 155 mittels entlang der Route 146 angeordneten Funkmasten 157. Da also die wahrscheinliche Route 146 des Fahrzeugs 115 bekannt ist, ist unter Verwendung des Netzsignals 150 eine Einschätzung von Eigenschaften, wie maximale Datenrate, Paketverlustrate, Latenz oder Jitter, die eine Funkübertragung vom beziehungsweise zum Fahrzeug 115 besitzen wird, zu jedem Zeitpunkt in der Zukunft möglich.
So ist die Steuervorrichtung 100 ausgebildet, um unter Verwendung des Routensignals 145, des Netzsignals 150, des ersten Anforderungssignals 130 und des zweiten Anforderungssignals 135 mittels einer Bestimmungseinrichtung 160 ein erstes Kapazitätssignal 165 und ein zweites Kapazitätssignal 170 zu bestimmen. Dabei repräsentiert das erste Kapazitätssignal 165 eine für die erste Funktionseinheit 105 zukünftig bereitstehende erste Teilkapazität und das zweite Kapazitätssignal 170 repräsentiert eine für die zweite Funktionseinheit 110 zukünftig bereitstehende zweite Teilkapazität. Gemäß einem Ausführungsbeispiel ist die Steuervorrichtung 100 ausgebildet, um die Kapazitätssignale ohne Verwendung des Routensignals 145 zu bestimmen. Die Bestimmungseinrichtung 160 ist in diesem Ausführungsbeispiel ausgebildet, um eine Zuteilung der Teilkapazitäten für den Datenverkehr zu den Funktionseinheiten 105, 110 zu berechnen und die Kapazitätssignale 165, 170 über die Funktionsschnittstelle 125 an die Funktionseinheiten 105, 110 bereitzustellen. Anders ausgedrückt ist die Bestimmungseinheit 160 ausgebildet, um den Funktionseinheiten 105, 110 mitzuteilen, ob und wann deren Kommunikationsanforderungen in der Zukunft eingehalten werden, sodass diese ihr Verhalten proaktiv darauf einstellen können. Dadurch ist eine frühzeitige Voraussage, wann Funktionen im Fahrzeug 115, die von der Kommunikation mit externen Teilnehmern abhängig sind, nicht mehr verfügbar sind und den Funktionseinheiten 105, 110 ist eine Anpassung der zukünftig benötigten Kapazitäten an die zukünftig bereitstehenden Teilkapazitäten ermöglicht.
Einer solchen Anpassung folgend sind die Funktionseinheiten 105, 110 in diesem Ausführungsbeispiel ausgebildet, um ein die ersten Funktionsdaten umfassendes erstes Funktionssignal 180 und ein die zweiten Funktionsdaten umfassendes zweites Funktionssignal 185 bereitzustellen. Die Steuervorrichtung 100 ist ausgebildet, um diese Funktionssignale 180, 185 über die Funktionsschnittstelle 125 einzulesen und an die Übertragungsschnittstelle 140 bereitzustellen.
Die zwei Funktionseinheiten 105, 110 sind lediglich beispielhaft dargestellt. Es können entsprechende weitere Funktionseinheiten an die Steuervorrichtung 100 angeschlossen sein und der von diesen weiteren Funktionseinheiten generierte Datenverkehr kann auf entsprechende Weise unter Verwendung der Steuervorrichtung gesteuert werden.
Fig. 2 zeigt ein Blockschaltbild eines Fahrzeugsystems 200 gemäß einem Ausführungsbeispiel. Das Fahrzeugsystem 200 ist in einem Fahrzeug anwendbar, wie es in der vorangegangenen Figur beschrieben wurde, und umfasst eine Steuervorrichtung 100, die der in der vorangegangenen Figur beschriebenen Steuervorrichtung entspricht oder ähnelt.
Zudem umfasst das Fahrzeugsystem 200 eine Mehrzahl von Funktionseinheiten 105, 110, 205. Die Funktionseinheiten 105, 110, 205 sind ausgebildet, um Anforderungssignale bereitzustellen, die Anforderungen der Funktionseinheiten 105, 110, 205 an eine zukünftig benötigte Kapazität von Datenverkehr zum Übertragen von Funktionsdaten repräsentieren. Ferner sind die Funktionseinheiten 105, 110, 205 ausgebildet, Kapazitätssignale zu empfangen, die für die Funktionseinheiten 105, 110, 205 zukünftig bereitstehende Teilkapazitäten repräsentieren. Schließlich sind die Funktionseinheiten 105, 110, 205 ausgebildet Funktionssignale bereitzustellen, die die Funktionsdaten repräsentieren.
Zudem weist das Fahrzeugsystem 200 eine Funkeinrichtung 120 auf. Die Funkeinrichtung 120 umfasst ein Kommunikationsmittel 210, beispielsweise ein Modem, zum Senden und Empfangen von Daten über ein Funknetz 215, beispielsweise ein Mobilfunknetz, sowie eine Funkschnittstelle 220 zum Verbinden des Kommunikationsmittels 210 mit dem Funknetz 215. Lediglich beispielhaft ist das Kommunikationsmittel 220 als LTE-Modem ausgebildet und über einen Funkmast 157, der auch als Mobilfunk Basisstation bezeichnet werden kann, mit dem Internet 222 verbindbar. Innerhalb des Fahrzeugsystems 200 ist die Funkeinrichtung 120 über die Übertragungsschnittstelle 140 mit der Steuervorrichtung 100 verbunden, wobei die Funkeinrichtung 120 ausgebildet ist, um Funktionssignale über die Übertragungsschnittstelle 140 einzulesen. Zugleich ist die Steuervorrichtung 100, die auch als Connectivity Control Unit (CCU) bezeichnet werden kann, ausgebildet, um über das LTE-Modem angesprochen zu werden. Aller Datenverkehr des Fahrzeugs mit fahrzeugexternen Kommunikationspartnern 225 läuft über die CCU, um beispielhaft Softwareuploads oder Softwaredownloads durchzuführen.
Hierfür umfasst in diesem Ausführungsbeispiel die Bestimmungseinrichtung 160 der Steuervorrichtung 100 eine Optimierungseinrichtung 230, die ausgebildet ist, um unter Verwendung des optionalen Routensignals, des Netzsignals, des ersten Anforderungssignals und des zweiten Anforderungssignals die erste Teilkapazität und die zweite Teilkapazität zu berechnen und die Teilkapazitäten den Funktionseinheiten 105, 110, 205 zuzuordnen. Mit anderen Worten bekommt die Optimierungseinrichtung 230, die auch als Optimierer bezeichnet werden kann, Daten darüber, welche Eigenschaften, beispielsweise bezüglich Datenrate, Latenz, etc., die Funkverbindung in Zukunft haben wird. Dabei ist die Optimierungseinrichtung 230 ausgebildet, die wahrscheinliche Route des Fahrzeugs mit einer mittels der Übertragungsschnittstelle 140 bereitgestellten und die Funknetzabdeckung abbildenden Mobilfunkabdeckungskarte 235 abzugleichen, um einen zeitlichen Verlauf der Größe der zukünftigen maximalen Kapazität für den Datenverkehr zu bestimmen. Lediglich beispielhaft handelt es sich bei der Mobilfunkabdeckungskarte 235 um einen Clouddienst, der Vorhersagen zu erwarteten Verbindungseigenschaften an einem Ort zu einer bestimmten Zeit bereitstellt. Mithilfe des wahrscheinlichsten Fahrtweges MPP sind somit die zu erwartenden Verbindungseigenschaften entlang der Route des Fahrzeugs abrufbar. In diesem Ausführungsbeispiel ist die wahrscheinliche Route mittels der Navigationseinrichtung 147 bestimmbar. Zusätzlich bekommt die Optimierungseinrichtung 230 alle Anforderungen der Softwarekomponenten an deren Datenflüsse. Die Optimierungseinrichtung 230 berechnet auf dieser Grundlage, wie und wann die verfügbaren Ressourcen auf die unterschiedlichen Datenflüsse aufgeteilt werden. In diesem Ausführungsbeispiel ist diese Zuteilung durch Optimierung einer Zielfunktion berechenbar. Diese Zielfunktion verknüpft, gewichtet und priorisiert die unterschiedlichen Anforderungen (Nutzenfunktionen) der Funktionen miteinander. Die Optimierungseinrichtung 230 ist ausgebildet, um diese Zielfunktion beliebig zu wählen, wobei die Zielfunktion über die Zeit veränderbar ist, um damit die veränderliche Wichtigkeit und Dringlichkeit von einzelnen Funktionen auszudrücken. Anhand der Zielfunktion ist die Zuteilung der Ressourcen auf Datenströme auf unterschiedliche Arten berechenbar. Lediglich beispielhaft ist die Optimierungseinrichtung 230 in diesem Ausführungsbeispiel ausgebildet, um hierbei eine rigorose mathematische Beschreibung und anschließende optimale Lösung mittels linearer Programmierung zu nutzen. In einem anderen Ausführungsbeispiel können zusätzlich oder alternativ auch Heuristiken oder Approximationen zur Berechnung herangezogen werden.
Durch den Abgleich der Route mit der Mobilfunkabdeckungskarte 235 ist zu jedem Zeitpunkt in der Zukunft schätzbar, welche Eigenschaften, wie maximale Datenrate, Paketverlustrate, Latenz oder Jitter, die Funkübertragung vom beziehungsweise zum Fahrzeug besitzen wird. In einem anderen Ausführungsbeispiel können anstelle oder zusätzlich zu einer Mobilfunkabdeckungskarte hierbei auch Verfahren wie predictive Quality of Service (pQoS) oder auch eine lokale Short-term Prediction für den Kommunikationskanal genutzt werden. Mit dieser Schätzung, zusammen mit den von den Funktionseinheiten 105, 110, 205 gestellten Anforderungen an die Kommunikation, ist nicht nur eine optimale Verteilung der Kommunikationsressourcen auf die einzelnen Komponenten durchführbar, es ist auch ermittelbar, ob und wann die Anforderungen mit einer bekannten oder unbekannten Wahrscheinlichkeit erfüllbar sind. Diese Information ist in diesem Ausführungsbeispiel mittels einer Prognoseeinrichtung 240 an die Funktionseinheiten 105, 110, 205 unter Verwendung von Kapazitätssignalen an bereitstellbar, sodass diese bereits im Vorfeld wissen, wann deren Anforderungen angepasst werden müssen, beziehungsweise wann diese mit welchen Eigenschaften der Kommunikation rechnen können. Die Prognoseeinrichtung 240, die auch als Prognose bezeichnet werden kann, bekommt das errechnete Ergebnis der Optimierungseinrichtung 230 und verteilt dieses an jene Softwaremodule, die Anforderungen gestellt haben. Diese Softwaremodule können daraus ableiten, zu welcher Zeit eine Anpassung der eigenen Datenflüsse notwendig ist, um eine optimale Leistung zu erzielen. Den Funktionseinheiten 105, 110, 205 ist damit ein frühzeitiges Einleiten von Maßnahmen ermöglicht, um weiterhin korrekt zu arbeiten. Ohne eine solche optimale Verteilung entfernt sich die Systemleistung vom optimalen Arbeitspunkt. Das heißt konkret, in einem anderen Ausführungsbeispiel ohne die hier beschriebene Steuervorrichtung wird entweder die verfügbare Kapazität nicht ausgenutzt, obwohl das System in der Lage wäre eine bessere Leistung zu erzielen, oder es wird eine Überlast am Engpass, üblicherweise dem Mobilfunk Modem, erzeugt. Letzteres ist besonders fatal. Denn eine Überlast der Datenrate hat negative Auswirkungen auf andere Kanaleigenschaften, wie zum Beispiel Latenz, Jitter und Paketverlust.
In diesem Ausführungsbeispiel umfasst die Bestimmungseinrichtung 160 zusätzlich zu der Optimierungseinrichtung 230 und der Prognoseeinrichtung 240 eine Verkehrsformungseinrichtung 250, die ausgebildet ist, um unter Verwendung des ersten Kapazitätssignals die ersten Funktionsdaten und unter Verwendung des zweiten Kapazitätssignals die zweiten Funktionsdaten über die Übertragungsschnittstelle 140 auszugeben. Die Verkehrsformungseinrichtung 250 kann auch als Traffic Shaping oder Warteschlangenverwaltung bezeichnet werden. Die Verkehrsformungseinrichtung 250 bekommt Informationen darüber, wie die einzelnen Datenflüsse von dem Optimierer behandelt werden sollen. Mittels des Traffic Shapings sind die Kommunikationsressourcen des Fahrzeugs bestmöglich (im Sinne der Anforderungen) nutzbar. Dabei ist das eigentliche Traffic Shaping ausgelagert, das heißt es ist weg vom Router und hin zur Applikation beziehungsweise den darin genutzten Kommunikationsbibliotheken, wie lediglich beispielhaft die Transport- Layer Protokolle QU IC oder TCP.
In einem anderen Ausführungsbeispiel kann das System auch gleichzeitig zu mehreren Mobilfunknetzen und WLAN-Netzen verbunden sein. In diesem Fall kann die CCU Verbindungen zu mehreren LTE-Modems und zusätzlich oder alternativ WLAN- Karten besitzen. Alternativ zur bisherigen Darstellung in der eine zentrale Komponente existiert, die die Optimierung berechnet und das Ergebnis an alle anderen Komponenten verteilt, kann es aus Redundanzgründen sinnvoll sein, wenn jede Softwarekomponente die Anforderungen an jede andere Softwarekomponente mitteilt. In der Folge kann jede Softwarekomponente die Optimierung lokal berechnen. Alternativ zur bisherigen Darstellung, in der das Traffic Shaping zentral auf der CCU passiert, kann jede Softwarefunktion ein eigenes Traffic Shaping besitzen, sodass Funktionen nicht mehr Daten zu der CCU senden können, als durch den berechneten Zeitplan definiert. Dieses Traffic Shaping kann direkt im Softwarestack des verwendeten Transportprotokolls, wie zum Beispiel TCP, UDP oder QUIC, implementiert sein. Dies hätte zur Folge, dass sich wesentlich weniger Daten an der CCU anstauen, da die Applikationen selbst nur so viel Daten generieren beziehungsweise anfordern, wie auch mit der Mobilfunkanbindung ausgetauscht werden können. Auch wird die Rechenlast auf der CCU, die durch das Traffic Shaping entsteht, dadurch wesentlich geringer. Alternativ zur Berechnung des Zeitplans im Fahrzeug, kann der Zeitplan auch in einer Fahrzeug-externen Komponente berechnet werden, beispielsweise in der Cloud.
Fig. 3 zeigt ein Diagramm eines Ausführungsbeispiels einer Nutzenfunktion 300, wobei die Datenrate auf der x-Achse in M Bit/s und der Nutzen auf der y- Achse abgebildet ist. Anforderungen von Funktionseinheiten, wie sie in den vorangegangenen Figuren beschrieben wurden, können Nutzenfunktionen enthalten, die den Nutzen von bestimmten Eigenschaften für die Funktionseinheiten beschreiben. Die hier dargestellte Nutzenfunktion 300 beschreibt, dass die Kommunikation mit dem externen Kommunikationspartner im Upload mindestens 2 MBit/s betragen muss (andernfalls ist der Nutzen 0) und kein zusätzlicher Nutzen daraus gezogen werden kann, wenn mehr als 5 MBit/s zur Verfügung steht. Zwischen 2 MBit/s und 5 MBit/s steigt der Nutzen für die Funktion linear. Softwarefunktionen können beliebige Nutzenfunktionen benutzen, um die Anforderungen an die Kommunikation zu beschreiben. Dabei können Nutzenfunktionen nicht nur von der Datenrate, sondern auch von Latenz, Jitter, Paketverlust, etc. abhängig sein. Die Nutzenfunktionen werden somit Mehrdimensional. Ist der Nutzen für eine realisierte Kommunikationseigenschaft gleich Null, so gilt die entsprechende Anforderung als nicht erfüllt.
Fig. 4 und Fig. 5 zeigen jeweils ein Diagramm eines Ausführungsbeispiels einer mehrdimensionalen Nutzenfunktion UA und einer weiteren mehrdimensionalen Nutzenfunktion UB. Im Falle mehrerer konkurrierender und unabhängiger Anwendungen sind mehrdimensionale Nutzenfunktionen UA, UB verwendbar, um die Rivalität zwischen diesen Anwendungen auszudrücken. Diese mehrdimensionalen Funktionen haben eine Achse für den Nutzen, die in den hier gezeigten Abbildungen als y- Achse dargestellt ist, und eine Achse für jede Ressource (Datenrate, Latenz, Fehlerrate usw.). In den hier gezeigten Abbildungen ist jeweils die Datenrate auf der x-Achse dargestellt. Zur Modellierung von Abhängigkeiten zwischen Anwendungen ist in diesem Ausführungsbeispiel eine zusätzliche Achse eingeführt, um zwei Nutzenfunktionen miteinander zu verbinden. Bei zwei Anwendungen A und B, hat lediglich beispielhaft die Nutzenfunktion UA von Anwendung A nun eine zusätzliche Dimension haben, nämlich den Nutzen von Anwendung B (UB). Dadurch wird die Nutzenfunktion von Anwendung A abhängig vom Nutzen von Anwendung B. In dem hier dargestellten Ausführungsbeispiel ergibt sich eine verteilte Anwendung, die sich aus zwei Teilen zusammensetzt. Lediglich beispielhaft beschreibt dabei Figur 4 die Nutzenfunktion UA einer Frontkamera und Figur 5 beschreibt die Nutzenfunktion UB einer Rückkamera, die alle eine bestimmte Datenrate benötigen, damit die verteilte Anwendung funktioniert. Dabei benötigt jeder Sensor eine bestimmte Menge an Datenrate, um richtig zu funktionieren, wobei die Anwendung nur dann einen gewissen Nutzen hat, wenn den einzelnen Sensoren ein bestimmter Anteil der Datenrate zugewiesen wird. Damit also die Gesamtanwendung einen Nutzen von beispielhaft 0,2 hat, werden mindestens 4 MBit/s für das Frontvideo und mindestens 0,5 MBit/s für das Heckvideo benötigt.
In einem anderen Ausführungsbeispiel können das vordere und hintere Video alternativ miteinander verknüpft werden, indem separate und nicht voneinander abhängige zweidimensionale Nutzenfunktionen für jeden Sensor UfrOnt und Urear und dann beispielsweise eine dritte Nutzenfunktion für die Gesamtanwendung verwendet werden. Dabei kann die dritte Nutzfunktion in 3D sein, mit einer Nutzen-Achse, einer Achse UfrOnt und einer Achse Urear. Aber in diesem Fall kann ein einzelner Sensor keinen großen Nutzen haben, weil er ohne den anderen nutzlos ist. Daher können diese sensorunabhängigen Nutzenfunktionen also nicht wirklich allein im Optimierer verwendet werden, da ihr Nutzen nicht "echt" ist. Sie sollten durch die Nutzenfunktion der Gesamtanwendung verbunden werden.
Da in dem in den Figuren 4 und 5 dargestellten Ausführungsbeispiel die einzige betrachtete Ressource die Datenrate ist, gibt es für jede gegebene Menge an Ressourcen (Datenrate) mindestens eine bestimmte Zuordnung dieser Menge an Datenrate auf die beiden Videosensoren, die den Gesamtnutzen maximiert. Wenn also n MBit/s an Ressourcen für die Anwendung verwendet werden, ist genau bekannt, wie diese Ressourcen den beiden Sensoren zuweisbar sind: An = (k, I), k + I = n. Durch die Definition dieser Zuweisungen An für jede n e R+ ergibt sich ein so genannter Allokationsplan. Dieser Allokationsplan definiert lediglich eine beste Zuordnung der verfügbaren Ressourcen zu den verschiedenen Sensoren, nicht den Nutzen für die Anwendung, der sich aus dieser Zuordnung ergibt. Um letzteren auszudrücken, kann die Anwendung eine separate Nutzenfunktion für den gesamten Allokationsplan angeben.
Fig. 6 zeigt ein Diagramm eines Allokationsplans 600 gemäß einem Ausführungsbeispiel. Sobald mehrere Applikationen im Sinne eines verteilten Systems einen Dienst anbieten, dessen Qualität von dem Nutzen seiner Einzelkomponenten abhängig ist, ist das (händische) Definieren der entsprechenden Nutzenfunktionen sehr zeitintensiv. Daher ist es auch möglich, solche abhängigen Nutzenfunktionen aus einem Allokationsplan zu generieren. Ein Allokationsplan zu einem verteilten System gibt dabei an, wie Ressourcen auf einzelne Datenströme verteilt werden müssen, damit das verteilte System insgesamt einen gewissen Nutzen spenden kann. Ein solcher Plan ist beispielhaft in der hier gezeigten Abbildung für drei verschiedene Datenströme zu sehen. Dabei handelt es sich lediglich beispielhaft um einen Allokationsplan 600 für drei Sensoren 605, 610, 615, beziehungsweise die Aufteilung der verfügbaren Datenrate auf drei Datenströme. Der Plan umfasst drei verschiedene Sensoren und definiert, wie viel Datenrate jedem Sensor zugewiesen wird (y- Achse) bei einer bestimmten Menge an Datenrate, die der Anwendung zur Verfügung steht (x-Achse). Wenn die Anwendung zum Beispiel insgesamt 4 MBit/s Datenrate erhält, werden alle 4 MBit/s dem ersten Sensor 605 zugewiesen. Wenn die Anwendung jedoch 5 MBit/s erhält, werden lediglich beispielhaft 4,5 MBit/s dem ersten Sensor 605 und 0,5 MBit/s dem zweiten Sensor 610 zugewiesen. In der hier gezeigten Figur ist nur die verfügbare Datenrate dargestellt, aber das gleiche Prinzip kann auch in einem mehrdimensionalen Fall verwendet werden, zum Beispiel mit Datenrate, Latenz und Bitfehlerrate.
Mit anderen Worten lässt sich die Verwendung von Allokationsplänen auch wie folgt beschreiben. Allokationspläne lösen im Allgemeinen das Problem der Zuteilung von verfügbaren Ressourcen zu einer bekannten Menge von Daten generierenden Einheiten, beispielsweise von Sensoren oder Datenspeichern. Sie können jedoch nicht verwendet werden, wenn nicht alle Verbraucher im Voraus bekannt sind, das heißt in einem System, in dem mehrere verschiedene Anwendungen verwendet werden, die nicht von denselben Entwicklern stammen, oder wenn neue Anwendungen im Laufe der Zeit kommen und gehen. Dabei sind Nutzenfunktionen aus einem Allokationsplan generierbar. In einem Ausführungsbeispiel kann mit der Definition eines Allokationsplans für beispielsweise zwei Sensoren und der daraus resultierenden Nutzenfunktion für eine Anwendung begonnen werden. Daraufhin können lineare Nutzenfunktionen für jeden Sensor separat erstellt werden, indem jeder zugewiesenen Datenrate ein künstlicher Nutzen zugewiesen wird. Dabei kann der Nutzen einer zugewiesenen Datenrate zum Beispiel durch die zugewiesene Datenrate selbst definiert sein, dividiert durch die maximal zugewiesene Datenrate für diesen bestimmten Sensor. Fig. 7 zeigt ein Diagramm einer anderen Nutzenfunktion 700 gemäß einem Ausführungsbeispiel. Die hier dargestellte andere Nutzenfunktion 700 ist lediglich beispielhaft zu einem Allokationsplan, wie er in der vorangegangenen Figur 6 beschrieben wurde, definierbar und gibt den Nutzen des verteilten Systems an. Dabei ist der Nutzen auf der y-Achse und die Datenrate auf der x-Achse abgebildet.
Fig. 8 zeigt ein Diagramm eines Ausführungsbeispiels einer Nutzenfunktion 300. Die hier dargestellte Nutzenfunktion 300 entspricht oder ähnelt der in der vorangegangenen Figur 3 beschriebenen Nutzenfunktion, mit dem Unterschied, dass die hier dargestellte Nutzenfunktion 300 lediglich beispielhaft dreidimensional dargestellt ist. Dabei ist der Nutzen auf der z-Achse, die Paketfehlerrate auf der x-Achse und die Datenrate auf der y-Achse angegeben. In weiteren Ausführungsbeispielen können verwendeten Dimensionen und deren Anzahl beliebig sein. Diese können verwendet werden, um den von der Applikation erfahrenen Nutzen aus der Kommunikation abzubilden.
Beispielsweise können Video und Audio Codecs das Kodieren von Video und Audio zu unterschiedlichen Datenraten erlauben. In der Regel gilt je niedriger die Datenrate, desto niedriger auch die Qualität beziehungsweise der Nutzen des Videos. Dieser Zusammenhang ist jedoch keineswegs linear. Darüber hinaus können einige Codecs Redundanzen enthalten, sodass diese mit Paketverlust umgehen können. Doch auch hier ist bei Paketverlust mit Einbußen in der Audiooder Videoqualität zu rechnen. Eine Video-Telefonie-Anwendung kann jedoch mehrere Codecs oder mehrere Konfigurationen desselben Codecs besitzen, die jeweils mit unterschiedlichen Kommunikationsbedingungen umgehen können und während der Laufzeit gewechselt werden können. Die daraus resultierende Nutzenfunktion kann sehr applikationsspezifisch sein und zusätzlich davon abhängen, welche der verfügbaren Codecs ebenfalls von der anderen Endstelle unterstützt werden. Eine sinnvolle Optimierung der Zuweisung von Kommunikationsressourcen zu Applikationen kann ohne Wissen über diese Nutzenfunktion nicht erfolgen.
Fig. 9 zeigt ein Ablaufdiagramm eines Verfahrens 900 zum Steuern eines Datenverkehrs gemäß einem Ausführungsbeispiel. Lediglich beispielhaft handelt es sich dabei um ein iteratives Verfahren, das in mehreren Schritten 905, 910, 915, 920, 925, 930 abläuft.
In einem ersten Schritt 905 des Einlesens wird ein erstes Anforderungssignal und ein zweites Anforderungssignal über eine Funktionsschnittstelle zu einer ersten Funktionseinheit und einer zweiten Funktionseinheit eingelesen. Dabei repräsentiert das erste Anforderungssignal eine erste Anforderung der ersten Funktionseinheit an eine zukünftig benötigte Kapazität für den Datenverkehr zum Übertragen von ersten Funktionsdaten und das zweite Anforderungssignals repräsentiert eine zweite Anforderung der zweiten Funktionseinheit an eine zukünftig benötigte Kapazität für den Datenverkehr zum Übertragen von zweiten Funktionsdaten. Anders ausgedrückt werden in diesem Schritt 905 Anforderungen an die Kommunikationseigenschaften von den Softwarefunktionen gesammelt. Diese Anforderungen bestehen in diesem Ausführungsbeispiel aus Deadlines und Nutzenfunktionen. Dabei können nicht nur die Funktionen innerhalb des Fahrzeugs Anforderungen stellen, sondern auch die Kommunikationspartner außerhalb des Fahrzeuges, in dem die Steuervorrichtung betrieben wird.
In einem Ausführungsbeispiel folgt auf den Schritt 905 des Einlesens ein optionaler Schritt 910 des Empfangens eines Routensignals. Dabei wird der wahrscheinliche zukünftige Fahrtweg beziehungsweise der aktuelle MPP empfangen. Dieser beschreibt den Pfad, den das Fahrzeug in Zukunft entlangfahren wird.
Lediglich optional umfasst das Verfahren 900 weiterhin einen Schritt 915 des Einlesens eines Netzsignals, das eine entlang der Route bestehende und von einer Funknetzabdeckung abhängige Größe einer maximalen Kapazität für den Datenverkehr repräsentiert. In diesem Ausführungsbeispiel wird in diesem Schritt 915 eine Mobilfunkabdeckungskarte entlang des MPP abgefragt. Die Mobilfunkabdeckungskarte liefert entsprechend eine Prognose darüber, welche Kommunikationseigenschaften, das heißt welche verfügbare Datenrate, Latenz, Paketfehlerrate, Jitter, etc., an jedem Punkt des MPP zu erwarten ist. In diesem Ausführungsbeispiel folgt ein Schritt 920 des Berechnens, in dem ein Zeitplan berechnet wird, der angibt, welche Softwarefunktion zu welcher Zeit wie viele Daten über ein Modem, beispielsweise ein LTE-Modem, senden beziehungsweise empfangen darf. Dieser Zeitplan wird lediglich beispielhaft so berechnet, dass die von einer Optimierungseinrichtung der Steuervorrichtung gewählte Zielfunktion maximiert wird. Dabei wird der Zeitplan in diesem Ausführungsbeispiel mittels mathematischer Optimierung gefunden. Nach dem Schritt 920 des Berechnens beginnt die Steuervorrichtung in diesem Ausführungsbeispiel erneut mit dem Schritt 905 des Einlesens des ersten und zweiten Anforderungssignals. Lediglich beispielhaft werden gleichzeitig der Schritt 925 des Bestimmens und ein beispielhafter Schritt 930 des Formens ausgeführt.
Im Schritt 925 des Bestimmens wird ein erstes Kapazitätssignal und ein zweites Kapazitätssignal bestimmt. Das Bestimmen wird unter Verwendung des optionalen Routensignals, des Netzsignals, des ersten Anforderungssignals und des zweiten Anforderungssignals ausgeführt. Dabei repräsentiert das erste Kapazitätssignal eine für die erste Funktionseinheit zukünftig bereitstehende erste Teilkapazität und das zweite Kapazitätssignal repräsentiert eine für die zweite Funktionseinheit zukünftig bereitstehende zweite Teilkapazität, um den Funktionseinheiten eine Anpassung der zukünftig benötigten Kapazitäten an die zukünftig bereitstehenden Teilkapazitäten zu ermöglichen. Anders ausgedrückt wird in diesem Schritt 925 jede Softwarekomponente, die Anforderungen gestellt hat, darüber informiert, zu welcher Zeit diese mit welchen Kommunikationseigenschaften rechnen kann.
Im Schritt 930 des Formens wird in diesem Ausführungsbeispiel eine Verkehrsformungseinrichtung der Steuervorrichtung angewiesen, die Datenflüsse gemäß des berechneten Zeitplans zu formen. In diesem Ausführungsbeispiel befindet sich lediglich beispielhaft eine sogenannte Legacy Software im Fahrzeug. Wenn die Legacy Anwendung viele Daten erzeugt, die aber aufgrund der Resourcenknappheit nicht transportiert werden können, werden die erzeugten Daten durch das Traffic Shaping verworfen. Fig. 10 zeigt ein Ablaufdiagramm eines Ausführungsbeispiels eines Schritts 905 des Verfahrens 900 Steuern eines Datenverkehrs. Der hier beschriebene Schritt 905 entspricht oder ähnelt dem in der vorangegangenen Figur 9 beschriebenen Schritt des Einlesens eines Anforderungssignals. Dabei ist der hier dargestellte Schritt 905 des Einlesens in vier Teilschritte unterteilt. Im ersten Teilschritt 1000 werden die Parameter eines fahrzeuginternen Sensors bestimmt. Im zweiten Teilschritt 1005 wird aus den Parametern eine interne, mehrdimensionale Nutzenfunktion bestimmt. Im dritten Teilschritt 1010 wird eine konkrete Anforderung einer Funktionseinheit an eine zukünftig benötigte Kapazität für den Datenverkehr zum Übertragen von Funktionsdaten erstellt. Im vierten Teilschritt 1015 wird diese Anforderung in Form eines Anforderungssignals von einer Bestimmungseinrichtung der Steuervorrichtung eingelesen und eine der Anforderung entsprechende Teilkapazität von einer Optimierungseinrichtung der Bestimmungseinrichtung berechnet. In diesem Ausführungsbeispiel hat die interne Nutzenfunktionen höhere Dimensionen, wobei einige dieser Dimensionen sogenannte interne Parameter sind, bei denen es sich lediglich beispielhaft um die aktuelle Fahrgeschwindigkeit und die Entfernung zum nächstgelegenen Objekt handelt. Solche internen Nutzenfunktionen werden verwendet, um die eigentlichen Nutzenfunktionen abzuleiten, die an den zentralen Optimierer des Netzwerksystems weitergegeben werden.
Fig. 10 zeigt ein Ablaufdiagramm eines Ausführungsbeispiels eines Schritts 905 des Verfahrens 900 Steuern eines Datenverkehrs. Der hier beschriebene Schritt 905 entspricht oder ähnelt dem in den vorangegangenen Figuren 9 und 10 beschriebenen Schritt des Einlesens eines Anforderungssignals und ist kongruent zu dem in der vorangegangenen Figur 10 beschriebenen Ablauf in vier Teilschritte 1000, 1005, 1010, 1015 unterteilt. Dabei umfasst die interne Nutzenfunktion in diesem Ausführungsbeispiel drei Dimensionen, wobei eine davon der Fahrzeugzustand ist. Da der Fahrzeugzustand ein interner Parameter des Fahrzeugs und außerhalb der Domäne für das partizipative Netzwerk ist, wird die aktuelle Fahrzeuggeschwindigkeit verwendet, um eine zweidimensionale Nutzenfunktion, bestehend aus den Achsen Nutzen und Datenrate, zu extrahieren, die dann an den zentralen Optimierer weitergegeben wird. Jedes Mal, wenn sich die Fahrzeuggeschwindigkeit ändert, sendet das Fahrzeug eine aktualisierte Nutzenfunktion an den Optimierer. In anderen Ausführungsbeispielen können beliebige n-dimensionale interne Nutzenfunktionen und m-dimensionale Nutzenfunktionen (mit n >= m) verwendet werden. Um nicht ständig aktualisierte Nutzenfunktionen an den Optimierer zu senden, sollte die Anwendung dies nur tun, wenn die Aktualisierung der Nutzenfunktion signifikant ist.

Claims

- 29 -
Ansprüche
1. Steuervorrichtung (100) zum Steuern eines von Funktionseinheiten (105, 110) eines Fahrzeugs (115) generierten Datenverkehrs über eine Funkeinrichtung (120) des Fahrzeugs (115), wobei die Steuervorrichtung (100) folgende Merkmale aufweist: eine Funktionsschnittstelle (125) zum Verbinden der Steuervorrichtung (100) mit einer ersten Funktionseinheit (105) und einer zweiten Funktionseinheit (110) und zum Einlesen eines ersten Anforderungssignals (130), das eine erste Anforderung der ersten Funktionseinheit (105) an eine zukünftig benötigte Kapazität für den Datenverkehr zum Übertragen von ersten Funktionsdaten repräsentiert, und eines zweiten Anforderungssignals (135), das eine zweite Anforderung der zweiten Funktionseinheit (110) an eine zukünftig benötigte Kapazität für den Datenverkehr zum Übertragen von zweiten Funktionsdaten repräsentiert; eine Übertragungsschnittstelle (140) zum Verbinden der Steuervorrichtung (100) mit der Funkeinrichtung (120); und eine Bestimmungseinrichtung (160), die ausgebildet ist, um unter Verwendung eines Netzsignals (150), das eine entlang einer wahrscheinlichen zukünftigen Route (146) des Fahrzeugs (115) bestehende und von einer Funknetzabdeckung abhängige Größe einer maximalen Kapazität für den Datenverkehr repräsentiert, des ersten Anforderungssignals (130) und des zweiten Anforderungssignals (135) ein erstes Kapazitätssignal (165) zu bestimmen, das eine für die erste Funktionseinheit (105) zukünftig bereitstehende erste Teilkapazität repräsentiert, und ein zweites Kapazitätssignal (170) zu bestimmen, das eine für die zweite Funktionseinheit (110) zukünftig bereitstehende zweite Teilkapazität repräsentiert, um den Funktionseinheiten (105, 110) eine Anpassung der zukünftig benötigten Kapazitäten an die zukünftig bereitstehenden Teilkapazitäten zu ermöglichen. - 30 - Steuervorrichtung (100) gemäß Anspruch 1, bei der die Bestimmungseinrichtung (160) ausgebildet ist, um das erste Kapazitätssignal (165) und das zweite Kapazitätssignal (170) unter Verwendung eines Routensignals (145) zu bestimmen, das die wahrscheinliche zukünftige Route (146) des Fahrzeugs (115) repräsentiert. Steuervorrichtung (100) gemäß einem der vorangegangenen Ansprüche, wobei die Bestimmungseinrichtung (160) ausgebildet ist, um eine Zuteilung der Teilkapazitäten für den Datenverkehr zu den Funktionseinheiten (105, 110) zu berechnen und die Kapazitätssignale (165, 170) über die Funktionsschnittstelle (125) an die Funktionseinheiten (105, 110) bereitzustellen. Steuervorrichtung (100) gemäß Anspruch 2, wobei die Bestimmungseinrichtung (160) ausgebildet ist, um das Routensignal (145) über die Funktionsschnittstelle (125) einzulesen. Steuervorrichtung (100) gemäß einem der vorangegangenen Ansprüche, wobei die Bestimmungseinrichtung (160) ausgebildet ist, um das Netzsignal (150) über die Übertragungsschnittstelle (140) einzulesen. Steuervorrichtung (100) gemäß Anspruch 2, wobei die Bestimmungseinrichtung (160) eine Optimierungseinrichtung (230) umfasst, die ausgebildet ist, um unter Verwendung des Routensignals (145), des Netzsignals (150), des ersten Anforderungssignals (130) und des zweiten Anforderungssignals (135) die erste Teilkapazität und die zweite Teilkapazität zu berechnen und die Teilkapazitäten den Funktionseinheiten (105, 110) zuzuordnen. Steuervorrichtung (100) gemäß Anspruch 6, wobei die Optimierungseinrichtung (230) ausgebildet ist, die Route (146) mit einer mittels der Übertragungsschnittstelle (140) bereitgestellten und die Funknetzabdeckung abbildenden Mobilfunkabdeckungskarte (235) abzugleichen, um einen zeitlichen Verlauf der Größe der zukünftigen maximalen Kapazität für den Datenverkehr zu bestimmen. Steuervorrichtung (100) gemäß einem der vorangegangenen Ansprüche, wobei die Bestimmungseinrichtung (160) eine Prognoseeinrichtung (240) umfasst, die ausgebildet ist, um das erste und das zweite Kapazitätssignal (170) bereitzustellen. Steuervorrichtung (100) gemäß einem der vorangegangenen Ansprüche, wobei die Bestimmungseinrichtung (160) ausgebildet ist, um ein die ersten Funktionsdaten umfassendes erstes Funktionssignal (180) und ein die zweiten Funktionsdaten umfassendes zweites Funktionssignal (185) über die Funktionsschnittstelle (125) einzulesen und an die Übertragungsschnittstelle (140) bereitzustellen. Steuervorrichtung (100) gemäß einem der vorangegangenen Ansprüche, wobei die Bestimmungseinrichtung (160) eine Verkehrsformungseinrichtung (250) umfasst, die ausgebildet ist, um unter Verwendung des ersten Kapazitätssignals (165) die ersten Funktionsdaten und unter Verwendung des zweiten Kapazitätssignals (170) die zweiten Funktionsdaten über die Übertragungsschnittstelle (140) auszugeben. Steuervorrichtung (100) gemäß einem der vorangegangenen Ansprüche, wobei die erste Anforderung und/oder die zweite Anforderung eine Nutzenfunktion (300) umfasst, wobei die Nutzenfunktion (300) den Nutzen bestimmter Eigenschaften des Datenverkehrs beschreibt. Steuervorrichtung (100) gemäß Anspruch 11, wobei die Nutzenfunktion (300) unter Verwendung eines Allokationsplans (600) bestimmbar ist. Steuervorrichtung (100) gemäß einem der vorangegangenen Ansprüche, wobei die erste Anforderung und/oder die zweite Anforderung eine Ablauffrist zum Definieren eines Endzeitpunkts des Übertragens von Funktionsdaten umfasst. Fahrzeugsystem (200), das folgende Merkmale aufweist: eine Steuervorrichtung (100) gemäß einem der vorangegangenen Ansprüche; eine Mehrzahl von Funktionseinheiten (105, 110, 205), die ausgebildet sind, um Anforderungssignale (130, 135) bereitzustellen, die Anforderungen der Funktionseinheiten (105, 110, 205) an eine zukünftig benötigte Kapazität von Datenverkehr zum Übertragen von Funktionsdaten repräsentieren, Kapazitätssignale (165, 170) zu empfangen, die für die Funktionseinheiten (105, 110, 205) zukünftig bereitstehende Teilkapazitäten repräsentieren, und Funktionssignale (180, 185) bereitzustellen, die die Funktionsdaten repräsentieren; und eine Funkeinrichtung (120), mit mindestens einem Kommunikationsmittel (210) zum Senden und Empfangen von Daten über ein Funknetz (215), einer Funkschnittstelle (220) zum Verbinden des Kommunikationsmittel s (210) mit dem Funknetz (215) und eine Übertragungsschnittstelle (140) zum Verbinden der Funkeinrichtung (120) mit der Steuervorrichtung (100), wobei die Funkeinrichtung (120) ausgebildet ist, um Funktionssignale (180, 185) über die Übertragungsschnittstelle (140) einzulesen. Verfahren (900) zum Steuern eines von Funktionseinheiten (105, 110) eines Fahrzeugs (115) generierten Datenverkehrs über eine Funkeinrichtung (120) des Fahrzeugs (115), wobei das Verfahren (900) folgende Schritte (905, 925) umfasst:
Einlesen (905) eines ersten Anforderungssignals (130) und eines zweiten Anforderungssignals (135) über eine Funktionsschnittstelle (125) zu einer ersten Funktionseinheit (105) und einer zweiten Funktionseinheit (110), wobei das erste Anforderungssignal (130) eine erste Anforderung der ersten Funktionseinheit (105) an eine zukünftig benötigte Kapazität für den Datenverkehr zum Übertragen von ersten Funktionsdaten repräsentiert und das zweite Anforderungssignal (135) eine zweite Anforderung der zweiten Funktionseinheit (110) an eine - 33 - zukünftig benötigte Kapazität für den Datenverkehr zum Übertragen von zweiten Funktionsdaten repräsentiert; und
Bestimmen (925) eines ersten Kapazitätssignals (165) und eines zweiten Kapazitätssignals (170) unter Verwendung eines Netzsignals
(150), das eine entlang einer wahrscheinlichen zukünftigen Route (146) des Fahrzeugs (115) bestehende und von einer Funknetzabdeckung abhängige Größe einer maximalen Kapazität für den Datenverkehr repräsentiert, des ersten Anforderungssignals (130) und des zweiten Anforderungssignals (135), wobei das erste Kapazitätssignal (165) eine für die erste Funktionseinheit (105) zukünftig bereitstehende erste Teilkapazität repräsentiert, und wobei das zweite Kapazitätssignal (170) eine für die zweite Funktionseinheit (110) zukünftig bereitstehende zweite Teilkapazität repräsentiert, um den Funktionseinheiten (105, 110) eine Anpassung der zukünftig benötigten Kapazitäten an die zukünftig bereitstehenden Teilkapazitäten zu ermöglichen.
PCT/EP2022/069073 2021-09-07 2022-07-08 Steuervorrichtung und verfahren zum steuern eines datenverkehrs eines fahrzeugs und fahrzeugsystem WO2023036494A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202280074241.3A CN118202704A (zh) 2021-09-07 2022-07-08 用于控制车辆的数据交通的控制设备和方法以及车辆系统

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102021209844.4 2021-09-07
DE102021209844.4A DE102021209844A1 (de) 2021-09-07 2021-09-07 Steuervorrichtung und Verfahren zum Steuern eines Datenverkehrs eines Fahrzeugs und Fahrzeugsystem

Publications (1)

Publication Number Publication Date
WO2023036494A1 true WO2023036494A1 (de) 2023-03-16

Family

ID=82748258

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2022/069073 WO2023036494A1 (de) 2021-09-07 2022-07-08 Steuervorrichtung und verfahren zum steuern eines datenverkehrs eines fahrzeugs und fahrzeugsystem

Country Status (3)

Country Link
CN (1) CN118202704A (de)
DE (1) DE102021209844A1 (de)
WO (1) WO2023036494A1 (de)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3079293B1 (de) * 2015-04-07 2019-01-30 Dejero Labs Inc. System und verfahren zur bereitstellung von datendiensten an fahrzeuge
US20210114616A1 (en) * 2017-05-18 2021-04-22 Liveu Ltd. Device, system, and method of wireless multiple-link vehicular communication

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3079293B1 (de) * 2015-04-07 2019-01-30 Dejero Labs Inc. System und verfahren zur bereitstellung von datendiensten an fahrzeuge
US20210114616A1 (en) * 2017-05-18 2021-04-22 Liveu Ltd. Device, system, and method of wireless multiple-link vehicular communication

Also Published As

Publication number Publication date
DE102021209844A1 (de) 2023-03-09
CN118202704A (zh) 2024-06-14

Similar Documents

Publication Publication Date Title
DE60210733T2 (de) System und Verfahren zur Überlastregelung in Netzwerken
DE112016002847B4 (de) Dienstgüte in einem drahtlosen Backhaul
DE602004004516T2 (de) Verfahren und Vorrichtung zur Datenprotokollierung
DE102015200422A1 (de) Fahrzeugspezifisches Berechnungsmanagementsystem für Cloud-Datenverarbeitung
EP3899723A1 (de) Verfahren zum management von rechnerkapazitäten in einem netzwerk mit mobilen teilnehmern
EP3948464A1 (de) Verfahren und vorrichtung zum steuern eines fahrzeuges durch einen teleoperator
EP4055848A1 (de) Verfahren zum übertragen einer nachricht in einem kommunikationsnetzwerk zur kommunikation zwischen einem verkehrsteilnehmer und mindestens einem weiteren verkehrsteilnehmer
DE112012006248B4 (de) Datenverarbeitungsvorrichtung und Programm
WO2023036494A1 (de) Steuervorrichtung und verfahren zum steuern eines datenverkehrs eines fahrzeugs und fahrzeugsystem
DE102019211347B4 (de) Datenübertragung zwischen einem Kraftfahrzeug und einem Mobilfunknetz
WO2020127080A1 (de) Telematik-steuergerät mit dispatcher für "always on" funkverbindungen
DE102021107787A1 (de) Dynamische Dienstqualitätssteuerung für Kraftfahrzeug-Ethernet
WO2022117167A1 (de) Verfahren zum schnellen flashen von sensorknoten über ein ethernetnetzwerk
EP2683184B1 (de) Verfahren zur Datenübertragung und Kommunikationssytem
DE102020215763A1 (de) Verfahren zur Optimierung der Übertragungsdatenrate in einem Sensornetzwerk im Teilnetzbetrieb in einem Ethernetnetzwerk
DE102019213562A1 (de) Verfahren zur Berechnung einer Funktion für ein Fahrzeug
EP3668050A1 (de) Anpassen einer software-anwendung, die auf einem gateway ausgeführt wird
DE102017223568A1 (de) Verfahren zur Steigerung einer Netzwerkressourcennutzung und Bereitstellung genügender Service-Qualität
EP3838709B1 (de) Verfahren zur übergabe von telegrammen von einer streckenzentrale an ein fahrzeug und streckenzentrale
DE102022127847A1 (de) System und Verfahren für cloud-koordinierte Fahrzeugdatensammlung
DE102017217057A1 (de) Verfahren und Vorrichtung zum Aufbau eines Kommunikationskanals zwischen einer ersten und einer zweiten Einrichtung
WO2023094354A1 (de) Partizipatives sicherheitsprotokoll für datenwolken-basierte funktionen
EP3069565B1 (de) Verfahren und vorrichtung für eine dynamische regelung von bandbreite in einer kommunikationsanordnung
DE102020000498A1 (de) Managementvorrichtung und Applikationsvorrichtung für ein Fahrzeugkommunikationssystem
DE102019213563A1 (de) Verfahren zur Berechnung einer Funktion für ein Fahrzeug

Legal Events

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

Ref document number: 22748309

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2022748309

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2022748309

Country of ref document: EP

Effective date: 20240408