Space debris nowadays is widely recognized as a potentially severe problem for (future) space flight activities. Because of this, surveying orbit regimes via sensors connected to a processing system aimed at creating and maintaining a catalogue of all detected objects automatically is thoroughly researched (Space Surveillance and Tracking, SST). In this context Institute of Space Systems, Technische Universität Braunschweig, develops simulators for such processing systems, one approach being Datastream Management Systems (DSMS). Just like conventional database management systems DSMS cope with huge amounts of data and provide standardized and optimized means for data storing and retrieving. Unlike conventional database management systems DSMS don't store data tuples perminently, but instead continuously expect incoming data streams and provide outgoing data streams while providing standardized and optimized means for controlling data flow and processing. Sensor data streams may, for example, be branched to distribute computation load on different processors and/or machines, joined to collect data from different sensor sources, filtered to eliminate "bad" sensor data, aggregated to calculate minima/maxima values etc. Processing may be modified without recompiling and, in many DSMS, during run-time. Whenever new data tuples arrive, processing is kick-started (data-driven processing). Overall, DSMS have been explicitely developed with dynamic, adaptable, real-time processing of and reaction on high-rate continuous input of data in mind making them an ideal candidate for usage in SST systems.
This paper evaluates a DSMS in the context of a radar system simulator (RSS). For this purpose one basic functionality of a RSS is implemented and executed: Initial Orbit Determination, i. e. a first estimation of an object's orbit based on - in this case: simulated - measurements. It is described what steps have been taken to achieve development of a prototype and what challenges arose. Results of a general test case are presented and discussed. A benchmark test case follows where the prototype is put under stress by sensor data at a realistic rate.