 | | | | |
| | | | | |
|
About us Software Engineering and Standardisation Software life cycle Software building blocks Software standardisation Archive Services Useful linksContact usFOR SECURITY REASONS, ALL LINKS TO THE ftp.estec.esa.int SERVER ARE DISABLED. YOU MAY REQUEST RELATED DOCUMENTS TO bssc@esa.int
| | | | | | | Application Building Blocks
A number of building blocks are being developed that implement particular applications in on-board software.
Mass memory management
Generic Architecture for Mass Memory Access (GAMMA) is a layered, distributed architecture independent of the mass memory technology. It supports a transparent memory storage partitioning, leading to an increase in storage reliability, security and performance. The layered architecture eases the integration of COTS components while ensuring their isolation in order to avoid fault propagation.
The architecture can also take advantage of the development of hardwired functions to support the storage and ensure the consistency of the data in a distributed system.
The SciSys/SEA study on mass memory architecture builds heavily on preceding work within the UK UNIONICS developments, which has already demonstrated a Mass Memory Unit (MMU) capability distributed within a networked system using SpaceWire interfaces and routers. In the predecessor work, the networked MMU nodes are flexibly designed as remote Direct Memory Access (DMA) functions that can be configured and used via two SpaceWire ports.
The current study extends this concept considerably through the development of a consolidated architecture that provides a mass memory system which is highly configurable, much more flexible in application, and has a higher potential performance than existing SSMM equipment.
On-Board Planning
Greater on-board autonomy, which extends the level currently supported by existing Packet Utilisation Standard (PUS) services, has been proposed as a means of improving science return. Autonomy in this sense is defined as having software elements which can modify or create a rover timeline.
The motivation for this is that an on-board element, with access to the actual on-board state, is in a position to adapt the nominal timeline in response to anomalies or opportunities in a timely manner. This will prevent excessive downtime and impact on the operational schedule. What is required therefore is a service which can take stock of the rover state, assess the remaining timeline and its nested priorities and compute which remaining activities should be carried out. This computation should optimise resource usage while ensuring that essential engineering tasks are catered for and that the rover is not put in any danger.
In an effort to address key questions concerning the adoption of planning and scheduling technology, a study called Mars Mission On-board Planner and Scheduler (MMOPS) has been conducted as part of ESA’s Aurora programme.
Last update: 19 March 2007 | |
| | More information Gamma (pdf)MMU (pdf)MMOPS (pdf)
|
