Space is becoming a domain in which commercial and institutional players operate side by side. Launch costs are decreasing because of new launch concepts and the miniaturization of satellite hardware. In the US, an effort is made to establish space traffic management as an analogue to air traffic management under the control of Department of Commerce. The private sector grabs opportunities that open up. Its actors plan to put a vast amount of new satellites into orbit which work in tandem. Not only big players are on the field, but many new space companies put their feet into the door (“NewSpace”). All the while, digitalization is progressing, making place for new technologies and paradigms. One of the paradigms emerging is Software as a Service (SaaS) which aims to provide software as something that is connected to on demand. Instead of downloading and installing software on one’s own systems, software runs somewhere else and is used via network. Common implementations allow users to connect via web browser and/or allow the user’s systems to connect via Representational State Transfer (REST) Application Programming Interface (API). The latter allows an automation of the usage of provided software. This approach yields the possibility for space operators to integrate exactly what they need for their Space Surveillance and Tracking (SST, US pendant is Space-situational Awareness (SSA)) needs into their own ground-based software systems. An algorithm can be provided, but so can a core SST functionality like statistical orbit determination or even a whole catalogue maintenance system. Also, new sensors and catalogues keep coming online pushing the need to be able to cope with Big Data. Scalability and adjustability are key to provide NewSpace actors exactly what they need. This can be achieved by allowing external SST experts to easily adjust a scalable SST processing system which provides SST as a Service (SSTaaS).
This paper presents OKAPI:Orbits’ SSTaaS provision based on a Data Stream Management System (DSMS) architecture. DSMS allow the definition of the data flow within the system via a script language. They don’t save data permanently, but rather expect continuous data stream input and produce continuous data stream output. DSMS work in RAM only, are suitable for working with uncertain Big Data and are inherently modular. It is shown what SST experts can do with the architecture presented to tailor the service provision to user’s needs.