ESA Summer of Code in Space (SoCiS) 2015 Projects
Below follow the list of the project proposals accepted for 2015 SoCiS. More information can be found on:
- The ERAS software wiki page.
- The ERAS software repository: https://bitbucket.org/italianmarssociety/eras.
- The ERAS software documentation: https://eras.readthedocs.org/en/latest/
2015 Accepted Project Proposals
ERAS Mission Operations Control Center (MOCC)
The purpose of this project is to design the Mission Operations Control Center (MOCC) architecture for the ERAS project, as well as to develop the main modules of the Configurations subsystem for the MOCC.
Benefits to ERAS
A MOCC is a key component of the ERAS project. It allows the planning, execution and control of one-off missions, e.g. EVA scientific expeditions, as well as routine tasks, like, for instance, air filtering maintenance.
The first part of this project consist on the architectural design of the ERAS project’s MOCC.
The design should follow a service oriented architecture pattern. The architecture should as modular as possible, while at the same time shielding the integrity of the information they handle. As stated before, the MOCC should perform three tasks — the planning, control and execution of missions, be they routine tasks or one-offs. The MOCC should also support all activities necessary for accomplishing those three tasks, namely:
- Acquisition, storage and analysis of telemetry.
- Delivery of commands.
- Presentation of information to human overseers.
- Storage of the system’s meta-information:
- Devices capabilities.
- Crew capabilities.
A proposed draft for the MOCC’s architecture is shown in the figure below.
Additional characteristics of the MOCC include:
- It should be divided in subsystems.
- The duties of each subsystem should be clearly specified in the design.
- The communication’s flow and contents between subsystem should be clearly specified in the design.
- Each subsystem should be divided in components.
- The duties of each component should be clearly specified in the design.
- The communication’s flow and contents between components should be clearly specified in the design.
- The communication’s flow and contents between the MOCC and external systems should be clearly specified in the design.
The second part of this project consist on the development of software to fulfill the last of the previous tasks, named “Configurations” in the draft. A list of characteristics the software is expected to posses can be read in the “Deliverables” section.
- Documentation describing the MOCC’s architecture.
- A Tango service (the Configurations’ component) that is able to:
- Return the available Tango devices.
- Given a device, return the description of its capabilities.
- Store a macro.
- Return a list of macros.
- Return the detailed description of a given macro.
- Test suite.
- Stretch goals:
- Macro’s CRUD.
- Device’s CRUD.
- Service to provide details about crew members.
- Crew member’s CRUD.
Week 1-7th June — Discuss and agree on a high level architecture. Document.
Week 8-14th June — Discuss and agree on a design for the Configurations and Telemetry subsystems. Document.
Week 15-21st June — Discuss and agree on a design for the Commands and Planning subsystems. Document.
Week 22-28th June — Discuss and agree on a design for the Operations subsystem. Document.
Week 29th June-5th July — Round up details and finish documentation.
Week 6-12th July — Propose a design for the component to implement, based on the MOCC’s design.
Week 13-19th July — Build a mock version able to receive and answer requests.
Week 20-26th July — Implement all device-related functionalities.
Week 27th July-2nd August — Design a macro definition language.
Week 3-9th August — Implement the language.
Week 10-16th August — Implement adding, listing, and showing macro’s details.
Week 17-23rd August — Finish tests.
Week 23-30th August — Finish documentation