DE102010005682B4 - Method and device for processing data in a vehicle - Google Patents

Abstract

A method of processing data in a vehicle network, - wherein data is received via the vehicle network, the received data comprising data packets, each data packet containing a presentation time in the form of a time stamp; In which the received data is processed in the vehicle network by checking by an application layer whether a presentation time determined on the basis of the data has been reached, both of which the processed data are output, if the presentation time has been reached, and in which the processed data is buffered if the presentation time has not yet been reached; wherein the application layer is provided by means of an application running on a sink or executable; and wherein the received data are decoded and / or decompressed based on the application and optionally output.

Description

The invention relates to a method for processing data in a vehicle and to an associated device. Furthermore, a vehicle is proposed comprising at least one such device.

In a vehicle, there are different communication elements that z. B. over a network, eg. As an Ethernet, are interconnected. Data can be exchanged between the communication elements using known protocols and mechanisms.

In particular, audio and / or video content in the vehicle is increasingly transmitted over such a network. In principle, there is the problem that z. B. the transmission of digitized data (eg., As data streams) can take place in the form of individual data packets and often logically related data streams, eg. As audio information and image information to be transmitted in separate data streams over the network. For one or more receivers, however, it must be ensured that the output of the data streams (eg the audio and video information) takes place synchronously, since otherwise the sound does not match the images displayed.

In this regard, Audio Video Bridging (AVB) technology enables the transport of time-synchronous audio and video data with low delay, utilizing quality of service (Qo5) over an Ethernet connection. An audiovisual data stream (A / V stream) is identifiable by an identifier (StreamID) according to AVB. This identifier includes a MAC address of an AVB source.

US 2006/0077994 A1 discloses a system and method for dynamically adapting a de jitter buffer to compensate for jitter in a VoIP system. In particular, the de jitter buffer adapts dynamically to current runtime conditions of the various data packets. The adjustment of the de jitter buffer is carried out by a compression or expansion of the data packets, which are located in the de jitter buffer.

US 2002/0031086 A1 discloses a method for processing first and second data packets comprising real-time data. The method includes calculating a deadline interval and processing the data packets according to the calculated deadline intervals. On the receiver side, the deadline interval is extracted from each data packet and the packets are placed in a processing list corresponding to the extracted deadline interval (prioritization). In a further step, the data packets are decoded by a decoder according to their priority.

US 2006/0072627 A1 discloses a system for synchronizing audiovisual data streams (A / V streams). In particular, after compressing a set of A / V data, the compressed data is transmitted to a delay unit which determines the time of presentation of the compressed data ("Presentation Time Stamp, PTS") and the time of decoding of a picture ("Decoding Time Stamp, DTS ") by a predefined or static clock signal (predefined delay time).

Furthermore, a transport protocol according to IEEE 1722 is known ("AVB Transport Protocol"). An Ethernet frame here comprises an IEEE P1722 data stream, wherein a packet of the data stream comprises a presentation time (also referred to as AVB TP time stamp or AVB TP Time Stamp). By means of the AVB technology, it is already possible to determine on layer 2 by analysis of the so-called ether type whether the IEEE 1722 packet is AN data or other information (eg other IP data). Therefore, the IEEE 1722 package does not need to be laboriously parsed across multiple layers of a protocol stack before the type of data content can be determined. The mentioned presentation time is determined by the AVB source. The IEEE 1722 package includes payload, z. In the form of an IEC 61883 package. Accordingly, other AN formats can be used.

It is disadvantageous that the presentation time currently defined in IEEE 1722 is often not sufficient to actually achieve a synchronous reproduction or output in the case of distributed AVB sources and AVB sinks. This is particularly relevant if non-transparent, directly reproduceable audio data is sent over the network instead of compressed audio and / or video data, which may initially be processed at different sinks (eg decoded and / or decompressed) and then (lip-shaped). ) must be output synchronously. With different run times first through the network and different processing times (for decoding or decompression), asynchronous rendering can easily occur. Furthermore, the additional temporal uncertainty due to the processing at the network level requires a significantly higher accuracy of the time.

The object of the invention is to avoid the disadvantages mentioned above and in particular to provide a solution which is efficient and timely, in particular time-synchronized Output of audio and / or video data on at least one sink allows.

• – bei dem Daten über das Fahrzeugnetzwerk empfangen werden, wobei die empfangenen Daten Datenpakete umfassen, wobei jedes Datenpaket eine Präsentationszeit in Form eines Zeitstempels enthält;
• – bei dem die empfangenen Daten im Fahrzeugnetzwerk verarbeitet werden, indem von einer Anwendungsschicht geprüft wird, ob eine anhand der Daten ermittelte Präsentationszeit erreicht ist,
• – bei dem die verarbeiteten Daten ausgegeben werden, falls die Präsentationszeit erreicht ist und
• – bei dem die verarbeiteten Daten zwischengespeichert werden, falls die Präsentationszeit noch nicht erreicht ist; wobei die Anwendungsschicht anhand einer auf einer Senke ablaufenden oder ablauffähigen Applikation bereitgestellt wird; und wobei die empfangenen Daten anhand der Applikation dekodiert und/oder dekomprimiert und gegebenenfalls ausgegeben werden.

This object is achieved according to the features of the independent claims. Further developments of the invention will become apparent from the dependent claims. To achieve the object, a method for processing data in a vehicle network is proposed,

• In which data is received via the vehicle network, the received data comprising data packets, each data packet containing a presentation time in the form of a time stamp;
• In which the received data is processed in the vehicle network by checking by an application layer whether a presentation time determined on the basis of the data has been reached,
• - in which the processed data are output, if the presentation time is reached and
• - where the processed data is cached, if the presentation time has not yet been reached; wherein the application layer is provided by means of an application running on a sink or executable; and wherein the received data is decoded and / or decompressed based on the application and optionally output.

In this case, it is advantageous for the application layer to carry out the evaluation of the presentation time and, if appropriate, to cache the already decoded and / or decompressed expansible data. Thus, the data thus processed can be output immediately upon reaching the presentation time. Another advantage is that by checking the presentation time on the application layer no time-consuming determination of processing times, eg. On layer-1 of the individual components of the network, because the network in the vehicle may be dimensioned so that a certain predetermined maximum delay time for the transmission of data between a source and a sink is not exceeded, and thus the timely output of the data at the sink is ensured. Accordingly, the sink or the receiver can perform an evaluation on layer 7 in order to adhere to the given presentation time for the output of the data. This is a synchronous output of the data, eg. B. several (audio and / or video) data streams at a sink or at several wells ensured.

Thus, the accuracy requirement for the time used in the network (network time) can only be determined based on the application requirements and (largely) independently of processing times.

In particular, the cached data can be output upon reaching the presentation time.

A further development is that the vehicle network is a packet-oriented network.

In particular, it may be an Ethernet or an IP-based network.

Another development is that the vehicle network comprises a wired network and / or a radio network.

Thus, for example, the network may have a wireless network, e.g. B. a wireless LAN (WLAN) or at least a Bluetooth connection.

In particular, it is a further development that the received data comprise data packets with audio information and / or video information.

It is also a further development that the audio information is output via at least one loudspeaker and the video information is output via at least one display unit.

Through the approach presented here, the contents can be output (lip) synchronously on display units and speakers.

In particular, these may be data packets according to an AVB protocol or based on an AVB protocol.

An embodiment is that the processed data is buffered in a buffer.

The buffer may be any data store which is located in particular in the sink or can be used by it.

An alternative embodiment is that the size of the buffer memory is determined depending on a maximum expected delay.

It should be noted here that the maximum delay to be expected comprises a delay due to the data transmission in the network as well as a processing time in the respective components of the network.

A next refinement is that several components of the vehicle network are synchronized so that the output of the processed data is based on a common time base.

The common time base of the multiple components of the network may be determined by means of an appropriate protocol, e.g. As a PTP (Precision Time Protocol, according to IEEE 1588 or IEEE 802.1AS) can be achieved. Based on the synchronized components of the network, it is possible that the presentation time is interpreted in the same way in different components and thus the output can be time-synchronized in distributed components.

The above object is also achieved by means of a device comprising a processing unit which is set up in such a way that the method described herein can be executed.

In particular, a device is provided with a processing unit which is set up such that the method according to one of claims 1 to 8 can be executed.

The processing unit may, for. It may be implemented as a processor and / or at least partially hard-wired circuitry arranged to perform the method as described herein. The processor may be or include any type of processor or computer or computer with correspondingly necessary peripherals (memory, input / output interfaces, input / output devices, etc.). Furthermore, a hardwired circuit unit, for. As an FPGA or an ASIC or other integrated circuit may be provided.

One embodiment is that the device comprises a loudspeaker unit and / or a display unit for outputting the processed data.

A next embodiment is that the device comprises a control device or part of a control device of a vehicle.

Also, the above object is achieved by means of a vehicle comprising at least one of the devices described herein.

Embodiments of the invention are illustrated and explained below with reference to the drawings.

Show it:

1 schematically a network that connects by way of example a source with two wells;

2 a schematic representation of a sink, which is connected via an interface (interface, IFC) with a line of a network.

The approach presented here allows audio and / or video data transmitted from at least one sink to be output at a predeterminable presentation time. This is particularly advantageous when outputting audio and video data lip-sync and / or when audio and / or video data are to be output at different sinks at the same time.

The sources and sinks are, in particular, components that are connected via a communications network, e.g. As an Ethernet, are interconnected. In particular, they may be sources and sinks that at least partially use or are based on AVB technology.

The source may be a head unit of a vehicle or another control device of a vehicle, in particular audio and / or video data, eg. B. in the form of packetized data streams, via a network of the vehicle provides the sinks. The sinks can be components of the network that output the data. So z. For example, a display unit with a network interface or a speaker unit with a network interface may be provided. Also, combined display and speaker units with a common network interface are possible. The display unit and the loudspeaker unit can each have a processing unit, by means of which a signal arriving via the network interface is converted into a signal that can be output.

So z. B. be arranged at different locations in the vehicle depending on a speaker unit with a network interface. Through the network, the speaker unit is supplied with the output (audio) data. In particular, the loudspeaker unit has a control unit which converts the data from the network interface into reproducible audio data (eg analogue signals) and, for example. B. via an analog amplifier, at least one speaker controls.

In particular, the network includes at least one router or bridge located between the source and the at least one sink. The data transmission can therefore take different lengths depending on the path through the network. In addition, when outputting or reproducing the data in the sink, processing, e.g. As decoding, decompression and / or (format) conversion. The necessary for this Processing time may vary depending on the sink. However, the output of the audiovisual information synchronized between sound and image information so in particular synonymous between different sinks done synchronized.

This is achieved by synchronizing the sink in the vehicle in the network with the other components of the network. This can be z. B. by means of a suitable protocol, for. As a PTP (Precision Time Protocol, according to IEEE 1588 or IEEE 802.1AS) can be achieved.

Furthermore, in the vehicle, the network topology can be designed or dimensioned so that a worst-case estimate for periods of data packets in a fault-free functioning, for example, network is relatively accurate. In contrast to the network of the vehicle is z. For example, the topology of the public Internet is subject to large fluctuations and changes, whereby the individual user or subscriber knows neither the topology nor its changes. so far, it is very difficult to impossible for the topology of the Internet to predict the transit time differences with high certainty.

In the vehicle, the communication network used is preferably designed statically for the life of the vehicle, i. H. the network itself is hardly changed, the components, eg. As switches, bridges or routers remain unchanged (except for a possible replacement in case of error) as well as the topology of the network. Thus, the communication paths between the sources and sinks are largely static. An estimate of the expected maturities is therefore possible with high reliability. Accordingly, the communication network in the vehicle can be designed so that certain specifications regarding the maximum transit times along the communication paths are met.

Now, the processing of the data received in the sink can be performed on an application layer, because a maximum expected delay is predetermined by the appropriate design of the communication network in the vehicle. The sink has a data memory (buffer) which stores incoming data packets. This storage occurs at the application layer, i. H. the data packets arriving in the sink are unpacked layer by layer and it is checked in the application layer whether the data packet can already be output due to the presentation time contained in the data packet. If the presentation time is the synchronized time of the sink (eg, taking into account a maximum allowed deviation of the presentation time from the synchronized time of the sink), then the audio and / or video data of the data packet is output. Otherwise, the audio and / or video data may be cached in the buffer until the synchronized time of the sink corresponds to the presentation time and the cached data can be output.

1 schematically shows a network 104 , the example of a source 101 with two depressions 102 . 103 combines. The network is preferably set up for packet-oriented data transmission, that is, for example, an Ethernet (layer 2) or the network uses an Internet protocol (IP, layer 3).

It should be noted that the network is a wired network or a wireless network, eg. As a wireless LAN may include.

In the network 104 are several connecting nodes 105 to 108 included, the z. B. can be executed as a router or bridge. For example, in 1 the source 101 with the node 105 and the node 106 connected, the node 105 is just like the knot 106 also with the knot 107 connected and the node 107 is with both the node 108 as well as with the sink 103 connected. The knot 108 is still with the sink 102 connected.

In this respect, there are different data paths to data packets from the source 101 to the valleys 102 . 103 to transport. In this way or due to the processing of the data packets in the individual nodes 105 to 108 There may be different delays or delays before a data packet from the source sinks 102 . 103 reached. In the valleys 102 . 103 the received data packet is, for example, first decoded or decompressed before z. B. can be output as sound and / or image information. Depending on the sink, this processing of the data in the sink may take a different amount of time and additionally delay the output of the data.

An exemplary scenario for the in 1 Topology shown is the use in a vehicle, ie the source 101 , Reduce 102 . 103 as well as the network 104 with the knots 105 to 108 are arranged in the vehicle. At the source 101 it may be a (eg, central) controller (eg, a head unit) of the vehicle that supplies the audio and / or video data to the sinks 102 . 103 transfers. The valleys 102 . 103 may be display units and / or speaker units having an interface for connection to the network and a processing unit to receive the data from the network suitable process (eg decode, decompress) and z. B. to be able to spend on a display and / or a speaker.

The source 101 may use a known data format and / or protocol when sending the data. For example, the transport protocol allows for IEEE 1722 the allocation of a presentation time, at which the audio / video data contained in the respective data package is to be output. In the valley 102 . 103 An evaluation of the presentation time can be made and an issue taking into account this presentation time.

Since it is a largely closed system in the vehicle, so z. For example, the topology of the network 104 is not changed for the duration of the use of the vehicle is usually a reliable estimate of usual maximum delay times (ie delay times, which are met with high security) when transmitting from the source 101 to the valleys 102 . 103 respectively. Such an estimate can be used to ensure that data packets are sent to the source 101 at a current time t stating a (future) presentation time T so timely that, despite the maximum delay time td by the transmission in the network and the processing of the data (in the source and) in the sinks, the data packets before expiry of the presentation time T can be output from the respective sink, ie: T> t + td.

Due to the static network topology in the vehicle, the maximum delay time td z. B. be determined in advance quite accurately.

It should be noted that the maximum delay time td z. B. can be determined by means of a worst-case estimate taking into account usual scenarios. This malfunction of a network component or a failure of the network component or the network may be disregarded or are optionally treated by means of a separate error model. The maximum delay time td should advantageously be dimensioned based on usual delays in the functioning operation of the network and the connected components, so that (only) the running times or processing times are taken into account accordingly. As a result, the premise that the network and components work ensures that the maximum delay time, td, is less than infinity.

When sending the data packets to the source, ensure that the presentation time T is further in the future than this maximum delay time td. Then it can be ensured at each source that the output or the reproduction of the received information takes place synchronously, ie simultaneously. Thus, the same information can be displayed in the vehicle at different display units or a synchronized audio information is output via different loudspeakers of the vehicle.

Since the data packets can also arrive at the sink much earlier than at time t + td, the sinks preferably have a buffer or buffer store in which the received audio video data are stored until their presentation time is reached.

In particular, it is advantageous that the individual components, in particular the source 101 and the valleys 102 . 103 synchronized with each other, ie have a common time base. This can be z. B. by means of a suitable protocol, for. As a PTP (Precision Time Protocol, according to IEEE 1588 or IEEE 802.1AS) can be achieved.

2 shows a schematic representation of a sink 201 , which have an interface (Interface, IFC) 203 with a line 202 of the network (see 1 , not in 2 shown) is connected.

the interface 203 is with a processing unit 204 connected with a buffer 205 connected is. The buffer 205 can also be part of the processing unit 204 or the interface 203 be. The processing unit 204 continues to control an output unit 206 at. The output unit may be z. B. act a display unit or a display and / or at least one speaker.

For example, the sink 201 a speaker unit or a display unit (with or without speakers) include. The valley 201 can z. B. in the back of the front seats may be arranged as a so-called rear seat entertainment unit (RSE). In particular, the sink can 201 also input means (not in 2 shown) to communicate over the network with the source (see 1 ) to communicate. So z. B. the RSE select audio video data via a control unit or stop a movie, navigate through menus, etc.

The data packets are sent to the interface 203 received and received by the processing unit 204 decoded or optionally decompressed. If the presentation time contained in the data packets has not yet been reached, the decoded or decompressed data will be in the buffer 205 cached and essentially at the time of the presentation via the output unit 205 output or reproduced.

It is advantageous that the processing unit 204 the received data is processed or buffered on an application layer. The user data are thus already decoded and decompressed and can be output with almost no delay when the presentation time is reached. Thus, the audio / video data provided by the packets are e.g. B. as layer 7 user data (without package overhead) and not in the format of the incoming data packets (with the packet overhead of layers 1 to 6) stored.

Due to the above-described design of the network and the consideration of the maximum delay time td can be advantageously achieved that no complex layer-1 calculations for determining the individual delays in the participating in the communication network components are needed. Instead, the total delay of the network (and the components involved) can be designed to allow a small delay but synchronized output on all sinks of a data stream or for multiple related data streams (eg, sound and image data) , The actual delay in individual components of the network need not be determined separately and taken into account individually; it is also not necessary that the delays be monitored consuming by z. For example, delays from the sinks or from individual components of the network may be reported back to the source or captured centrally in the network.

Thus, the presented approach allows a synchronized reproduction of different information in a vehicle, taking into account existing maturities and processing times of the network or the network components involved.

Claims (12)

Method for processing data in a vehicle network, In which data is received via the vehicle network, the received data comprising data packets, each data packet containing a presentation time in the form of a time stamp; In which the received data is processed in the vehicle network by checking by an application layer whether a presentation time determined on the basis of the data has been reached, - both the processed data are output, if the presentation time is reached and - where the processed data is cached, if the presentation time has not yet been reached; wherein the application layer is provided by means of an application running on a sink or executable; and wherein the received data is decoded based on the application and / or decompressed and optionally output. The method of claim 1, wherein the vehicle network is a packet-oriented network. Method according to one of the preceding claims, in which the vehicle network comprises a wired network and / or a radio network. Method according to one of the preceding claims, in which the received data comprise data packets with audio information and / or video information. Method according to one of the preceding claims, in which the audio information is output via at least one loudspeaker and the video information is output via at least one display unit. Method according to one of the preceding claims, in which the processed data is buffered in a buffer. Method according to one of the preceding claims, wherein the size of the buffer memory is determined depending on a maximum expected delay. The method of any one of the preceding claims, wherein a plurality of components of the vehicle network are synchronized such that the output of the processed data is based on a common time base. Device having a processing unit, which is set up such that the method according to any one of the preceding claims is executable. Apparatus according to claim 9, wherein the apparatus comprises a speaker unit and / or a display unit for outputting the processed data. Device according to one of claims 9 or 10, wherein the device comprises a control device or part of a control device of a vehicle. Vehicle with a device according to one of claims 9 to 11.

Images