open day requirements esa

ESA UNCLASSIFIED – For Official Use

OPS-SAT Requirements


Software Applications

OPS-SAT Requirements | Slide 3



1. Software Experiments

2. Anomaly Detection

3. Framework

4. Camera




Bandwidth:

1MBps down, up as much as possible up to 1 Mbps

2 passes daily, less than 6 hours

Power:

None

CPU:

As fast as possible

ARM Cortex-A9 would be great

LEONIII (OPS-SAT should allow this on FPGA)

2 processors (communicating with each other)




Software: (No one required RTOS)

Linux

Java, C++, Erlang

Payload:

Access to camera (50m): 50m impossible with present technology and size constraints. Please see if you can live with a much lower resolution.

AOCS:

1 degree accuracy

Synchronized time with GPS

On-board memory:

MMU, R-map protocol



Anomaly Detection

Bandwidth:

9.6 kbps up/down OK

Power:

None

CPU:

Own dedicated system for diagnostics (i.e. Two processors need to run)

Need to be able to handle the processors themselves

Software:

Linux

Java



Anomaly Detection

Payload:

Access to camera

AOCS:

None

On-board memory:

None (depends on algorithms)

Other:

Colloboration with other OPS-SAT experimenters

Information about TM from sensors, actuators and software parameters of other experiments



Framework

Bandwidth:

None

Power:

None

CPU:

ARM, LEONII or III

Software:

POSIX

C++



Framework

Payload:

None

AOCS:

Access to data

On-board memory: at least the following

4MB RAM

2MB FLASH

Other:

Simultion Facility on ground

Debug links to target systems



Camera

1. Requirements for track „Software Applications“

2. Contacts:

a. Vessel watch - Karima hein, [email protected]

b. rasdaman - Peter Baumann [email protected], Dimitar Misev [email protected]

c. iGeotec - Tim McCarthy, [email protected]

d. Fry - Keean Schupke, [email protected]

3. Coordinator: [email protected]



Bandwidth reqs

1. Vessel watch

a. none

2. rasdaman

a. none

3. iGeotec

a. Uplink: small control connection

b. Downlink: video burst 4-5 secs @ 4 fps...30fps (MPEG2: 1 MB/s)

4. Fry

a. Downlink time-/bandwidth product: 1 raw hi-res image frame per overpass



Power reqs

1. Vessel watch

a. Normal CPU operation: object tracking

2. rasdaman

a. Normal CPU operation: database server

3. iGeotec

a. Normal CPU operation: Nav info acquisition, image/video processing

4. Fry

a. Normal CPU operation: camera, CPU for video processing

5. No experiment adds unforeseen hardware → no excessive power consumption



CPU reqs

1. Vessel watch

a. ARM + FPGA

b. Optional: Multicore, 1.5+ GHz

2. rasdaman

a. Any Linux-compatible CPU; Intel x86 compatible preferred, ARM etc possible

b. Optional: Multicore

c. FPGA

3. iGeotec

a. FPU

b. ARM or compatible (image analysis & categorization; compression)

4. Fry

a. FPU

b. ARM or compatible; alternative: Intel ATOM

c. Optional: Multicore, 1.5+ GHz



Software reqs

1. Vessel watch

a. Linux, python, optional: C runtime system

2. rasdaman

a. Linux, C++ runtime environment, sqlite (NB: sqlite already used on mobile phones, readily available on ARM), Java (optional)

3. iGeotec

a. Linux

4. Fry

a. Linux, C/C++, python, OpenCV, FFMPEG (can port those)



Payload reqs

1. Vessel watch

a. 2 cameras (nadir, space); direct connection to CPU („smart camera“)

b. GPS + platform orientation

2. rasdaman

a. Camera; great to have: multi-spectral (infrared!)

b. GPS + AOCS

3. iGeotec

a. 5 megapixel camera, with video burst; pointing; multi-spectral (infrared!)

b. GPS + platform orientation

4. Fry

a. Hi-res camera (optical, infrared, spectrograph); pointing (optional); zoom (optional)

b. Inertial control system (optional)



AOCS (attitude orientation control system)

1. Vessel watch

a. Access to AOCS + clock from Linux

2. rasdaman

a. AOCS (for georeferencing camera images)

b. Access to AOCS + clock from Linux

c. Accuracy: whatever is available, optional: subpixel accuracy relative to camera

3. iGeotec


b. Decimeter level accuracy (.5 degree or better)

4. Fry




On-board mem reqs

1. Vessel watch

a. RAM: moderate (500+ MB)

b. persistent storage: 4 GB (incl OS)

2. rasdaman

a. RAM: whatever is avaialble; optional: as high as ever possible

b. persistent storage: 64 GB, optional: whatever is available

– best: 512 GB SSD, weighs 70g with cage)

– Or several SD cards, 64 GB each

3. iGeotec

a. RAM: none in particular

b. persistent storage: none in particular

4. Fry

a. RAM: 0.5+ GB

b. persistent storage: 16+ GB


Network & Protocols



Network & Protocols

• IP based access to S/C (note no-one providing this end to end yet!)

• Bidirectional links

• DTN (ion, dtn2, trasys) over IP/CCSDS

• Current estimated bandwidth acceptable (the more the better!)

• Access to S/C over the internet from institute/company big asset to many

• Multiple GS access for DTN would be nice

• RTOS

• FPGA



Network & Protocols

Question:

• The network bandwidth will be a constant stream (priority based?) or agreed outage times for other commanding/activities?)

• How much power can we get? (most SW apps, but intensive transfer needs more power)


On-board System Applications & Communications



Outline

1. Global impressions

2. Communication link requirements

a. Payload of opportunity: Radio with NI equipment

3. Interfaces requirements

4. Processing requirements

5. Living within the experimental part



Global impressions

1. Group intended to put together people who will affect interfaces

2. Very diverse group:

a. FPGA users

b. Software users (TSP partitioning, FDIR, new OBSW software architectures)

c. Mixed (FPGA recof + software)

d. Communications systems

3. Not so many requirements derived, but strong realizations about what implies to be in the experimental part were made



Communication link requirements

1. It is assumed by several experiments that a standard service is provided by the system for comms:

a. Change band, modulation, coding…

2. Access to UHF radio is desirable

3. The running experiment shall be able to get the exact transmission time of a frame:

1. Deterministic model of transmission

2. Signalling of frame transmission

4. The change of modulation is requested by several experiments: this is a blocking point from the point of view of regulation



Payload of opportunity: Radio with NI equipment

1. An adaptation of a NI radio equipment would be made for OPS-SAT.

2. The experimenter is able to provide a whole communications chain

3. Some elements (power amplifiers, antennas) can be shared with other radios if necessary

4. If necessary, the experiment can be fit in a generic FPGA board with direct interfaces to the radio equipment

5. It is necessary to present the technical budgets of the experiment and the alternatives to make a decision



Interfaces requirements (I)

1. Direct access to the FPGA reconfiguration controller shall be available (to perform partial reconfigurations)

2. Low-level interfaces with the experimental equipment shall be available (e.g. writing a new driver should be possible), especially Mass-Memory

3. The experimental processors shall be able to control the power of the whole experimental part (note implication if switches are on cubesat power board)

4. The experimental part shall be able to get TM from the cubesat part (power, attitude…)



Processing and software requirements

1. Processing power shall be equivalent to a Gumstix (i.e. run Linux and JVM)

2. It is desirable for the FPGA to have a Xilinx architecture (clarified that Cyclone V is also OK)

3. Several processors are expected by some experimenters (e.g. to run a cluster on-board)

4. A service to upload an FPGA or software image for the processors, and then verify the uploaded data shall be provided



Living within the experimental part

1. Some experiments want to take full control of the experimental part

2. Other experiments want to run concrete applications which monitor the system, or change only a part of it

3. This means someone else has to take care of how to download the data, or to provide drivers for equipment (will be experiment partners)

4. A very strong collaboration from the experimenters is needed to handle this:

a. Standard storage structure in mass-memory?

b. Running within partitions of other software?

c. Running on top of a framework?

5. Debate: Is is up to the prime to define a general approach on using the mass memory and downlink?

1. The only requirements for the prime up to now is to provide the upload of images and to make the satellite fail-safe


ADCS



ADCS Working Group Requirements

1. Experimenters involved

a. 95 – On-board enhanced image resolution

b. 75 – On-board optimal attitude control for slew manoeuvres

c. 74 – S/C control using adaptive neural network pred control

d. 94 – Orbit determination using pseudo-range processing

2. Summary

a. No hardware experiments (except laser reflectors)

b. The two baseline systems are sufficient to most extent




Architecture

1. Sensors : (no specific requirements on each)

a. Sun sensors

b. Magnetometer

c. Gyros

d. GPS/GNSS

2. Actuators : (no requirements definable yet)

a. Magnetorquer

b. Reaction wheels

3. Note that no star trackers or mappers are requested. This could be because the opportunity to fly one is new. Please clarify with ESA asap if you can use one and how. Otherwise it will be descoped.




Requirements

1. Performance : 2deg det, 5deg control (except 95, needs 0.x)

2. Mass : no additional

3. Power : no additional

4. Volume : no additional

5. Processing : high processing power 500 MHz

6. Software : to be provided by other experimenters.

a. H/W access layer (modules)

b. Kalman filter, Detumbling algorithm, others? (this will not be provided by the prime. ADCS experiments shall be delivered complete.)

c. Access to GNSS/GPS raw measurements




Open questions / discussion

1. No specific need for gumstix -> but need high processing power with OS

2. Star tracker -> to improve att det but much too complex (see earlier comment)

3. Use experiment 95 as attitude sensing experiment instead

4. Is an FPGA really needed? -> Huge power consumption (we will see)

5. How is H/W protection mechanisms implemented? (part of phase AB1)


Ground Applications



Ground Applications

• Use S-Band transmitter freely (shared access), bypassing the TM/TC chain, for implementing a monitoring service (must have, Min)

• Access to OPS-SAT via another S-band ground station besides NGS1. (Yes for TM, usually not for TC. However if TC is really needed this can be negotiated on a case by case basis)

• Access to OPS-SAT via a distributed ground station network

1. E.g NGS1 + TU Munchen + SARAS

2. Distributed operations experiment (Baumgartner)

• Close geographical proximity of 2+ ground stations

1. Real time operations (nice to have, Minn, others)



Ground Applications

• Access to orbital data (e.g. ground station coverage) (Minn)

1. STDM file format for loading directly into experiment’s own antenna (SARAS)

• Provision of simulators and test harnesses for developing and testing applications before submitting them to OPS-SAT (nice to have, all)

• Keep GUMSTIX processors in design

1. Development so far has been done on this platform (nice to have, Minn) – probably will be descoped.

• Use S-band transceiver for commanding and receiving telemetry from the transceiver itself (must have, SARAS)



Ground Applications

• Access to a virtual channel for inclusion of extra navigation messages to be ignored by other ground stations (must have, Luelf)

• Access to full TM (or at least all experiment related TM) in ESA baseline format (nice to have, all)

• Access to on-board memory for storage of experiment data for dumping later (must have, Minn)

• On-board operating system: Linux (must have, LEON III, nice to have)

• TCP/IP space link (lots of interest from several sources - coordinate with appropriate experiment). Does not exist yet as an experiment.



Ground Applications

• Full, easy configuration of FPGA router without going through the TM/TC chain (nice to have, Minn)

• Easy upload of new versions of experiment S/W (must have, Minn)

• Access to an ESA standard ground segment (e.g. SCOS) for access to the S/C (nice to have, Burek)

• Large (>2/3) overlap between sequential camera images (must have, Metelo)


Scheduling and Autonomy



Scheduling and Autonomy

1. Proposals

a. On-board autonomous planner

b. On-board autonomous controller

c. On-board autonomous diagnosis

d. Goal-based operations/commanding

e. Multi-agent systems

2. Most based on existing systems

a. Assess the use of these systems on-ground



Requirements

Requirement Rationale Severity If not ..

BandwidthDownload 160 kbit/sUpload 50 kbit/s

Upload of the images: < MB Initial uploading of 150 MB It can limit the number of parallel experiments

H

Linux Operating System with JAVA/C/C++

Not to rewrite the existing applications

H

Time & space partitioning RTOS (Preferable VxWorks or PikeOS)

To prove all the functionalities of an experiment

M Required by one of the proposalLinux is ok, but not all features can be demonstrated

On-board memoryFew GB

To host the experiments H

Access to GPS, Startracker H



Requirements

Requirement Rationale Severity If not ..

CPU requirement

Min 300 Mhz

Planners will depend on the available CPU (the better the more efficient) Image processing is more demanding (but this depends on the camera/sensor) On-board diagnostics expensive

M Reduced capabilities

Control S/C attitude Controlling the attitude to take pictures (or while taking picture)

For some experiment real-time access is required

H For some experiments it is sufficient to be Nadir pointing

Debugging capabilities M It is required by only one experiment

Access to orbit M

Direct access to PUS packet

M



Open points

1. How to run experiments:

a. Repetition of the experiment can allow to test different scenarios

b. Single experiments: few orbits

2. Available Payloads

a. They should allow to have complex scenarios to demonstrate concepts like on-board autonomy

3. Contact period duration ?

open day requirements esa

Documents

requirements esa unclassified

requirements slide

requirements ops

official useops

official usecamerarequirements

official useframeworkpayload

official useframeworkbandwidth

overpass ops