open day requirements esa
DESCRIPTION
Open Day Requirements ESATRANSCRIPT
OPS-SAT Requirements | Slide 3
ESA UNCLASSIFIED – For Official Use
Software Applications
1. Software Experiments
2. Anomaly Detection
3. Framework
4. Camera
OPS-SAT Requirements | Slide 4
ESA UNCLASSIFIED – For Official Use
Software Applications
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)
OPS-SAT Requirements | Slide 5
ESA UNCLASSIFIED – For Official Use
Software Applications
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
OPS-SAT Requirements | Slide 6
ESA UNCLASSIFIED – For Official Use
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
OPS-SAT Requirements | Slide 7
ESA UNCLASSIFIED – For Official Use
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
OPS-SAT Requirements | Slide 8
ESA UNCLASSIFIED – For Official Use
Framework
Bandwidth:
None
Power:
None
CPU:
ARM, LEONII or III
Software:
POSIX
C++
OPS-SAT Requirements | Slide 9
ESA UNCLASSIFIED – For Official Use
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
OPS-SAT Requirements | Slide 10
ESA UNCLASSIFIED – For Official Use
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]
OPS-SAT Requirements | Slide 11
ESA UNCLASSIFIED – For Official Use
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
OPS-SAT Requirements | Slide 12
ESA UNCLASSIFIED – For Official Use
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
OPS-SAT Requirements | Slide 13
ESA UNCLASSIFIED – For Official Use
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
OPS-SAT Requirements | Slide 14
ESA UNCLASSIFIED – For Official Use
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)
OPS-SAT Requirements | Slide 15
ESA UNCLASSIFIED – For Official Use
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)
OPS-SAT Requirements | Slide 16
ESA UNCLASSIFIED – For Official Use
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
a. Access to AOCS + clock from Linux
b. Decimeter level accuracy (.5 degree or better)
4. Fry
a. Access to AOCS + clock from Linux
OPS-SAT Requirements | Slide 17
ESA UNCLASSIFIED – For Official Use
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
OPS-SAT Requirements | Slide 19
ESA UNCLASSIFIED – For Official Use
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
OPS-SAT Requirements | Slide 20
ESA UNCLASSIFIED – For Official Use
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)
OPS-SAT Requirements | Slide 22
ESA UNCLASSIFIED – For Official Use
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
OPS-SAT Requirements | Slide 23
ESA UNCLASSIFIED – For Official Use
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
OPS-SAT Requirements | Slide 24
ESA UNCLASSIFIED – For Official Use
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
OPS-SAT Requirements | Slide 25
ESA UNCLASSIFIED – For Official Use
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
OPS-SAT Requirements | Slide 26
ESA UNCLASSIFIED – For Official Use
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…)
OPS-SAT Requirements | Slide 27
ESA UNCLASSIFIED – For Official Use
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
OPS-SAT Requirements | Slide 28
ESA UNCLASSIFIED – For Official Use
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
OPS-SAT Requirements | Slide 30
ESA UNCLASSIFIED – For Official Use
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
OPS-SAT Requirements | Slide 31
ESA UNCLASSIFIED – For Official Use
ADCS Working Group Requirements
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.
OPS-SAT Requirements | Slide 32
ESA UNCLASSIFIED – For Official Use
ADCS Working Group Requirements
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
OPS-SAT Requirements | Slide 33
ESA UNCLASSIFIED – For Official Use
ADCS Working Group Requirements
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)
OPS-SAT Requirements | Slide 35
ESA UNCLASSIFIED – For Official Use
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)
OPS-SAT Requirements | Slide 36
ESA UNCLASSIFIED – For Official Use
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)
OPS-SAT Requirements | Slide 37
ESA UNCLASSIFIED – For Official Use
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.
OPS-SAT Requirements | Slide 38
ESA UNCLASSIFIED – For Official Use
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)
OPS-SAT Requirements | Slide 40
ESA UNCLASSIFIED – For Official Use
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
OPS-SAT Requirements | Slide 41
ESA UNCLASSIFIED – For Official Use
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
OPS-SAT Requirements | Slide 42
ESA UNCLASSIFIED – For Official Use
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
OPS-SAT Requirements | Slide 43
ESA UNCLASSIFIED – For Official Use
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 ?