On-board payload data store and forward design for

On-board payload data store and forward design for remote sensing satellites Aritra Sarkar, Jafi E.J., Srividhya R., Jothy Soman, Subramanya Udupa, Valarmathi N. Data Handling and Storage Group Control and Digitals Area ISRO Satellite Centre Abstract: The data accumulated from the scientific payloads can be either transmitted in real time or stored, which will be transmitted to ground during the satellite visibility. In case of Low Earth Orbit satellites, since the visibility of the satellite to the ground station is limited due to its orbit period, there is a strong need for storing data on board and then forwarding it to the ground through RF transmission. This also give rise to the need of having a mechanism on-board as to how much chunk of data has to be downloaded and an identity should be attached along with data. It calls for a design where the data has to be stored and managed using file management techniques and downloaded as per the user requirement. The paper discusses the techniques involved in the design of on-board payload data store and forward design for missions like ASTROSAT. Keywords: Solid State Recorder; on-board software; data storage; real time operating system; payload data management; store and forward. 1. INTRODUCTION On-board data storage forms an integral part of a satellite system. Data from the various payloads, as well as the satellite housekeeping data are stored in this memory. The data gets recorded continuously during the entire orbit or as and when required depending on the user requirement. The recorded data is then relayed back during visibility over the ground station for further processing. For some missions, especially deep-space missions, the payload data rates are higher than the communication link from the earth station. Automatic rate conversion is taken care of as the data gets recorded to, and played back from the storage system. The subsystem used to realise this store and forward mechanism is called as Solid State Recorders and has now become an integral part of any remote sensing satellite.

internal timing design to cater to the proper acquisition of the data. c) Memory Technology: SSR is realised using SDRAM and each module can store up to 2 Gb. The individual boards can handle up to 48 Gb. d) Mitigation Techniques: SSR integrity is hardened with Error Detection and Correction (EDAC) logic. Input data to SSR is encoded with Hamming Codes. Additional storage space for these parity data should be considered. e) Automation: Design of the SSR is greatly influenced with the level of automation desired for the mission. In deep space mission, where command transmission time is considerably high, automation should involve self-checks safety logic for internal house-keeping. Ground station intervention should be reduced to a minimum for normal operation. 3. SYSTEM DESIGN The system design of an SSR involves various critical elements which work in conjuncture to achieve the desired operation. These are shown in the figure below.

Figure 1: A typical communication chain 2. SYSTEM DESIGN PARAMETERS The system design of a Solid State Recorder is derived from various requirements: a) Payload data requirement and Mission: The sizing of the SSR is based on the data storage requirement of each payload. Also, the mission planning elements, like orbital period, availability of ground stations for playback of SSR Data, contingency situations, scales the storage requirement. b) Data Rates: Data input to an SSR system is generally through the Baseband Data Handling (BDH) sub-system. The BDH system multiplexes data from multiple payload interfaces, compresses the data if required, formats the data into suitable frames, and send to the SSR for storage and rate conversion. The input data rate of the SSR influences not only the interface technology requirement, but also the

Figure 2: SSR Interfaces and Internal blocks a) IO Interfaces: These units form the front end data interface for reception and transmission of data, to and from the SSR respectively. LVDS technologies are normally used. b) Hardware Logic: FPGA with hardware codes manages the high speed input data. Various control functions are also built in these. c) Software Logic: It involves a Processor running a code from a PROM. Program data storage for processor in done in SRAMs and EEPROMs. d) Control Logic: This involves reception of ground Telecommand and transmission of SSR Housekeeping data to ground. This is done in SµMMIT 1553 protocol chip, and analog interfaces for voltage and temperature monitoring.

e) Mass Memory: These are the solid state chips where the payload data is stored. They are arranged into ‘bank’ and sometimes stacked as multiple memory ‘boards’. Data transmission across boards are over a motherboard. f) Power: Distributes stable power to all ICs with reset logics. 4. SOFTWARE DESIGN PARAMETERS The software of an SSR plays a central role. It interfaces with the hardware logic to control the final destination of the incoming data. Decodes the Telecommands and performs the necessary actions. The housekeeping information is compiled by the software for telemetry transmission. There are various parameters that determine the design of the software. a) Mission Requirements: Various parameters vary based on the mission. Simultaneous record and playback, or played back with erase are some examples. b) File Types: Data in the mass memory is recorded as files. These normally correspond to a data recording session, or payload events that are segregated. There are two primary file types: Linear and Circular. Linear files are preferred in spot-imaging operation satellites (like cartography imaging satellites). Each imaging session is saved as a single file. There are a number of file IDs associated with each operation. The files are played back over allotted ground stations. The memory of each file is reclaimed after successful playback (or as commanded). Circular files are preferred in scientific missions (like planetary rovers, astronomy satellites). Each payloads are allotted a specific portion of the SSR memory by partitioning. The data from the payloads keep rolling in these segments, the older data being overwritten automatically by newer data. This method is discussed in detail in payload data management. c) Coding methodology: Coding of a software can be interrupt driven, or scheduler/polling based. While interrupt driven software mingles well with the architecture of a general purpose computer; it has it disadvantages while testing and qualification in a real-time system where events determine the state of the software. For real time operating system (RtOS) designs, if the software interfacing elements are less and are dedicated, a scheduler based approach is beneficial. An event (say, reception of a Telecommand) is identified by flags which will be regularly polled by software. The flow of the software is to check the events approaching and service them on the allocated timeline. The timelines are constructed on minor cycles which are nothing but time slots and various functionalities of the software are handled here. d) Commanding rate: The maximum Telecommand rates needs to be considered for designing the cycle time of a scheduler so that subsequent commands can be services after proper actions of the current commands are carried out. e) Data rates and segment size: The hardware logics in FPGA control the data flow at high speed. However, the file allocation table and memory allocation logic is difficult to manage in hardware. So, the software searches and calculates segment address and periodically loads the FPGA registers. Once a segment address is loaded, the FPGA can run independently without processor intervention till the chunk of memory in that segment is exhausted. Since the processor works at lower clock speed than the FPGA logics, the segment size and software cycle must be optimal to allow comfortable scheduling of operations in the software. For example, if the software cycle is ‘x’ ms, the FPGA should function independently

for at least ‘x’ seconds. Thus, if the maximum payload data rate is ‘y’ bits per second, the segment size should be at least ‘xy’ bits. 5. SOFTWARE DESIGN The design of the SSR software is based on Scheduler paradigm. After the Bootstrap initialization of the code, the software initializes the hardware FPGAs to the default states on Power On. The software then enters the scheduler routine which loops for the entire duration of the On period. The scheduler time slot period is derived by continuously polling a hardware port which outputs the required software cycle timer signal. On detection of an edge, the operation starts for that time slot. The primary operation of the scheduler are, reception and decoding of telecommands, telemetry compilation, tasks based on decoded telecommand. Apart from the scheduler, rest of the system operations are handled by the respective mode managers. Based on the functioning of a SSR system, the system runs in 3 primary software modes: Configuration, Maintenance and Operational.

Figure 3: Software Modes a) Configuration mode is the default power on mode of the SSR. In this mode, the variables are initialized to the default values. The memory board configuration parameters received from the ground through 1553 commands are loaded in the SRAM variable area and executed in hardware. Specific configuration can be issued by command, or the configuration saved in EEPROM can be loaded. After the configuration mode, the SSR is ready for Diagnostics or Operational sequence. b) Maintenance mode involves diagnostics activities. In the Device Diagnostics, a known data pattern is writing to specific memory area and read back. The Memory bus port for data transmission as well as the integrity of the memory chip control signals are validated in this mode. The addresses of these locations are chosen such that the smallest hardware unit of memory gets validated. In the Memory Diagnostics, locally generated Pseudo Random data sequence is written into the entire valid memory area and played back. The playback back PN data is verified using BER Test Equipment on ground. c) Operational Mode deals with the functional activities of the mission. In this mode, the software receives Record or Playback commands and perform read or write operations. During record operations, files are opened after the initialization. The data received from the BDH is stored in the mass memory. The segment address is being loaded on

after polling for a segment load request from the hardware. During Playback, the files are transferred through the output port by proper sequencing of segment pointers and loading to the hardware for read out. 6. TELECOMMAND AND TELEMETRY DESIGN Beside payload data rate and interfaces, which are managed by the hardware; mission requirements calls for project specific design of Telecommand and Telemetry for each satellite. Towards standardization of the software modules, the basic Telecommands are unaltered for the satellites. These major Telecommands are, Set Mode; Configure SSR; Configure Memory; Diagnose Memory; Record Start; Record Stop; Playback Start; Playback Stop.

Playback involves reproduction of pre-recorded data. The commanded file is accessed through file meta-data. The segments of the file are loaded consecutively in the hardware for continues playback till the end of circular buffer, or on reception of a playback pause command. For proper mission management, two types of playback command is designed. a) Re-dump playback involves the Telecommand specifying the positive offset from the start of the partition. b) Normal playback involves resuming playback from the last paused pointer. A configurable negative offset is added at the beginning for data stitching on ground.

Both Telecommand and Telemetry is strictly tied to the modes, i.e. when a specific software mode is active, only commands pertaining to the mode is accepted. Also telemetry parameters for understanding the state of the SSR system in that mode is compiled for housekeeping telemetry transmission. 7. PAYLOAD DATA MANAGEMENT The management of files is based on mission requirement. A generic design pertaining to the ASTROSAT mission is described here. The entire memory is subdivided into segments of pre-calculated size. Memory is allocated in integer multiples of segments. Thus, apart from the timing constraint on the segment size, segments also determine the resolution for memory allocation. While smaller segment size allows finer control of record and playback data, it demands a larger storage in Processor SRAM for the allocation tables. The primary mission operations of the SSR are record, and playback. Data is recorded in a circular buffer and gets overwritten when the partition end is encountered by the record pointer. Record involves payload data being stored in the SSR. Recording can be from the origin of a partition, or appending to the already recorded data. The Telecommand from ground specifies the Partition ID. As recording continues, for every new segment required for the file, the hardware is loaded with the new address, and the File Databases are updated in the SRAM. Once all the segments in the partition are allocated it overwrites the older recorded segment. The mission operation will ensure the download of older data before it gets overwritten.

Figure 5: Playback operations in a partition 8. Fault Detection, Isolation and Recovery The processor time management is presided by a Watch Dog Timer built in the hardware logics. This counter must be reset in every software cycle to indicate integral operation of the code. On overflow of the counter, the Processor is reset to the code starting. The data in the SRAM involves critical pointers of the payload data. On-board memory must mitigate radiation upsets. The data is strengthened with EDAC logic in a separate EDAC SRAM, or by TMR MVL. On failing to abide by these, the software enters a halt mode with the SSR system safe from doing any unintended non-deterministic operation. 9. ACKNOWLEDGEMENTS We sincerely acknowledge the constant motivation provided by Director, ISRO Satellite Centre, and for allowing us to publish our work. 10. REFERENCES [1] SDRAM Data Sheets [2] Intel 8086 Microprocessor Datasheet [3] Assembler 86 Manual [4] Software Practices for Assembly Language Coding

Figure 4: Recording operations in a partition