SOURCEFORGE » RALF » 2014 Sputnik strikes back

h1. Mission Analysis

{{>toc}} 

Since the beginnings of space exploration, space missions have been and continue to be the apex of human engineering capabilities. Their high costs and the impossibility of repair once launched, make it necessary to plan ahead for every possible events and environments susceptibles of disturbing the mission. The resulting systems used to achieve the desired objectives considering all possible adversities have an elevated grade of complexity, with numerous subsystems interacting with each others. In order to increase the chance of success, systems engineering techniques are implemented throughout all the phases of the mission.

h2. Systems Engineering

*Systems engineering* (SE) is the science of developing a system capable of meeting requirements within often opposed constraints. The main task is to find a safe and balanced design in the face of opposing interests and multiple conflicting requirements. In other words, system engineering is about balancing organizational and technical interactions in complex systems.

Hence, it is about tradeoffs, compromises and generalists rather than specialists in a complex system development process.

The processes of the SE engine are used to develop and realize the end products. These set of technical processes are classified in three groups: system design, product realisation and technical management.

System design processes are related to the definition of the mission objectives, the generation of technical requirements, and the corresponding translation from technical requirements into a design solution.

Product realisation processes are used to create the design solution for each product and to verify, validate, and transition up to the next hierarchical level products that satisfy their previously defined design requirements.

The technical management processes are used to establish plans for the project, which would be used to monitor progress, to control technical execution of tasks and, finally, to produce useful information which would help to make decisions.

The mission analysis and definition in this project have been realized following the recommendations presented by the NASA, in the book _“NASA Systems Engineering Handbook”, Revision 3_.[1]

From a practical and factual point of view, taking into account the project objectives, there is no need for a complex system engineering approach. However, some basic project planning and control is needed.

Although many system engineering tasks will be trivial or useless in our Cubesat project, as it was previously explained, it is of interest, from an academic point of view, to have an approach to this field since we are working with a small spacecraft system.

h2. Stakeholder Expectations Definition

h3. In general

The first stage of the System Design, its main purpose is to identify who the stakeholders are (people or groups with interests in the mission) and their intentions for the project. A definition process is suggested for complex missions, where many stakeholders may be present, each with different expectations for the project. 

With this information, a set of high-level requirements is obtained, following the information path depicted below: 

p=. !flow.png!

_Product flow for stakeholder expectations, from the NASA Systems Engineering Handbook_

Where : 

* The *Mission Authority* is the entity in charge of the mission

* The *Mission Objectives* are defined from the needs, wants, desires, capabilities and constraints from the stakeholders.

* The *Operational Objectives* specify how the mission has to be operated in order to achieve its objectives.

* The *Success Criteria* defines when the mission is considered as successful.

* The *Design Drivers* consist of important constraints such as the launch date, duration, orbit, that may guide the design of the mission.

The output of this stage are a set of high-level requirements, that will be the input of the technical requirements definition process.

h3. The Cubesat project

In the case of our cubesat project, the stakeholder expectations definition is considerably simple.

The sole stakeholder in the project is the SatCom lab, and more precisely, its director, the group of students currently working on the CubeSat, and future users of the platform. The desires: to set ground for future Cubesat projects, and to develop a proof-of-concept of a simple Cubesat mission.

Following the above mentioned flow chart, the key points used for defining the top-level requirements are presented below.

*Mission authority*

Laurent Franck, director of the SatCom lab.

*Mission objectives*

Develop a prototype of a Cubesat mission, capable of communicating with ground.

*Operational objectives*

* Integrate and test the Cubesat with its payload

* The testing phase at laboratory shall prove the following system capabilities: 

** Establish a communication with ground

** Download telemetry from the satellite, to obtain its position

_Note: Since this project is being developed as a proof of concept for a CubeSat mission, the set of tests and measurements to be done at the laboratory, shall provide operational proofs under conditions as close as possible to real space missions. Therefore, it shall be carefully evaluated the design of tests and channel emulation._

*Success criteria*

The definition of success varies between Cubesat missions. However, it has been noted, that when communications are already established, the success rate is incredibly high. Therefore, we consider a successful mission if a communication link can be established.

*Design drivers*

	Not specified for this simple project.

The mission end to end architecture is depicted in the following diagram:

p=. !oparchitecture.png!

h2. References

[1] "NASA Systems Engineering Handbook":https://acc.dau.mil/adl/en-US/263346/file/40975/NASA-SP-2007-6105-Rev-1-Final-31Dec2007.pdf