Mission analysis » History » Version 10

DE GENDRE, Raphaëlle, 03/23/2016 04:01 PM

1 1 DE GENDRE, Raphaëlle
h1. Mission analysis
2 2 BASTIDE, Paul
3 9 BASTIDE, Paul
{{>toc}}
4 9 BASTIDE, Paul
5 7 BASTIDE, Paul
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.
6 6 BASTIDE, Paul
At the level of our project, we are going to stay do one passage, since the complexity is not that high.
7 2 BASTIDE, Paul
8 4 BASTIDE, Paul
p=. !{width:50%}System_Engineering_Engine.PNG!
9 4 BASTIDE, Paul
Figure : System Engineering Engine
10 4 BASTIDE, Paul
11 2 BASTIDE, Paul
h2(. Requirement definition Process
12 2 BASTIDE, Paul
13 2 BASTIDE, Paul
The first step we had to take was to define the mission from the stakeholder expectations and the technical requirements
14 2 BASTIDE, Paul
		
15 2 BASTIDE, Paul
h3((. Stakeholder Expectation Definition
16 2 BASTIDE, Paul
17 2 BASTIDE, Paul
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.
18 2 BASTIDE, Paul
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.
19 2 BASTIDE, Paul
20 2 BASTIDE, Paul
h3((. Technical Requirement definition
21 2 BASTIDE, Paul
22 2 BASTIDE, Paul
The mission we are to create has multiple constraints on technical aspects, due to the object of the experiment: 
23 2 BASTIDE, Paul
* We are to use the Cubesat Kit we have been provided, and the different equipment already included.
24 2 BASTIDE, Paul
* The mission has to include a transmission of data between the Cubesat and a receiver.
25 2 BASTIDE, Paul
* The mission has to include a sensor and its data to be retrieved
26 2 BASTIDE, Paul
* The complexity should be adequate to the time allocated to the project.
27 2 BASTIDE, Paul
* Small equipment can be ordered if the mission is accepted.
28 2 BASTIDE, Paul
29 7 BASTIDE, Paul
h2. Technical solution Definition Processes
30 2 BASTIDE, Paul
31 7 BASTIDE, Paul
h3.   Logical Decomposition
32 2 BASTIDE, Paul
33 7 BASTIDE, Paul
For this part please refer to the [[Work description]] realised at the beginning of our work.
34 2 BASTIDE, Paul
35 7 BASTIDE, Paul
h3.   Design Solution Definition
36 2 BASTIDE, Paul
37 2 BASTIDE, Paul
As per the work description above, we need to determine which mission we are going to undertake.
38 2 BASTIDE, Paul
We planned that part after getting to a relative understanding and mastering of the different equipment and software belonging to the Cubesat Kit.
39 3 BASTIDE, Paul
40 1 DE GENDRE, Raphaëlle
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:
41 3 BASTIDE, Paul
* Reading the temperature: using a thermocouple to retrieve the external temperature of the Cubesat and send it back on Earth.
42 3 BASTIDE, Paul
* 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. 
43 7 BASTIDE, Paul
* 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.
44 3 BASTIDE, Paul
* Retrieving pictures: installing a small camera on the Cubesat to send back pictures periodically to be stored and processed on Earth.
45 3 BASTIDE, Paul
46 7 BASTIDE, Paul
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:
47 3 BASTIDE, Paul
* 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.
48 3 BASTIDE, Paul
* Retrieving the temperature is a feasible task, and a common sensor used for that could be a thermocouple.
49 7 BASTIDE, Paul
* 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.
50 3 BASTIDE, Paul
* The hygrometry was dismissed nearly instantly.
51 3 BASTIDE, Paul
* 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.
52 3 BASTIDE, Paul
53 3 BASTIDE, Paul
54 7 BASTIDE, Paul
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.
55 1 DE GENDRE, Raphaëlle
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.
56 8 BASTIDE, Paul
57 8 BASTIDE, Paul
h2. Final choice
58 8 BASTIDE, Paul
59 10 DE GENDRE, Raphaëlle
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.