Satellite Earth Observation Platform
IIMEO aims to advance key building blocks of future new-space earth observation missions by enabling improved, weather-independent imaging and reduced latencies. To this end, the project focuses on bringing innovative sensor and processing technologies to the payload in the form of a Ka-band sensor for high-resolution SAR imaging, and, in the spirit of edge computing, a powerful on-board processing platform enabling the deployment of state-of-the-art, AI-supported data processing for increased on-board autonomy and decreased transfer-rate requirements. Development efforts focus on the payload components, with the on-board processing unit and the on-board processing software expected to reach TRL 6 at the end of the project. In the interest of demonstrating the novel on-board technologies in a credible environment and to illustrate future EO infrastructure monitoring services based on developments from the project, the full pipeline from data source to end user shall be established with railway monitoring as a pilot use-case. Mimicking deployment on future constellation satellites, the on-board processing technology demonstrator shall be integrated with an airborne platform.
Technological innovation focuses on the payload which is intended for future deployment on LEO constellation satellites. EO missions in LEO utilize lower-cost small satellites and are capable of providing high resolution data, but in turn require numerous units for global coverage. To avoid data transfer bottlenecks associated with data volume, a promising approach is to perform crucial processing operations on-board. This is referred to as edge computing (contrasting cloud computing, where data is transferred away from the source to some platform prior to processing).Satellite on-board processing requires sophisticated, space hardened hardware tailored to the task. Infrastructure monitoring tasks require data from several sensors to be sensibly combined and evaluated. For the IIMEO project, SAR and VIS sensors serve as the primary data sources. SAR sensors are capable of providing high resolution data regardless of
weather or time of day. However, SAR images are difficult to interpret for the non-expert. Further, SAR sensors require inclination with regard to the normal, making nadir imaging impossible. To address these shortcomings, nadir and oblique VIS sensors accompany the SAR sensor. The oblique VIS sensor is aligned with the SAR sensor with the intention to provide service users with more accessible data of sites of interest. The nadir VIS sensor allows imaging of regions that are occluded from the oblique sensors. Within the project, concepts for fusion of SAR and VIS data shall be explored to enhance the algorithmic detection of infrastructure
events whenever both data sources are available. Any data collected by the sensors is passed on to the on-board processing, which combines FPGA, VPU and GPU hardware with an innovative neuromorphic module for optimized and fault-resistant AI-acceleration. Further processing steps include detection of infrastructural changes and anomalies, as well as of clouds exclusively in VIS data. For change detection, data need to persist in the on-board storage for two or more revisits. It is expected that only a part of the processing will be realized on-board. The selection of the processing running on-board should be done during the execution of the project based on priorities identified for the use cases taking the technical limitations into account.
A primary factor for on-board processing is the reduction of data volume, in order to save bandwidth during transfer and to limit heat production during processing. User-specified preselection of data is a sensible approach to facilitate this. Coarse preselection is possible earliest at the point of image taking, and more precisely once image data have been appended with location metadata at Level-0. By accessing an updatable database of user-specified regions of interest, relevant data can be limited to those regions where infrastructure monitoring is necessary and omitted entirely where this is not the case, e.g. above extended water bodies or in between sites. Minimal latencies are expected when service-related processing steps like change and anomaly detection are performed on-board, and transferable data is limited to the vicinity of the positive result. Using smart queueing, L-0/L-1 data can be transferred regardless of latency for multipurpose-use when the required bandwidth is available. Another layer of optimization of resolution and delivery time is facilitated in a constellation concept: following the overpass of one satellite screening for infrastructure disruption events, a second overpassing satellite can provide very high-resolution data of the scene by using spotlight mode SAR after regional preselection based on coordinates provided by the first satellite.
Within the scope of the project, the data processing, storage and service in the ground segment will be implemented as a cloud-based prototype platform using custom or commercial/open-source tools for data distribution and service provision. Service and processing design for the off-board segment will reflect advances of the “Generic Infrastructure Monitoring Platform” prototype, a service platform developed within the CityCLIM Horizon 2020 project which is an ideal candidate for future commercialization of infrastructure monitoring services. This cloud-based platform is intended to provide storage engines for generic data processing workflows, interfaces for receiving and providing data upon request as well as billing and account systems. The pilot service, railway monitoring, will be accessible to the pilot user via a web interface during demonstration. The platform is intended to host multiple services using different data sources, and to provide direct access to data products via EO data services.
Another important aspect that needs to be respected is the later use case/business case for the proposed hardware and algorithm. Infrastructure monitoring is a “Change-Detection” application, means revisit times from 1h or below are needed (in difference to mapping with days or weeks revisit times). That means, if done from LEO (in 500 to 900 km high) it would require a satellite constellation of 24+ satellites, typical on 3 or 4 orbital planes. Keeping this in mind, and the return of invest, this is a use case of micros-satellites in the mass range below 200kg, where the investment costs per satellite is below 10 Mio Euro (in opposite to big satellites as ENVISAT or SARLUPE). Higher cost cannot be reimbursed in a commercial approach. These satellites are limited by two parameters: 1. Energy/Heat dissipation of the SAR payload and 2. The downlink capacity bottleneck. The power/heat problem can be solved by SCanOnREceive SAR approach and only operating the payload over area of interest (currently systems as Iceye or Sysnspective allows 3 to 5min operation per orbit, a SCORE SAR can be operated 10 min per orbit). The downlink bottleneck should be solved by the proposed activity, means by using AI for the on-board data processing up to Level-2 data. Keeping the orbit in mind, as well as the costs per satellite, a COTS/Class 3 EEE-Part approach needs to be used, also called NEWSPACE. Typical lifetime will be 7 years with 25-35 kRad radiation environment. Following this approach, the hardware for the on-board processing is selected.