SOURCEFORGE » RALF » 2015 Prototype mission for cubesat

h1. Mission analysis

{{>toc}}

p. We are going to implement a basic system engineering approach, based on the well practice of the NASA, presented in the NASA Systems Engineering Handbook. It is done by going through an engine several times, refining the results at every iteration, so as to arrive at the most precise definition of the system, its solution and tasks.

At the level of our project, we are going to stay do one passage, since the complexity is not that high.

p=. !{width:50%}System_Engineering_Engine.PNG!

Figure : System Engineering Engine

h2(. Requirement definition Process

The first step we had to take was to define the mission from the stakeholder expectations and the technical requirements

h3((. Stakeholder Expectation Definition

p. The stakeholder for this mission is represented by Laurent Franck, head of the SatCom Lab of Telecom Bretagne, located in ISAE-Supaero facilities in Toulouse.

The purpose of this project is to create a “prototype mission”, that is to say to propose, create and develop a proof of concept scenario using the resources and the Cubesat at our disposal.

h3((. Technical Requirement definition

The mission we are to create has multiple constraints on technical aspects, due to the object of the experiment: 

* We are to use the Cubesat Kit we have been provided, and the different equipment already included.

* The mission has to include a transmission of data between the Cubesat and a receiver.

* The mission has to include a sensor and its data to be retrieved

* The complexity should be adequate to the time allocated to the project.

* Small equipment can be ordered if the mission is accepted.

h2. Technical solution Definition Processes

h3.   Logical Decomposition

For this part please refer to the [[Work description]] realised at the beginning of our work.

h3.   Design Solution Definition

As per the work description above, we need to determine which mission we are going to undertake.

We planned that part after getting to a relative understanding and mastering of the different equipment and software belonging to the Cubesat Kit.

During the first weeks of discovery of the system, we determined several missions possible, basing ourselves on common sensors that could be procurable easily. The different missions possible were:

* Reading the temperature: using a thermocouple to retrieve the external temperature of the Cubesat and send it back on Earth.

* Reading the dynamic of the Cubesat: based on either gyro meters or accelerometers, trying to recover the dynamic information and send it back on earth. 

* Reading the hygrometry: using a hydrometer to give back the external humidity of the atmosphere: dismissed on the instant, since the mission couldn’t be a suicide one where the Cubesat would re-enter the atmosphere, and as such would stay in space where there would be no atmosphere or water.

* Retrieving pictures: installing a small camera on the Cubesat to send back pictures periodically to be stored and processed on Earth.

Following the planning determined earlier, we debated the different solutions with the principal stakeholder and counsellor, Mr Laurent Franck. From this discussion, the followings items were determined:

* Any mission to be accepted should be implemented as an autonomous process, meaning that no telemetry should be implemented, task which would increase the complexity tenfold as receiver and emitters would be placed on both ends of the system.

* Retrieving the temperature is a feasible task, and a common sensor used for that could be a thermocouple.

* Reading the dynamics of the Cubesat is possible but was deemed as of low interest since it would be a similar mission to the thermocouple one.

* The hygrometry was dismissed nearly instantly.

* Retrieving picture is a very interesting mission, but the complexity would be greatly increased compared to the other ones. The size of the data would be on another level, and would enter in the system the problem of integrity. However, the sensor is already know and common, we would use a serial camera.

The result of the meeting was that the most interesting mission would be retrieving picture, but as the complexity may prevent the mission to be completed in the imparted time, we would still keep in reserve the temperature mission as a backup mission.

At that stage, the discovery of the system wasn’t completed, so we pushed the final choice of the mission later in time, so as to  match the complexity with our mastering.

h2. Final choice

p. The final choice of the mission was made considering the time left that was relatively small when considering the complexity of retrieving pictures from a camera. That's why we chose to implement a thermocouple to retrieve the temperature.