StreamCars: A new flexible architecture for driver assistance systems

Andre Bolles1, H.-Jurgen Appelrath1, Dennis Geesen2, Marco Grawunder2,Marco Hannibal3, Jonas Jacobi2, Frank Koster3, Daniela Nicklas2

1OFFIS - Institut fur Informatikfirstname.lastname@offis.de

2Universitat Oldenburg,firstname.lastname@uni-

oldenburg.de

3Deutsches Zentrum fur Luft- undRaumfahrt Braunschweigfirstname.lastname@dlr.de

Abstract— One of the main challenges in the developmentof traffic systems is to assure safety for all road users. Hence,especially expensive vehicles are equipped with advanced driverassistance systems (ADAS) that use data about the vehicleand information about objects in the proximity of the vehicleto execute the assistance function. These objects have to bedetected by sensors and they have to be tracked over multiplescans to keep the object’s state up-to-date. Usually, such ADASare developed as proprietary systems that are tailored forthe specific assistance function and the specific sensors inuse. Indeed, that leads to a very efficient system. However,changing system properties, e. g. an exchange of sensors, isvery expensive. In this case, very often at least some partsof the system code have to be reimplemented. To solve thisproblem of bad maintainability which arises especially duringthe development of new assistance functions in this work a newarchitecture for ADAS is presented. The relevant informationfor the assistance function is no longer provided by hard coded,predefined processes, but by flexible continuous operator plansin a datastream management system. These operator plansbuild up a dynamic context model of the vehicle’s environment.The context model is kept up-to-date by object trackingoperators in these operator plans and is then used as a datasource to extract information for different assistance functions.This extraction is also done by operator plans that produceonly relevant information and discard other information.

I. INTRODUCTION

Advanced driver assistance systems (ADAS) are developedto increase comfort and safety while going by car. In contrastto simple DAS new ADAS detect objects in the enviromentof the vehicle to react directly on specific traffic situations.E. g., an adaptive cruise control (ACC) slows down thevehicle in order to avoid a rear end collision. However, mostof these ADAS are very specialized systems that are tailoredfor specific sensors and the specific task they are used for.Although tailoring makes these systems working efficientlythe problem is that they have high maintenance costs. Espe-cially during the development phase of new ADAS whennot all requirements are clear and changes in the systemsoccur frequently this can lead to time-consuming changesof the system. In most cases even the system code mustbe partially reimplemented. To make ADAS more flexibleagainst changes such as changing the sensors or addingnew requirements of the assistance function in this work wepropose a new architecture for ADAS based on a datastreammanagement system (DSMS). The main idea of this approach

is to use operator plans similar to operator plans in databasemanagement systems to process sensor data and provideinformation for the assistance functions. Furthermore, thisarchitecture allows to integrate information for differentassistance functions into a single context model and thusshares processing of sensor data between applications.

In this paper, we first present related work in the fieldsADAS and DSMS and address the differences to our ap-proach in Section II. After that, we introduce our flexiblearchitecture for ADAS in Section III and show its benefits.Section IV presents the evaluation of our approach in a testvehicle and show its sufficiency for in-vehicle use. The papercloses with an overview about future work in Section V.

II. RELATED WORK

This work integrates two fields of research: advanced dri-ver assistance systems (ADAS) and data stream managementsystems (DSMS).

Most works about ADAS develop new systems that havespecial features and work with special sensors. E. g., in [1] anADAS is developed that is based on multiple laserscanners.The work in [2] goes one step further and develops anobject tracking system based on a laserscanner and a videocamera. In that system, the detection of objects is done onthe raw data of both sensors and the detected objects arefused afterwards. Similar to this work in [3] a video cameraand a radar sensor are used. Here, object tracking is doneon object data and not on the raw sensor data. However, thishigher level information is used to support object detectionon the raw sensor level for example restricting the area ina video frame in which to look for new objects. Besidesthese works that implicitly develop architectures for driverassistance system other works directly address the fieldof system architectures. For example, in [4] a dynamicand reconfigurable architecture for driver assistance systemsbased on FPGAs is developed. That work allows to selectone filter from a predefined set of filter algorithms whiledriving the car. However, increasing the flexibility of thearchitecture itself is not addressed in this paper. In contrast tothis, [5] develops a three-tier-architecture that distinguishesbetween raw sensor data processing, object data processing,and application data processing. This architecture differsfrom our approach, since it does not increase the flexibility of

2012 Intelligent Vehicles SymposiumAlcalá de Henares, Spain, June 3-7, 2012

978-1-4673-2118-1/$31.00 ©2012 IEEE 252

the data processing itself. As we present in the next section,we also use a multi-tier-architecture, but additionally delevopa new approach for data processing in ADAS.

DSMS are similar to database management systems(DBMS). In a DSMS queries are formulated. These aretranslated into so-called operator plans that read data fromthe sensors and process it to generate information that isuseful for applications like ADAS. The operators can becombined in a flexible way so that different information cangenerated from sensor data in a very simple way. Today,many DSMS-prototypes exist such as Aurora (Borealis) [6],[7], STREAM [8], TelegraphCQ [9], PIPES [10], and SPADE[11] to name just a few. Partially, they have been refinedto commercial products such as RTM Analyzer, which isbased on PIPES, or IBM Infosphere Streams, which isbased on SPADE. All these systems have in common thatthey use special approaches for data processing. In contrastto this, we developed a framework for tailor-made DSMScalled Odysseus (see [12], [13], [14]). Though all DSMS-prototypes provide a flexible way for (soft) real-time sensordata processing, no DSMS provides mechanisms for objecttracking. Therefore, in our work we enrich our frameworkOdysseus with object tracking capabilities and integrate itinto a flexible architecture for ADAS.

III. ARCHITECTURE

Flexibility of the system architecture is of crucial import-ance for the development of completely new ADAS. Assumethat you are using a completely new combination of differentsensors to sense the environment of a vehicle. The deve-lopment of a completely new ADAS is an iterative process.Thus, you make changes in your system design and integratethese into your implementation. Doing these changes withina proprietary system usually you have to reimplement orregenerate some parts of your code, recompile it, and installit in your vehicle to test it. This is very costly process.

Therefore, different from existing works we propose anew architecture for ADAS. This architecture allows a verysimple integration of new design aspects into an existingsystem. In our architecture, the information an ADAS needsfor executing its function is not processed in a hard codedsystem any more. Instead of that we use continuous operatorplans in a datastream management system (DSMS) to processsensor data and build up a context model of the vehicle’senvironment. This context model itself is the informationsource for serveral ADAS. To extract the information fromthe context model again continuous operator plans are used.E. g. if only information about objects ahead the ego-vehicle are needed, a special operator plan that extractsthese information can be installed into our architectureat runtime. For another ADAS another operator plan canbe used to extract different information. These operatorplans can share common parts. The architecture overviewis shown in Figure 1. As you can see here, we use amulti-tier-architecture similar to other works such as [5].The physical world is represented by the vehicle electroniclevel and the sensor level. On the sensor level the sensors

observe the vehicle’s environment and generate digital datatypical in fixed time intervals. On the vehicle electroniclevel, electronic control units (ECU) control the vehicle. Theremaining three core levels are the data processing levels.These levels are separated from the sensors and the vehicleby a middleware called DOMINION [15]. This middlewarehas been delevoped at the German Aerospace Centre (DLR)in Braunschweig. The main function of this middleware isto provide a generic interface to sensors and vehicles. Thisfunction allows the integrated development of new ADASusing virtual simulators, semi-virtual simulators, and testvehicles without changing the interface of the data processingunit of the ADAS.

Within these three core layers the raw sensor data levelis used for preprocessing the sensor data. On this level e. g.segmentation in point clouds or object detection in videoframes can be done to get information of higher value. Theextracted object information is then used on the object datalevel to build up a context model of the vehicle’s environmentfrom which specific information can be provided to differentADAS that map the information into control commandsof the vehicle. In the following we concentrate on theobject data level, since this level addresses our flexible dataprocessing for ADAS.

A. Object data processing by a DSMS

On the object data level we use a datastream managementsystem (DSMS) for data processing. Therefore, the mainconcept for flexibility of data processing is the use ofoperator plans. An operator in our architecture is similarto an operator of a query plan in a database – it is anatomic data processing unit. For example, an operator canfilter objects from sensors that fulfill some requirements, e. g.they do not exceed a specified threshold for their certainty.Multiple operators can be connected to operator plans tofulfill more complex tasks. For example, the first operatorof an operator plan could pass only detected objects withvery low uncertainty and the second one could map theseobjects from the sensor coordinate system to the globalcoordinate system of the vehicle. Usually there are only fewrestrictions to combine operators in a query plan. So you havehigh flexibility, since very complex tasks like object trackingfor specific sensor combinations or passing specific objectinformation to several ADAS can be solved by building upoperator plans containing multiple operators. Building suchplans can be done in a textual or graphical way.

In our architecture, we use operator plans for two tasks:to integrate the data coming from the different sensors in useto a context model, and to extract needed information fromthe context model and deliver this information to serveralADAS.

B. Building up a context model

The context model is the key information source in ourarchitecture. Each object in the vehicle’s environment andevery other relevant information is stored in this model.Although we know that special data structures are necessary

253

lane change

assistance

object tracking

adaptive

cruise control

DSMS

information extraction for ADAS

object

detections

context

model

object detections

DOMINION preprocessingpreprocessing ...

...

radar laser

sensors

raw data level

object data level

application level

vehicle electronic

...

operator

context model

data flow

middleware

timestamps

timestamp flow

e. g. parallel paths

Fig. 1. Stream management based architecture for ADAS

for efficient data processing, for simplicity assume that acontext model is a set of tuples containing information aboutobjects in the environment of a vehicle. This context modelis managed by a special operator that can also occur multipletimes for more robustness as we will show in our evaluation.

To bring this information into the context model, objectsaround the vehicle have to be tracked. However, objecttracking is a cyclic process shown in Figure 2 that we hadto integrate into our DSMS. Sensors periodically scan their

Ausgangssituation Schritt 1: Prädiktion

aus früheren

Messungen

bekanntes

Objekt

Schritt 2: Assoziation Schritt 3: Filterung

hohe Ähnlichkeit:

es könnte sich um

dasselbe Objekt

handeln

Schätzung der

tatsächlichen Position

Prädiktion auf

neuen Mess-

zeitpunkt

Objekte, die in einer

neuen Messung

erkannt wurden

start step 1: prediction

old object state

step 2: association step 3: filtering

strong similarity

estimation of true

position

prediction to new

point in time

new detected

objects

Fig. 2. Object tracking: a cyclic process

environment and detect objects. Usually the state of theseobjects, e. g. their position, changes continuously. Thus, totrack new detected objects, they have to be compared totheir state in the scan before. However, this old state hasto be made comparable by predicting it to the point in time,when the new object has been detected. The predicted stateand the new detected object are then compared by somesimilarity measures. Having a high similarity these objectsare assumed to represent the same real world entity. In thiscase they are associated. The remaining differences betweenthe predicted object and the new detected object are filteredby the correction step of algorithms like the Kalman-filter[16].

To integrate this process into a DSMS, we had twochoices. On the one hand we could build a new operatordoing all these three steps (like the complete Kalman-filtercontaining prediction and correction). On the other hand

we could develop an operator for each of these steps. Thefirst alternative would have had the advantage that we couldintegrate highly specialized object tracking methods into oneoperator. However, the problem with this approach is that foreach new specialized method, even if only one of the threesteps differs, we need a completely new operator. With thesecond alternative, we can simply exchange the operator forone of the steps by another one.

To enable such an exchange of operators, we separatesemantics and implementation of our operators. The imple-mentation is similar to the implementation of operators ina database management system. For example, there you canhave different join algorithms that produce the same resultin different ways. In the following we describe the semanticsof our operators that are shown in Figure 3.

object detections

of sensor 1

object detections

of sensor 2

association initialization

association evaluation

association selection

prediction

prediction assign

old objects timestamps

filter

Fig. 3. Association separated into three operators

Prediction The prediction step is separated into twooperators for more flexibility. The first operator is the so-called prediction assign operator (see [12]). This operatorassigns specified prediction functions to different objects.That is done by predicates that are evaluated against each

254

object. Predicates and prediction functions can be definedby a developer by simply typing the equations into the userinterface of our system (that is a simple text editor andwith a graphical representation of the operator plan and notshown here for space reasons). They will be automaticallyparsed. That provides high flexibility in the use of movementmodels. The second operator is the prediction operator itself.It is an operator with two inputs. The first input is for theobjects that are to be predicted and the second one is forthe points in time when new objects have been detected.This operator reads the old object states and the predictionfunction assigned to this state and calculates the predictedobject state at the point in time read in the second input ofthis operator.

Association According to [17] the association step isseparated into three operators (see Figure 3). The first as-sociation initialization operator merges the predicted objectsand the new detected objects of all sensors into one dataelement. This operator also initializes a so-called associationhypercube. This hypercube is a data structure, which isused to store the similarity values between the differentobject states. Assume that you have two synchronized sen-sors (scanning always at the same point in time1) and thepredicted object states from the context model. In this case,this association initialization operator will build up a three-dimensional cube. In each cell ci,j,k the next associationevaluation operator will put the similarity between the i-thobject of the context model, the j-th object of the first sensorand the k-th object of the second sensor. This operator canbe configured with arbitrary similarity measures like theMahalanobis distance [18] or more complex metrics likeshown in [3]. Again, this configuration can be done by simplyinserting the equations of the metrics into the user interface.They will be automatically parsed. Furthermore, it is possibleto build an operator chain of association evaluation operators,in which each operator is configured with different similaritymeasurements. This increases flexibility in finding combi-nations of similar objects. The third association operatoris the so-called association selection operator. Since thereis a similarity between each of the serveral objects, thisoperator selects the object combinations that are most similar.It can be configured by a selection strategy. Usually theobject pairs with the highest similarity will be selected first,but ambiguities have to be solved in a deterministic way.Solving ambiguites is application dependent. The associationselection operator has one more outputs than inputs. Foreach of the inputs this operator has an output that containsthe objects, for which there was no association partner.The additional output is for the sucessfully matched objectcombinations.

Filtering The last step of the object tracking process isthe filtering step. This step is mapped to one operator thatcan be configured by filter equations like the equations forthe Kalman-Filter or its derivates. This configuration is also

1With unsynchronized sensors each sensor is handled separately but inglobal order of the timestamps of the sensor scans of each sensor.

supported with automtic parsing. This operator smoothes thedifferences between the object combinations. The output ofthis operator is used to update the context model, so that thenext measurements can be processed.

C. Using the context model as information source

As mentioned earlier, after the context model is built upit will be used as information source for different ADAS.As you can see in Figure 1 you can install operator plansinto the system that read data from the context model –also in a push-based way. Each time the objects in thecontext model are updated by the object tracking processthey are passed to the installed operator plans. These operatorplans can represent simple database-like queries. So youcan simply do a selection on the objects in the contextmodel. But it can also represent more complex queries likecomplex event processing queries, SPARQL-like queries orqueries containing user defined operators. The output of theseoperator plans contain exactly the information that is neededby the specific ADAS the operator plan is installed for.For example, an adaptive cruise control (ACC) will onlyget objects that are ahead of the ego-vehicle. A blind spotassistant will only get information about objects that arebesides the ego-vehicle and so on.

D. Advantages of DSMS-based object tracking

The main advantage of our architecture is the very highflexibility, while still being able to process data fast enoughas we will show later. The flexibilty comes from the operatorplans used to process incoming data. Due to the fact thatoperators in a query plan can be combined in an arbitraryway, the developer of a new ADAS is able to configurea query plan that fits his needs best. In the following wewill summarize the most important points of variation in ourarchitecture.

Arbitrary prediction models Due to the fact that theprediction step is mapped to two different operators it ispossible to choose different prediction models without reim-plementing the system. The prediction models can directlybe typed into the user interface and they are parsed whenthe operator plan is installed in the system.

Arbitrary association models The association step hasbeen mapped to three operators. They can be parameterizedwith different association metrics. Similar to the predictionmodels if these metrics can be expressed by equations, theycan be typed directly into the user interface and they willbe parsed automatically when the operator plan is installedin the system. Another possibility is to implement a set ofcomplex association metrics and by this build up a libraryof association metrics from which the user can choose whenhe installs a new operator in our architecture.

Arbitrary filter models The filtering step behavessimilar to the association step. If filter methods can beexpressed by equations, they can be typed directly into thesystem and will be parsed automatically. However, again itis possible to directly implement different filter models andget a library of filter models from which the user can choose.

255

Arbitrary operator plans The most important advan-tage is the combination of operators to different plans. Forexample, as you can see in Figure 1 there is an operator planthat splits the object tracking process into two parallel pathsfor redundancy and that uses one context model. However,sometimes it is necessary to use more than one contextmodel. For example, as done in [3] to be more robust againstghost objects (objects that do not really exist, but havebeen detected due to sensor artefacts), it can be useful totemporally store objects and pass them only, if they havebeen detected multiple times subsequently. The operator planshown in Figure 4 is used for our evaluation and is anexample for this multiple context model processing.

The second adavantage of arbitrary operator plans is thatyou can select information from the context model in a waysimilar to querying data from a database. So, you can selectdifferent information for different assistance functions byinstalling corresponding operator plans into the system.

All these operator plans can be installed in the system atruntime. So the vehicle has not to be stopped for testing newconfigurations.

IV. EVALUATION

The flexibility of our approach has been explained inthe former sections. However, our framework has not onlyto be flexible, but also fast enough to process all relevantsensor data. To demonstrate this we developed an operatorplan that processes objects detected by a laserscanner andprovides information for an adaptive cruise control (ACC).The operator plan for this scenario is shown in Figure 4.As you can see here, two context models are used in thisoperator plan to increase robustness against false detections.The primary context model contains the information thatis passed to the ACC. The secondary context model isused to increase evidence for new detected objects. Eachincoming object is passed to the primary object trackingcycle first. If in this cycle an object cannot be associatedto an object from the primary context model, it is passedto the secondary object tracking cycle, since it has not beendetected before and therefore might be a false positive. If inthe secondary cycle the object has been detected before orhas a high probability of being correct, it is directly passedto the primary context model. Otherwise its certainty mustbe increased by further sensor scans or it will be deleted.Objects in the primary cycle that could be associated toobjects from the primary context model using Mahalanobisdistance are passed through the correction step of a Kalmanfilter that updates the object’s state in the primary contextmodel. Each time the primary context model is updatedthe vehicles that are in front of the ego-vehicle with lowdistance2, are passed to the ACC. The ACC then slows downthe ego-vehicle or even stops, if necessary.

This operator plan has been tested twice using a 2.2GHz Dual-Core CPU with 4 GB RAM. The first run was

2The threshold can be typed into the user interface and is automaticallyparsed. In this test we used 25 meters.

interface to sensors

A initialization

A evaluation

A evaluation

A selection

F filtering

P assignment

P prediction

P assignment

P prediction

A initialization

A evaluation

A evaluation

A selection

F filtering

Interface to ADAS

selection

secondary

context model

primary

context model

secondary object tracking cycle primary object tracking cycle

Fig. 4. Query plan for evaluation

simulation-based to test different sensor rates. In this runa driving simulator generated five to fifty object detectionsper scan at different sensor rates. Figure 5 shows responsetimes at the different scans. Response time means the latencyfrom the point in time when a new sensor measurementcomes into the system until the point in time when updatedinformation is passed to the ACC. As you can see in Figure

1

10

100

1.000

10.000

100.000

10

11

12

14

16

20

25

33

40

50

52

55

58

62

66

71

83

100

200

1000

late

ncy

in m

s

sensor frequency (Hz)

Fig. 5. Determining the maximal frequency of our framework

5 our framework has a response time of approximately 12ms at sensor rates up to 55 Hz. After that the response timegrows exponentially, which means that the data cannot beprocessed fast enough anymore. 55 Hz are sufficient, sincemany sensors for ADAS work at lower rates3. Also rememberthat we did not implement any algorithmic optimizationsand that our architecture will be used in the development

3e. g. ibeo LUX laserscanner, http://www.ibeo-as.com, last visited:2011/11/21

256

phase of new ADAS. After a sufficient operator plan hasbeen found, similar to [11] C-code could be generated fromthe corresponding operator plan that works efficiently onelectronic control units.

The proof of concept of our framework has been donein a test vehicle provided by the German Aerospace Centre(DLR) in Braunschweig. This test vehicle called FAS-Car isequipped with three laserscanners of type ibeo LUX runningat 25 Hz. Figure 6 shows the cockpit view of the testdrive. As you can see on the notebook display the personsin front of the vehicle have been detected correctly. Thevehicle stopped timely (unfortunately not presentable in thisfigure) . This test shows that our framework is also sufficientfor the use in a vehicle even without implementing anyoptimizations for our algorithms.

Fig. 6. Cockpit view in the test vehicle

V. FUTURE WORK

The presented architecture for ADAS is still a prototype.The following things will be addressed in future work.

First, we have to extend our operator library since indifferent ADAS we need optimized methods for objecttracking and data processing. At the moment very simplemethods like the Mahalanobis distance or a simple Kalman-filter correction step have been implemented for a proof ofconcept. If the library of operators will be extended, devel-opers using our architecture can choose from different objecttracking and data processing methods that are sufficient fortheir use case. It will be even possible to switch betweendifferent methods on the fly while driving a car.

Second, real-time capabilities of our approach must beinvestigated. This can be reached by transforming operatorplans into C-code that can be directly installed in differentelectronic control units of a car (s. [11]). In this case forexample the dynamic parsing of mathematical equations willnot be necessary any more.

Conformity of our approach to widely used standards likeAUTOSAR and ISO 26262 has not been considered yet. Thismust still be done to use our approach in series production.For example, interfaces to other software modules must beadapted for AUTOSAR. Additionally, for ISO 26262 ourapproach must give guarantees for automotive integrity levels

(ASIL) and it must be integrated into a development processfor safe software implementation in the automotive domain.

Our next step is to use our approach for autonomoustransport vehicles developed in the research project SaLsA(granted by German Federal Ministry of Economics andTechnology (BMWi), no. 01MA09037).

REFERENCES

[1] M. R. Ghahroudi and A. Fasih, “A hybrid method in driver andmultisensor data fusion, using a fuzzy logic supervisor for vehicleintelligence,” in Proceedings of the Int. Conf. on Sensor Technologiesand Applications 2007. IEEE Computer Society, 2007, pp. 393–398.

[2] Alvaro Catala-Prat, R. Reulke, and F. Koster, “Early detection ofhazards in driving situations through multi-sensor fusion,” in FISITA2008 Automotive World Congress, 2008.

[3] M. Munz, M. Mahlisch, and K. Dietmayer, “A sensor independentprobabilistic fusion system for driver assistance systems,” in Pro-ceedings of the 12th International IEEE Conference on IntelligentTransportation Systems, 2009.

[4] N. Harb, S. Niar, M. Saghir, Y. Hillali, and R. Atitallah, “Dynamicallyreconfigurable architecture for a driver assistant system,” in Applica-tion Specific Processors (SASP), 2011 IEEE 9th Symposium on, june2011, pp. 62 –65.

[5] M. Darms and H. Winner, “A modular system architecture for sensordata processing of adas applications,” in IEEE Intelligent VehiclesSymposium, 2005, pp. 729 – 734.

[6] D. J. Abadi, Y. Ahmad, M. Balazinska, U. Cetintemel, M. Cherniack,J.-H. Hwang, W. Lindner, A. S. Maskey, A. Rasin, E. Ryvkina,N. Tatbul, Y. Xing, and S. Zdonik, “The Design of the Borealis StreamProcessing Engine,” in CIDR 2005. VLDB Foundation, 2005.

[7] D. J. Abadi, D. Carney, U. Cetintemel, M. Cherniack, C. Convey,S. Lee, M. Stonebraker, N. Tatbul, and S. Zdonik, “Aurora: A NewModel and Architecture for Data Stream Management,” The VLDBJournal, vol. 12, no. 2, pp. 120–139, 2003.

[8] A. Arasu, B. Babcock, S. Babu, M. Datar, K. Ito, R. Motwani,I. Nishizawa, U. Srivastava, D. Thomas, R. Varma, and J. Widom,“STREAM: The Standford Stream Data Manager,” IEEE Data Engi-neering Bulletin, vol. 26, no. 1, pp. 19–26, 2003.

[9] S. Chandrasekaran, O. Cooper, A. Deshpande, M. J. Franklin, J. M.Hellerstein, W. Hong, S. Krishnamurthy, S. Madden, V. Raman,F. Reiss, and M. Shah, “TelegraphCQ: Continuous Dataflow Proces-sing for an Uncertain World,” in CIDR 2003. VLDB Foundation,2003.

[10] J. Kramer and B. Seeger, “Semantics and implementation of conti-nuous sliding window queries over data streams,” ACM Transactionson Database Systems, vol. 34, no. 1, pp. 1–49, 2009.

[11] B. Gedik, H. Andrade, K.-L. Wu, P. S. Yu, and M. Doo, “Spade: Thesystem s declarative stream processing engine,” in SIGMOD 2008.ACM, 2008, pp. 1123–1134.

[12] A. Bolles, M. Grawunder, J. Jacobi, D. Nicklas, and H. Appelrath,“Prediction functions in bi-temporal datastreams,” in DEXA 2010, ser.Lecture Notes in Computer Science, P. Bringas, A. Hameurlain, andG. Quirchmayr, Eds. Springer Berlin / Heidelberg, 2010, vol. 6261,pp. 261–268.

[13] J. Jacobi, A. Bolles, M. Grawunder, D. Nicklas, and H.-J. Appelrath,“A physical operator algebra for prioritized elements in data streams,”Computer Science - Research and Development, vol. 25, no. 3-4, pp.235 – 246, 2009.

[14] A. Bolles, “A flexible framework for multi-sensor data fusion,” inProceedings of the joint EDBT/ICDT Ph. D. workshop, 2009.

[15] J. Gacnik, O. Hager, M. Hannibal, and F. Koster, “Service-orientedarchitecture for future driver assistance systems,” in FISITA 2008Automotive World Congress, 2008.

[16] R. E. Kalman, “A new approach to linear filtering and predictionproblems,” Transactions of the ASME–Journal of Basic Engineering,vol. 82, no. Series D, pp. 35–45, 1960.

[17] D. L. Hall and S. A. H. McMullen, Mathematical Techniques inMultisensor Data Fusion. Artech House, 2004.

[18] P. C. Mahalanobis, “On the generalized distance in statistics,” inProceedings of the National Institute of Science, vol. 2, no. 1, 1936,pp. 49–55.

257