Abstract

The development, deployment, and maintenance of the current space situational awareness (SSA) information system have become increasingly complex. However, researchers cannot flexibly and conveniently apply the research results to practical applications due to the lack of basic research platforms for SSA. Inspired by X as a Service (XaaS), we propose the microservice-based platform for SSA data analytics to provide a scaffold-like platform for researchers. Based on microservice, the architecture for this platform is proposed to meet the requirements of flexible development and loosely coupled deployment. To facilitate the use of the platform, the hybrid data service layer is established to provide basic data for research and the functional service layer is designed to provide services for clients and applications. Due to the massive data processing requirements, the data analysis architecture and processing model, which can easily integrate various user-defined algorithms and significantly improve the computational efficiency, are proposed based on the Lambda architecture. To verify the platform’s effectiveness, two cases are established and implemented. The results show that this platform can provide a convenient, flexible, and efficient platform for the requirements of algorithm integration, experiment, and data display from users and researchers.

1. Introduction

The importance of the space environment around the earth has increased. More than 80 countries and organizations have payloads in space [1]. Countries, organizations, and individuals worldwide increasingly depend on space with respect to positioning, navigation, communication, etc. Aerospace powers are vigorously developing space situational awareness (SSA) capabilities to maintain security and dominant position and to detect any changes or threats in space. The SSA represents the current and predictive knowledge of space events, activities, conditions, and space application status capabilities and constraints [2], which has been used for satellite tracking, communication management, orbit operation and maintenance, and threat assessment [3]. It is concerned with various space objects such as satellites, debris, and rockets. Various countries have developed and deployed a series of SSA-related systems for the acquisition, analysis, mining, and application of SSA information and data [4], which are often referred to as the SSA information system (SSAIS). These systems have made tremendous contributions to SSA, although many challenges still remain as time and technology advances.

As countries around the world launch more spacecraft, there is growing complexity and diversity of SSA-related information and data, which have made development, deployment, and maintenance of the SSAIS more complex. Initially, SSAISs were implemented based on the monolithic architecture with tightly coupled components. The addition or modification of internal functions required consideration of their compatibility with others, which resulted in larger maintenance and development costs, longer continuous delivery cycles, and worse expansion [4, 5]. Due to the underutilization of distributed computing and network-based service architecture [6], these systems could not be effectively deployed on the cloud [7]. To address these challenges, cloud computing, big data, and service-oriented architecture (SOA) are applied to the SSAIS [5] and the SSAISs are deployed on the cloud based on various technologies such as virtualization [4]. The European Space Agency (ESA) has established the SSA preparatory system based on SOA [8], and the Defense Advanced Research Projects Agency (DARPA) has established the OrbitOutlook project by using SOA to integrate datasets from multiple countries, organizations, and enterprises [9, 10]. To obtain an efficient and flexible SSAIS by 2020 [11], the United States is building the Joint Space Operations Center Mission System (JMS), a worldwide state-of-the-art SSAIS, based on cloud computing and SOA [12]. Almost all these systems use SOA to transform the monolithic architecture and realize a distributed deployment. However, SOA requires more manpower, material, and financial resources, and the system developed based on SOA is difficult to maintain and develop. In the era of cloud computing and big data, user requests for services are variable and resilient [13, 14]. Therefore, services need to be easily maintained and to have continuous delivery capabilities [15]. However, such properties cannot be met by the monolithic architecture and SOA.

The relationship between space and the public is growing closer. Nevertheless, there is still inconvenient and insufficient access to SSA information and knowledge. The concept of SSA has been applied by the military to space activities, and the existing SSAISs are mainly dedicated to the military and national security. However, space activities (e.g., navigation, communication, and weather) are closely related to civil life, and the public has begun to pay attention to SSA [16]. The shortage of channels for obtaining SSA information leads to the lack of access and opportunities for the public to understand outer space [3]; even a vast majority of satellite operators cannot accurately obtain information about the space environment surrounding their satellites [17]. Based on these issues, new ideas and services have emerged. Concepts of building a civil space traffic management system [18] and a publicly available global SSA information service based on open data sources have been proposed [17]. In addition to these concepts, several website portals providing services have been established. Space-Track [19] and Heavens-Above [20] are some of the portals that provide such datasets as satellite ephemeris data and SSA-related information, such as data analysis and visualization of the satellites position; however, the data distribution needs to be authorized, which limits the application of the datasets [21]. CelesTrak [22] and Gunter’s Space Page [23] provide sufficient datasets without authorization restrictions and visualization [21]. SpaceBook [24] and N2YO [25] provide visualization schemes and application programming interfaces (APIs) to access object satellite ephemeris data and properties but do not provide analysis services. These projects are in part capable of providing SSA information to the public, but they do not provide comprehensive services for the public to improve SSA cognition, particularly the capabilities of helping the research institutions with academic studies and engineering applications.

In response to the above-mentioned problems and adhering to the idea of X as a Service (XaaS), we propose a microservice-based platform for SSA data analytics to promote the sharing of SSA information and provide convenient and efficient services to researchers who need to build and deploy the related algorithms and applications. The main contributions of this paper can be summarized as follows: (1)Based on microservice architecture (MSA), a platform for SSA data analytics is established and the basic SSA services are constructed, including space object service, data statistic service, database management service, and batch and stream computing services. These basic services will provide support for the building of various user services(2)The platform proposed builds regularly updated databases based on different data sources, including the various relevant catalog object information, which can provide basic data support for various services in the platform(3)Aiming at the different computing requirements from spatiotemporal analysis services, the data analysis model combining batch processing and stream processing is designed based on the Lambda architecture. User-defined algorithms can be applied in this model to process SSA data, and the analysis results will be stored in the databases or the cache service for different requirements(4)As a scaffold-like platform, two cases of SSA analysis service are constructed and the applicability of the platform is tested, which prove that the platform can well adapt to various algorithms, and the final analysis results can be flexibly presented in different visualization schemes

The remainder of this paper is organized as follows. For the construction of this platform, several state-of-the-art technologies related to our work are introduced in Section 2. Section 3 elaborates the platform architecture based on MSA. In the platform, the data service layer and functional service layer which play important roles in the platform are discussed in detail. For the data service layer, the back-end data model is designed and constructed; for the functional service layer, the dependency and deployment approaches are designed and described. In order to meet the massive computation and analysis requirements of SSA effectively, the general data analysis architecture based on the Lambda architecture and the data processing model are designed in Section 4, and two case analyses are illustrated in Section 5 to test and verify the platform. The conclusions and outlines of our future work for the platform are drawn in Section 6.

The state-of-the-art IT concepts and technologies needed to implement the platform are described in this section.

2.1. Microservice Architecture and Container Technology

As a new architectural style that emerged in recent years, there has been rising interest on MSA [26]. MSA can split a complex software system into single-function and small-grained services [2729]. Each service can be independently developed, tested, and deployed. The services use a lightweight communication mechanism to exchange data [30]. MSA allows the team to build services by using appropriate program languages and tools according to the business context, which has advantage over the monolithic architecture [31].

Although MSA and SOA exhibit some commonalities with respect to the definition and design, they also significantly differ, as shown in Table 1 [32]. One significant difference is that the enterprise service bus (ESB) in SOA requires complex configurations, which leads to a higher latency and single failure point [7, 33]. In contrast, the highly cohesive and low-coupling MSA does not emphasize the ESB, which leads to more flexibility, enforceability, and scalability [34, 35]. Another key difference is that most services in SOA are derived from monolithic architecture applications and functions, which cannot be changed, scaled, or deployed independently [31].

The MSA deployment method is shown in Figure 1. The request from the external terminal is forwarded to different microservices through the service gateway, and the results of different microservices are received and transmitted to the terminal. Each microservice meets highly concurrent computing requirements by building multiple instances. Load balancing can be used to reasonably allocate requests to make a high response speed and the overall performance certain. Different microservices can be developed using different programming languages (e.g., C++, Java, and Python) and be able to access data services as needed. This architecture and its deployment approach meet the flexible needs of users.

Because of the advantages of container technology over traditional virtualization technologies, container technology has been widely applied to software development and deployment on the cloud [36, 37]. When using traditional virtualization technologies, every service must be applied with all dependencies and a complete isolation operation system (OS) in terms of having its own process and network, which leads to the waste of the resource, space, and hardware performance. The container technology differs from traditional virtualization technologies in that services can be built in a shared host OS that only includes the applications and dependencies. Only the necessary processes need to run when services start, which means that the containers consume only the resources required for the services [38, 39]. Once a container is built, it can be deployed and run without need for modification on any host OS. These advantages make the container technology very suitable for the deployment of microservice-based applications and allow researchers to put most of their time and effort into the innovation of algorithms and applications.

2.2. Batch and Stream Computing Platforms

Many excellent platforms and frameworks, such as Apache Hadoop [40], Apache Spark [41], Apache Storm [42], and Apache Flink [43], are available for the computation of big data. Each framework is applied in all walks of life for different needs. Apache Hadoop has been used in various big data processing fields but cannot meet the real-time computing tasks and requirements [44, 45]. Apache Storm only supports stream processing [46], Apache Spark simulates stream processing based on batch processing [47], and Apache Flink is entirely based on stream processing and simulates batch processing through stream processing [48]. Apache Flink can implement both stream processing and batch processing via a single solution, which can help prevent duplication of codes during development. The characteristics and excellent performance of Apache Flink can better meet the needs of researchers [49, 50].

2.3. SQL and NoSQL Database

Nowadays, a variety of online service applications need the appropriate databases to meet the requirements from hundreds of users at any time [51]. Simultaneously, the advances of technologies generate a huge volume of different kinds of data, which can be divided into structured data, semistructured data, and unstructured data. Relational database management system (RDBMS), or structured query language (SQL) databases, can store structured data well, but it has great limitations with massive unstructured data (e.g., images and files). Therefore, not only SQL (NoSQL) databases, which are suited for storing semistructured and unstructured data, are proposed and have achieved widespread and successful applications in the internet domain [52].

According to the storage mode, NoSQL databases can be divided into a document database (e.g., mongoDB), column-oriented database (e.g., HBase), key-value database (e.g. redis), etc. [53]. In terms of unstructured data, NoSQL databases have a huge advantage over RDBMS [51, 54]. The NoSQL databases are well equipped to cope with the need of horizontal expansion and are mainly used in systems with intensive reading and writing requirements and systems with uncertain data structure. However, RDBMS occupies a dominant position in the systems with high requirements for data consistency and vertical scalability. For these reasons, in order to build a storage system for various data structures, the current mainstream solution is to use the RDBMS and NoSQL database side by side, which is called the hybrid SQL/NoSQL database [5557].

2.4. 3D Visualization Platform

The Digital Earth system can effectively fuse data from different sources in a network environment [58], which has become the standard method for analyzing and displaying spatial information on different spatiotemporal scales [59]. Based on the comparison of different digital earth platforms [60], Cesium is an appropriate solution for the visualization of SSA information and scenarios.

Cesium [61] is an open-source JavaScript library for world-class three-dimensional (3D) globes and maps based on WebGL and has become the leading 3D WebGIS platform [62, 63]. Cesium is capable of merging image layers from different data sources, loading various industrial-grade 3D model formats (e.g., KML, glTF, GeoJSON, and TopoJSON), and supporting open geospatial consortium (OGC) standards. More importantly, CZML [64], a markup language for Cesium, has been designed and developed.

CZML is a JavaScript object notation (JSON) format for the description of a time-dynamic graphical scene. It is an effective means for the network-based, real-time, data-driven analysis of dynamic objects in a 3D digital earth [62, 63]. In addition to various default properties, CZML also supports custom properties. CZML can meet all kinds of data processing needs; especially for stream computation, CZML is ideally suited for incremental streaming to Cesium for the visualization because of its unique ability to stream massive datasets and the storage of property information of different objects in multiple packets. A CZML packet is a collection of name-value pairs, which describe the geometrical, graphical, semantic, and temporal aspects of a single geospatial object [62]. The data volume in a packet depends on the needs; therefore, CZML guarantees the timeliness of each computation and transmission by controlling the data volume. Figure 2 shows the CZML data format for the scenario of the satellite coverage analysis, which includes ground area, satellite, and sensor packets.

3. Platform Framework

3.1. Platform Architecture

The architecture of the platform based on MSA is shown in Figure 3. The client (e.g., desktop, browser, and mobile) requests services through the APIs in representational state transfer (RESTful) architectural style [65]. The clients can use a series of display methods such as the three-dimensional (3D) visualization, for processing the results. The service gateway provides a unified RESTful API access interface, and all requests from the clients need to go through the service gateway, which avoids the exposure of internal APIs between microservices. Users do not need concern for the interaction between internal services, and the cases of service upgrading, modification, and expansion will not affect user experiences. Load balancing is responsible for assigning requests, preventing excessive pressure on background services, and improving the response speed and overall performance. When services add new instances, load balancing can reasonably allocate requests to the newly added instances. All microservices are registered in the service registry, and each microservice finds the others through the service registry. Service configuration stores the attribute configurations of all microservices.

In addition to the above components, the two most important parts of the platform are the functional service layer and data service layer. The functional service layer provides basic services that are currently available on the platform and user services; the data service layer provides the databases and cache service. The expatiation of both layers will be provided separately in Sections 3.2 and 3.3.

The efficient operation of the platform requires a good deployment strategy. As a representative enterprise container platform for high-velocity innovation, Docker [66] can build, host, and run distributed microservices ideally. It has an advantage over traditional virtualization deployment particularly with respect to data computation-intensive applications [67]. Figure 4 shows how the functional services are deployed in the application server based on Docker. Each application server includes many containers, and each container runs a separate functional service. In each application server, the microservice in different containers exchanges messages and combines functions through a lightweight communication mechanism. Load balancing can distribute requests between different application servers to avoid excessive pressures on one of the servers. All services that need to request data can access the database in the data service layer directly or indirectly.

Generally, container technology is well suited for the distribution and deployment of application services, but the situation becomes different and complicated when databases are deployed using the container technology. Regarding the persistent data in the production database, deploying data by using the container technology can easily cause loss of data when the container fails. However, when using redis to provide the cache service, there will be no problem in deploying the cache service in the container because cache data is only stored temporarily. Based on the above analyses, in terms of the deployment of the data service layer in Figure 3, databases use the stand-alone data server for deployment instead of containers, while the cache service is deployed using the container technology.

3.2. Data Service Layer

The core of the SSAIS is the database of trackable objects and relevant information [68], which needs to be continuously updated and maintained, and the space catalog object database needs to be constructed for object retrieval and data analyses, such as conjunction assessment [69]. Based on the architecture in Figure 3, the platform needs the data service layer to provide effective services for users and operators. This section will describe the construction of the data service layer in detail.

3.2.1. Acquisition of Data Sources

Current space object data of the platform include the basic information, attribute parameters, ephemeris data, photometric characteristic data, object images, and other related data, which can be obtained by integrating multiple data sources. Open datasets, which are most relevant and significant for integration, are as follows: (i)CelesTrak [70]: a website providing datasets that include current and historical orbital data, detailed interpretation of satellite ephemeris data, satellite orbital conjunction reports, and assessments of threatening encounters in space. It also provides an online query for satellite ephemeris data and a data download function for the data in the form of text documents based on different needs (e.g., launches of the last 30 days, 100 (or so) brightest).(ii)The Union of Concerned Scientists (UCS) satellite database [71]: a public dataset including important information about current on-orbit satellites, such as the name, country, purpose, orbit type, orbital parameter, launch weight, and dry weight, to assist both professional and nonprofessional users in conducting research and analysis. This database is updated every few months and is less time-efficient, but it can complement other databases due to the inclusion of valid significant information about many space objects. The latest data used in this paper was updated on November 30, 2018(iii)Planet4589 [72]: a website maintained by Jonathan McDowell from the Harvard-Smithsonian Center for Astrophysics. It provides and updates satellite launch details, satellite lists, and geosynchronous satellite lists every couple of months

In addition to the above data sources, we obtained images, models, and characteristic data (e.g., photometric characteristic data) of the space objects through the Internet and relevant software (e.g., systems tool kit (STK) [73]), which are also used as the data sources for the platform.

3.2.2. Data Model

According to the platform architecture and the core design ideology of hybrid SQL/NoSQL databases, we use the storage mode in the platform as follows: the RDBMS (MySQL) is used to store structured data, mongoDB is used to store unstructured and semistructured data, and redis is used to store cached data. The schematic database diagram of this platform is shown in Figure 5.

When using the RDBMS to store the structured data, the most important table is the satellite_list table. The data of the table satellite_list that are derived from CelesTrak include all orbital and decayed space objects (e.g., payloads, debris, and rockets) and relevant information such as the launch site code, owner, purpose, and operation parameters. The most pivotal field is the North American Aerospace Defense Command (NORAD) catalog number, which is a sequential 5-digit number assigned to all earth-orbiting objects in the order of identification. The other tables of the structured data are as follows: (i)The table launch_site_list includes the full name, geographic coordinates, and other information pertaining to worldwide launch sites. It is associated with each space object in the table satellite_list via the launch site code(ii)The table purpose_list includes codes and detailed descriptions of the satellite purpose. It is associated with the table satellite_list via the purpose code(iii)The table owner_list includes countries, regions, and organizations that had and have space objects. This table is associated with the table satellite_list via the country code(iv)The table orbital_decayed_boxscore includes the orbital and decayed counts of payloads, debris, and rockets of each country or organization and is associated with the table owner_list via the country code(v)The table ucs_satellite_list includes the datasets from the UCS Satellite Database and is associated with the table satellite_list via the NORAD number

In this platform, based on the excellent performance of mongoDB in storing unstructured data, the unstructured data of SSA are stored with mongoDB, and two examples (photometric characteristic data and position data) are presented in Figure 5. In the characteristic data of space objects, the photometric characteristic data includes imaging parameters, photometric values, and optical images. mongoDB is ideal for storing these kinds of data. For the position data of space objects within a time period, the position and time are always on a one-to-one correspondence. As shown in Figure 5, the calculation parameters and position data can be combined into data in the JSON format. mongoDB stores data in the BSON (Binary JSON) format, which means that mongoDB is well suited for storing this data.

The SSA-related information analyses have various intermediate data that will be used by different components in the execution process and analysis results of batch and stream processing that will be used by the clients, which means the cache service is indispensable. The cache service stores the cached data (e.g., analysis results and temporary data generated in data processes) temporarily within a certain period of time to improve the data access speed and reduce the request pressure on the database service. When the results requested can be obtained through the cache service, the databases will no longer be accessed; otherwise, the data will be queried and processed from the databases and be stored or updated by the cache service simultaneously. As a high-performance cache database, redis can effectively store these intermediate and result data and ensure that users and various components can access these data efficiently.

3.3. Functional Service Layer

MSA allows platforms and systems to perform complex functions through the orchestration of different microservices. Simultaneously, the existing microservices can be well integrated with other services. More importantly, MSA can solve the integration problems of heterogeneous services, so different services can be developed by using the most appropriate program language. By packaging different data analysis services, a unified interface can be provided externally by the service gateway, which can be accessed by different clients. Therefore, when building the functional service, the platform proposed in this article can split different functions and combine them to complete more complex tasks.

The functional service in the platform includes basic services and user services. The basic services can provide functions and interfaces for user services; hence, they are the cornerstone and can reduce the difficulty of construction of user services. User services mainly concern various functions of SSA analysis, such as satellite coverage analysis and conjunction assessment. As a scaffold-like platform, this platform cannot provide full analytical functions. Therefore, only the basic services are covered in detail here, and the user services are illustrated using two cases in Section 5.

In MSA, each service is split according to the specific functions and the data exchange between them by using a lightweight communication mechanism. The basic services are necessary for the platform, and the current basic services of the platform and their dependencies on each other are shown in Figure 6. The detailed descriptions of each basic service are as follows: (1)The data management service manages all the data in the data service layer. This service can periodically obtain and integrate data from different sources and store them in suitable databases. It can also update the back-end databases according to the data submitted by users. This service will trigger certain functions to perform tasks when the data in databases is updated. For example, when the ephemeris data of space objects is updated, the position calculation of space objects based on the batch computing service will be called to calculate the position of updated objects at a fixed interval in a certain period of time. The results will be stored in the persistent database, and the other position-related services can avoid or reduce the position calculation by using these results. This service is mainly called by the external data management user service, which requires the administrator authorization to log in(2)The data retrieval service constructs access to all the data in the data service layer. It can retrieve, organize, and return data based on the user’s needs and requests from other related services. This service provides an easy-to-understand access interface to avoid complex data query statements, which is one of the most basic services in the platform(3)The position calculation service provides the position computation in various reference coordinate systems (e.g., J2000 coordinate system, True Equator and Mean Equinox (TEME) coordinate system) for the platform. The spatiotemporal characteristics of SSA objects make the position data into the basis of the data analysis of SSA objects. This service can be called by other services to compute position, and it accesses satellite ephemeris data through the data retrieval service(4)The data statistic service mainly analyzes the data of the entire back-end database and returns the results. The content of the data statistic includes the count of orbital objects (payloads, rockets, and debris), the distribution of orbital satellites according to various conditions (e.g., country, altitude, and application), the number of satellites launched in different years, and the different launch sites. All these statistics provide users with an intuitive understanding of the current space objects and the changes and trends of the data from the past to the present. User services can use this data to build visual charts(5)The SSA data includes the structured data (e.g., basic information and two-line element (TLE)) and unstructured data (e.g., images, text, and media). Therefore, the space object service needs to retrieve both kinds of data based on request and integrates the obtained data to construct organized information that can be used by users directly(6)The scenario construction service packages the space object operating scenario or the result of SSA analysis into the data of the CZML format and visualizes scenarios by using the 3D visualization platform (e.g., Cesium), to meet the cognitive needs. Users can also add custom properties into the data for display in the scenario. The service relies on space object service, data retrieval service, and position calculation service, and it can provide scenario data for the visualization of various analysis scenarios, such as satellite coverage analysis, conjunction assessment, and more(7)The stream computing service can provide the timely computing service for high real-time requirements in SSA analysis, and the batch computing service is aimed at large-scale data computation scenarios that do not require real-time analysis. This paper builds the data analysis architecture and the processing model by integrating the stream and batch computing services, which can combine with the users’ algorithms to realize the data analysis and display the results in different approaches. The data analysis architecture and processing model are illustrated in Section 4

4. Data Analysis Architecture and Processing Model

4.1. Data Analysis Architecture

As an important part of space operations, SSA requires efficient analyses of the complex space activity [74]. However, the spatiotemporal characteristic of space objects leads to large amounts of data and complex calculations in SSA data analysis. Therefore, there are needs for the batch computing to finish analyses that do not require real-time processing and for the stream computing to carry out the high real-time processing. For example, when the operational state of a certain space object changes (e.g. maneuver and attitude change), the actual impacts and consequences of the state change on relevant tasks need to be obtained and fed back to users in real time, which requires the stream processing. The spatiotemporal information of space objects is complicated, and enormous computing power is required to obtain the spatial relationship of space objects within a certain time period; this requirement can be met by employing batch processing. Therefore, it is necessary to construct a data analysis architecture that can satisfy the needs of batch and stream processing.

Based on Section 2.2, this paper builds the SSA data analysis architecture with the stream and batch processing based on the Flink and Lambda architectures, as shown in Figure 7. The Lambda architecture refers to a big data processing architecture that integrates batch and stream processing methods [75, 76]. In Figure 7, the clients include management application and user applications. Management application is used to maintain the data service of the platform. It can perform manual or automatic periodic operations, such as the update operation, on the data layer service. Management application interacts with the data management microservice in the box microservices through the API of data management service in the box RESTful API. The data that needs to be processed is passed to the microservices in the box microservices, and the analysis results are requested through the API provided by the API of data retrieval service in the box RESTful API.

In the analysis architecture, batch computing performs two kinds of roles. First, when the client initiates a data processing request without real-time requirements, it can be processed by batch computing. Next, the space objects (e.g., satellites and debris) display obvious spatiotemporal characteristics, and it is necessary to calculate the positions of the space object during the data analysis, such as conjunction assessment. Because SSA analyses are usually time-consuming, computing the positions of the space objects over a period of time and storing them in databases will effectively improve analytical efficiency. The data analyses of SSA also include real-time processing requirements, which can be met by stream computing. For example, when the maneuver of a space object occurs, users need to immediately perform a conjunction assessment to determine whether this maneuvered object will be a threat to the other objects. The batch and stream computing services receive the data from the client and process them by using user-defined algorithms.

When the position data of the objects exist in the cache service, the computing services can retrieve these data from the cache service, which prevents redundant calculations from occurring. After the completion of the computing process, the data that needs to be persisted can be stored in the persistence databases, and the analysis result required by the user is stored in the cache service. Finally, the clients obtain the data stored in the persistence databases and the analysis result in the cache service through the data retrieval service.

4.2. Data Processing Model

Due to the spatiotemporal characteristic of SSA, a general spatiotemporal-oriented data processing model for space objects is proposed in order to process the data in a better way. As shown in Figure 8, the execution flow of the processing model is as follows: (1)Getting the input dataset. The input dataset includes the time range and the calculation objects targets. Each target contains a set of objects that can complete the calculation, for example, in the conjunction assessment, Target x includes one primary and one subordinate space object(2)According to the time range and a certain time interval (e.g., one day), the dataset from step (1) is divided into new datasets. Each new dataset contains a sub-time range and calculation object targets(3)The targets of the datasets from step (2) are split into a separate object Target x to form new datasets. Each new dataset contains a sub-time range and calculation object Target x(4)This step contains a series of processing maps, and each processing map contains a user-defined algorithm (e.g. A.1, A.2,…, A. in Figure 8). The data from step (3) will be processed through a series of maps, and the results obtained include the unique identifier generated by Target x and the sub-time range . Simultaneously, each result can be constructed by adding the other information and custom properties for special needs(5)The analysis results from step (4) will be combined in this step according to the unique identifier in chronological order. The result finally formed is the analysis result of the object Target x in the time range (6)The results obtained from step (5) are stored separately in the persistence database and cache service according to different requirements. The client and users obtain the results through the RESTful API

5. Case Studies and Implementation

This article uses two cases to test the proposed platform. The experimental system environment includes 5 nodes, and the details of all nodes are shown in Table 2. The service gateway, load balancing, service registry, and configuration services are deployed in the master node; functional services are deployed in the slave nodes; all databases and cache services of the service layer are deployed in the data server node.

5.1. Case I: Microservice-Based Satellite Coverage Analysis

As an important application efficiency indicator of earth observation satellites, the satellite coverage capability is of great significance for the mission planning, constellation design, and acquisition of data [77]. Common algorithms mainly include analytical methods [78], grid point methods [79, 80], and geometric operation methods [81]. The analytical method is only applied to single satellites and regions. The calculation efficiency and accuracy of the grid point method are greatly affected by the grid size. These algorithms are computationally intensive and time-consuming. In view of these problems, we propose a satellite coverage analysis algorithm based on the extended minimum bounding rectangle (EMBR) of the ground area, called EMBR-SCA, to verify and test the platform proposed in this paper.

5.1.1. Algorithm Principle and Flow

The calculation of the satellite coverage area is complex, which is one of the main factors affecting the computational efficiency. Within one satellite orbital period, the satellite coverage area only has a limited time to join with the ground area. Preventing the calculation of the satellite coverage area in the disjoint time period will improve the efficiency.

The points, lines, and polygons used for the judgment of spatial relationships are converted to suit the plane coordinate system. Simultaneously, the rectangular centrum sensor model is taken as an example, and other sensor models can be analyzed based on this method. Figure 9 shows that polygon is the satellite coverage area, point represents the intersection of the satellite sensor centerline with the earth ellipsoid, the dotted line represents the motion track of point , polygon is the ground area, polygon is the minimum bounding rectangle (MBR) of , and polygon is the EMBR of . The EMBR is obtained by extending the MBR of the ground area by a certain angle in the southeastern and northwestern directions, which will be described in Section 5.1.2. The algorithm principle is as follows: within the satellite orbital period, the maximum central angle of the satellite coverage area on the earth ellipsoid will not exceed a certain value . Polygon is then built by using as the certain angle. If polygon and point are disjointed, polygons and must be disjointed. In that case, there is no need to calculate polygon , and this is implemented to avoid an excessive calculation of the satellite coverage area. The algorithm flow is as follows: first, angle is calculated during the satellite orbital period. Angle only needs to be calculated once during the entire satellite orbital period. Angle is used to extend polygon to obtain polygon . Figure 9(a) shows that polygons and must be disjointed if polygon and point are disjointed. In this case, there is no need to calculate polygon . Figures 9(b)9(e) show that polygon and its spatial relationship with polygon must be calculated if polygon contains point . Figure 9(f) shows that polygons and are disjointed if polygon does not contain point . In this case, point must be calculated without calculating polygon , and it must be determined if polygon contains point . The algorithm only calculates polygon during a certain part of the satellite orbital period, which reduces the calculation and increases the efficiency. The algorithm records the time period and coordinates of the satellite coverage area intersecting with or containing the ground area; these data can be used to obtain other satellite coverage parameters such as the coverage ratio.

5.1.2. Establishment of the EMBR of the Ground Area

Attitude maneuvering of the satellite ontology will lead to a complex calculation of . To balance simplicity and accuracy, a special method is proposed.

The cut-away view along the meridian in Figure 10 shows that points and are the intersections of the ground coverage of the satellite and earth ellipsoid at time , respectively; the corresponding central angle of the arc is . If the field of view is fixed, reaches the maximum when the boundary ray of the satellite sensor is tangential to the earth ellipsoid. The calculation of angle is not simple; therefore, line is created, with . Because is smaller than and the calculation of is simple, we obtain by calculating . The angle can be calculated in where . The partial derivative of Equation (1) with respect to parameters , , , and shows that decreases with and increases with , , and . The following relationship exists: where is the semimajor axis of the earth ellipsoid and  m, is the semimajor axis of the earth ellipsoid and  m, is the distance between the satellite apogee and the center of the earth, and , , and . Taking the rectangular centrum sensor model as an example, Figure 11 shows that the horizontal half angle and the vertical half angle . The maximum can be calculated in

Therefore, the angle can be calculated by using Equation (4), and the EMBR of the ground area can then be achieved by using to extend the MBR of the ground area.

5.1.3. Comparison and Analysis of the Calculation Accuracy and Efficiency

To verify the computational efficiency of EMBR-SCA based on the proposed data analysis and processing model, we compare the results of the satellite coverage by using EMBR-SCA and STK [73].

The experiment dataset details are shown in Table 3. The ground area data in Table 3 are the geodetic coordinates of the points that make up the area; the calculation time step of the satellite position is 1 s; is the horizontal half angle; is the vertical half angle; and , , and are the attitude maneuvering parameters of the satellite ontology. The satellite ephemeris data are represented by the two-line orbital element (TLE).

The comparison of the intersection time windows of the satellite coverage with the ground area is shown first. We use the differences in the start time, end time, and time length separately for the comparison. The results are shown in Figure 12. The range of the differences is less than 1 s, which indicates that the calculation accuracy of EMBR-SCA is close to that of STK.

To compare the coverage rates, the grid size of the ground area in STK is set to 0.05°. The results in Table 4 show that the coverage rate differences between EMBR-SCA and STK are small and meet the actual needs.

To compare the calculation efficiency by using the proposed platform, the traditional algorithm, EMBR-SCA, and EMBR-SCA are tested based on the data processing model with different calculation thread counts. The results in Table 5 show that EMBR-SCA based on the data processing model achieves a more than six times larger speed-up ratio. The time consumption associated with different thread counts in Figure 13 shows that the more the thread counts, the smaller the data quantities per segment and the shorter the calculation time. When the thread count is constant, the calculation time is proportional to the number of satellites, which is expected. The number of ground areas has minimal impact on the calculation time because the datasets are decomposed into a combination of one satellite with all ground areas. The parameters of the satellite for different ground areas must be calculated only once.

5.1.4. Visualization of the Case

Based on the proposed algorithm, this paper integrates the case into the platform as a demonstration demo. When using this demo, as shown in Figure 14, the time range and time step should be first selected. Then, the earth observation satellite can be constructed, which includes the name and TLE data; following that, a sensor with different parameters should be added. The option to set the attitude of the satellite is also provided in consideration of the attitude change. After that, all the parameters can be displayed in the form of JSON in the right list widget. After the data analysis is performed, the results can be presented in 3D scenario by using Cesium or chart visualization.

5.2. Case II: Microservice-Based Space Object Conjunction Assessment

The increasing number of orbital space objects (satellites, rockets, debris, etc.) has led to a deterioration of the space environment and constituted a serious threat to the normal operation of spacecraft, space missions, and future space developments [69]. The United States and Russia satellite collision that happened on February 10, 2009, is powerful proof.

The operational safety of space objects requires robust and effective space object information [82]. Preventing the collision between space objects has become an urgent problem that requires a solution, and the conjunction assessment is an evaluation indicator for the collision risk of space objects [83]. Beyond that, the conjunction assessment can be applied to various analyses of space operations, such as the timing determination of space-based target imaging.

To improve the efficiency, the conjunction assessment typically uses a series of filters to screen objects. The most common screening processes are proposed by Hoots et al. [83] and Rodríguez et al. [84], but some filters in the two methods are not robust [85]. In response to these problems, different software and solutions [70, 86, 87] have been proposed to improve the processes. Through the algorithms’ experiments and the screening steps, this paper proposes a robust data filter process and uses the process as a base case to test the platform and data processing model proposed here.

5.2.1. Filters of Conjunction Assessment

The filters that have been implemented in this case are as follows:

(1) Perigee/Apogee Filter. This is the most robust filter in the classical prescreening schemes, which can filter out lots of space objects. But according to the test from Alfano and Finkleman [88], it is necessary to add a pad of 50 km to the conjunction threshold distance for distance screening based on probability-based actions. The subordinate object cannot pass this filter if Equation (5) is met: where is the larger of the two perigees, is the smaller of the two apogees, and the conjunction threshold distance .

(2) Filter. This filter is improved by Chen et al. [89]. The time period is selected, and the distance between two objects is compared in time . If the distance between two objects is greater than in Equation (6) at all the given analysis intervals, the current subordinate object cannot pass this filter: where is the escape speed and is usually 3% of the average orbital period of the two objects [89].

(3) Minimum Filter and Fine Filter. Minimum filter and fine filter are proposed by Rodríguez et al. [84].

Integrating the above filters, the object filter process is as shown in Figure 15.

5.2.2. Comparison and Analysis of the Calculation Accuracy and Efficiency

The conventional method is less efficient when conjunction assessment is carried out between the primary object and all the other orbital objects in the back-end database, a process referred to as the one-to-all conjunction assessment. The one-to-all conjunction assessment is a typical SSA analysis task, and the data processing model proposed in this paper is very suitable for the conjunction assessment. The time range in the one-to-all conjunction assessment can be segmented by step (1), and each filter can be constructed as a separate map by step (4) in Section 4.2. After all the filters are completed, the objects that are close to the primary object can be obtained by comparing their distance and the conjunction threshold distance.

This study combines the conjunction assessment filters with the proposed data processing model and conducts the related experiments. First, this study calculates the minimum distance and the closest moment between the primary object and the given subordinate objects. The comparative data represents the top 10 objects by minimum range from CelesTrak, and the comparison are shown in Table 6. The start computation time is April 28, 2019, 00:00:00, and the stop computation time is May 5, 2019, 00:00:00. The conjunction threshold distance is 5 km. The ephemeris data of all the objects is obtained from CelesTrak. The result shows that the minimum distance and the closest moment obtained in this paper are very close to the results given by CelesTrak, which indicates that the accuracy of the conjunction assessment can meet the needs.

On the basis of meeting the accuracy, this paper carries out the calculation efficiency test of the one-to-all conjunction assessment. This paper chooses three primary objects for experiment: FENGYUN 1C DEB (NORAD catalog number: 30879), IRIDIUM 33 DEB (NORAD catalog number: 35619), and MICROSAT-R DEB (NORAD catalog number: 44201). To each primary object, the subordinate objects are all the other orbital objects in the database. The count of the subordinate objects is 17854 (data current as of April 28, 2019, 00:06:00 UTC). The running environments involved in the comparison are listed as follows: the single thread running on a single machine, the stand-alone service instance, and the distributed service instances (three nodes) running the data analysis architecture and process model proposed. As shown in Figure 16, the result shows that the computational efficiency can be greatly improved based on the data analysis architecture and process model proposed in this paper.

5.2.3. Visualization of the Case

Based on the conjunction assessment, the visualization of the case is constructed here, as shown in Figure 17. The algorithms of the filters and distance computation have been integrated with the data analysis architecture and processing model proposed. For a one-to-all analysis, the primary object can be selected at the front end. After the analysis task is submitted, the server side begins the conjunction assessment based on the data analysis architecture and the processing model. The analysis results are stored in the cache service, and the users get them through the data retrieval service. By constructing a 3D scenario, the conjunction assessment can be visualized.

6. Conclusion and Future Plans

The development, deployment, and maintenance of the current SSA service systems have become more complex, which hinders the application of innovative algorithms and the promotion and dissemination of the easy-to-understand SSA knowledge to the public. In response to these problems, we propose the microservice-based platform for SSA data analytics, which is designed for SSA promotion and for innovation researchers to test and integrate their algorithms. This platform allows sustainable delivery and is easy to deploy. To facilitate the usage and development, different dataset sources are merged and the SSA data service is constructed. The platform builds a series of basic services and describes the deployment method. Aiming at the massive computing needs in SSA, this paper proposes the data analysis architecture and processing model. Based on the above, the platform is deployed and tested via two typical case studies. In order to better improve the cognition of analysis results, different schemes are used for the data visualization. The results show that the platform proposed can easily integrate various analysis algorithms and use efficient architecture and calculation strategies to satisfy various needs of the public and scientific institutions.

In the future, we will reinforce the prototype platform to create greater convenience and benefits. To meet the needs of SSA applications and improve the practicability of the platform, more practical applications and cases need to be integrated and tested. Simultaneously, the platform will provide users with more comprehensive service access interfaces in the future to meet the integration of heterogeneous data and user-defined algorithms. Effective and appropriate visualization methods can significantly reduce the cognitive difficulty of SSA information, which shows that more comprehensive visualization solutions need to be integrated. The increase of system services requires the construction of the overall system monitor. Furthermore, the rapid development of artificial intelligence (AI) and machine learning (ML) also opens up new research directions for SSA, and the future platform will build user-oriented machine learning microservices that allow users to apply data, models, and algorithms for the cognitive improvement of SSA.

Data Availability

The authors declare that all data underlying the findings of the manuscripts can be shared with researchers, and the authors allow all readers to be able to access the data supporting the conclusions of the study. There is no unavailable data that cannot be released.

Conflicts of Interest

The authors declare that there is no conflict of interest regarding the publication of this paper.

Authors’ Contributions

Wanjie Lu and Qing Xu conceived and designed the research; Wanjie Lu, Chaozhen Lan, Liang Lyu, and Qunshan Shi developed the platform together; Yang Zhou provided the algorithms for building cases; Wanjie Lu and Yinghao Zhao participated in data collection; Wanjie Lu and Chaozhen Lan wrote the paper.

Acknowledgments

We would like to thank all individuals who contributed to the development of the platform, including the students who assisted in improving the platform by testing and reporting bugs. We would like to thank Editage (https://www.editage.cn) for English language editing. This research was funded by the National Natural Science Foundation of China, grant number 41701463.