Technical requirements » History » Version 18

PRIETO, Matías, 12/15/2014 08:46 PM

1 1 PRIETO, Matías
h1. Technical requirements
2 2 PRIETO, Matías
3 18 PRIETO, Matías
The following technical requirements analysis is mainly based on the recommendations presented by the NASA, in the book _“NASA Systems Engineering Handbook”, Revision 3_.[1]
4 17 PRIETO, Matías
5 8 PRIETO, Matías
{{>toc}}
6 8 PRIETO, Matías
7 2 PRIETO, Matías
h2. Functional requirements
8 2 PRIETO, Matías
9 2 PRIETO, Matías
Functional requirements define what functions need to be done to accomplish the objectives of the mission. In this way, the following requirements are defined: 
10 2 PRIETO, Matías
* The satellite shall send one RF beacon regularly with a period time equal to 60 seconds = 1 minute.
11 2 PRIETO, Matías
* The satellite may send its GPS coordinates information inside the beacon frame.
12 2 PRIETO, Matías
* The satellite may send system state information (like temperature) inside the beacon frame.
13 2 PRIETO, Matías
* A ground station situated at the Télécom SatLab (Toulouse, France) shall be inside the satellite footprint at least twice a day.
14 2 PRIETO, Matías
15 2 PRIETO, Matías
h2. Performance requirements
16 2 PRIETO, Matías
17 2 PRIETO, Matías
Performance requirements define how well the system needs to perform the functions previously defined. Also they determine quantitative parameters that will set bases for the later technical measures specification. These concepts lead us to the performance requirements shown below:
18 2 PRIETO, Matías
* The beacon signal shall comply RTTY specifications.
19 2 PRIETO, Matías
* The communication time with the ground station shall be long enough in order to assure that one complete beacon frame can be received.
20 9 PRIETO, Matías
* The RF emitter device may be implemented with the low cost, 434 MHz, 2-FSK transmitter, available at the lab. Product information: Aurel, file:TX_4MAVPF10.pdf
21 2 PRIETO, Matías
* If on board GPS reception is implemented, the device shall be accurate enough in order to assure, for each coordinate (latitude, longitude and attitude), an absolute error smaller than 50 m.
22 2 PRIETO, Matías
23 2 PRIETO, Matías
h2. Interface requirements
24 2 PRIETO, Matías
25 3 PRIETO, Matías
Once the system components are defined, a block diagram showing the main subsystems, their interconnections, and the external interfaces is a powerful tool to define the interfaces and interactions. By this way, the nodes represent each subsystem and the links represent each interface. There are two types of interfaces, internal and external. The internal interfaces are the links representing the interactions between all the subsystems. By the other hand, the external interfaces are the links representing the interactions between the main system and the rest of the world, outside the product boundaries. There are different types of interfaces: mechanical, electrical, data protocol, etc.
26 1 PRIETO, Matías
27 14 PRIETO, Matías
h3. System/subsystems interactions blocks diagram
28 1 PRIETO, Matías
29 14 PRIETO, Matías
p=. !{width: 70%}sys_interfaces.png!
30 14 PRIETO, Matías
_Figure showing the main system/subsystem interactions and interfaces_
31 14 PRIETO, Matías
32 5 PRIETO, Matías
The interface requirements are the set of specifications that both linked nodes need to meet in order to have a proper and coherent system behaviour and interactions. Thus, the next interface requirements are identified:
33 5 PRIETO, Matías
* Interface Launcher - Satellite (L1).
34 5 PRIETO, Matías
Type: Mechanical.
35 15 PRIETO, Matías
Since the nanosatellite is based on a Pumpkin Cubesat 2U module. Therefore it has to be compliant with CubeSat mechanical specifications.
36 5 PRIETO, Matías
37 5 PRIETO, Matías
* Interface Processor - Power supply (L2).
38 5 PRIETO, Matías
Type: Electrical.
39 5 PRIETO, Matías
The power supply shall feed the processor with a DC source. Voltage: +5V. Typical operating current: 0.5 mA.
40 5 PRIETO, Matías
A +3V backup battery shall be used.
41 5 PRIETO, Matías
*The other Power supply - Subsystem links shall be defined in the same way.*
42 1 PRIETO, Matías
43 5 PRIETO, Matías
* Interface Processor - GPS receiver (L3).
44 5 PRIETO, Matías
Type: Electrical, logical, protocol.
45 14 PRIETO, Matías
If on-board GPS reception is implemented, it may be used a SPI bus between the receiver and the processor. The decision is linked to the external interface of the GPS module chosen.
46 5 PRIETO, Matías
47 5 PRIETO, Matías
* Interface Processor - Beacon transmitter (L4).
48 5 PRIETO, Matías
Type: Electrical, logical, protocol.
49 5 PRIETO, Matías
The communication shall be in serial mode. Baud rate between 50 and 300 bauds.
50 5 PRIETO, Matías
51 5 PRIETO, Matías
Other type of interface may be for instance the RF modulation between two terminals.
52 5 PRIETO, Matías
* Interface Beacon transmitter - Ground station.
53 5 PRIETO, Matías
Type: RF modulation
54 5 PRIETO, Matías
Defined by functional requirements. It shall be used a simple 2-FSK modulation to transmit data as a serial stream of bits complying with RTTY specifications.
55 5 PRIETO, Matías
56 5 PRIETO, Matías
For the scope of this project, there is no need of further interfaces analysis. Obviously, all the inter-system connections shall be designed to be compatible for both linked subsystems.
57 5 PRIETO, Matías
58 5 PRIETO, Matías
h2. Environmental, reliability and safety requirements
59 5 PRIETO, Matías
60 5 PRIETO, Matías
Functional, performance and interface requirements are important but they don't constitute the whole set of requirements for the mission. For instance, there are several other particular constraints for space segment systems. These constraints are environmental requirements, reliability requirements (robustness, failure tolerance, redundancy, etc.) and safety requirements.
61 5 PRIETO, Matías
62 5 PRIETO, Matías
h3. Environmental requirements
63 5 PRIETO, Matías
64 5 PRIETO, Matías
A complete study of environmental requirements are out of the scope of this project. Nevertheless, it can be introduced the main idea.
65 13 PRIETO, Matías
66 6 PRIETO, Matías
Each space mission has a group of environmental requirements that apply to the flight segment elements. In order to specify these requirements, different factors should be considered, such as EMI/EMC, grounding, radiation, shielding and contamination protection. Here EMI stands for Electromagnetic Interference and EMC stands for Electromagnetic Compatibility.
67 1 PRIETO, Matías
68 13 PRIETO, Matías
p=. !{width: 40%}Environmental_reqs.png!
69 13 PRIETO, Matías
_Figure showing the main factors linked to environmental requirements_
70 1 PRIETO, Matías
71 6 PRIETO, Matías
Once all the requirements are identified, then it should be defined the corresponding margins and design criteria to compensate them.
72 6 PRIETO, Matías
73 6 PRIETO, Matías
h3. Reliability requirements
74 6 PRIETO, Matías
75 5 PRIETO, Matías
Reliability can be defined as the probability that a system will not fail for a given period of time under specified operating conditions. This is an inherent system design characteristic. Therefore, it is needed to specify all the system and subsystems requirements in order to ensure that they can perform properly their tasks and can handle a certain number of errors and failures. Reliability addresses design and verifications to meet the requested operational level as well as failure tolerance for the defined working conditions.
76 7 PRIETO, Matías
Additionally, a brief analysis of the operational lifetime over CubeSat projects will be helpful to well define the reliability requirements and the critical design criteria which are related.
77 1 PRIETO, Matías
78 9 PRIETO, Matías
79 1 PRIETO, Matías
h2. Subsystems functional and performance requirements
80 16 PRIETO, Matías
81 16 PRIETO, Matías
Once defined all the high level system requirements, such us the previously presented requirements: functional, performance, interface, etc., it is possible to derive the corresponding lower level subsystem requirements. These would be functional and performance specifications that the subsystem shall comply in order to ensure the upper level system requirements are met.
82 16 PRIETO, Matías
83 16 PRIETO, Matías
p=. !{width: 50%}Reqs_flowdown.png!
84 16 PRIETO, Matías
_Figure showing the flowdown of requirements_
85 7 PRIETO, Matías
86 7 PRIETO, Matías
h3. Communication System
87 7 PRIETO, Matías
88 7 PRIETO, Matías
As defined in the mission objectives, the payload shall carry a beacon transmitter, it may transmit the GPS coordinates with a RTTY compliant communication chain.
89 7 PRIETO, Matías
The idea of using a satellite payload built over a radio amateur communication system is not strange. Many examples can be found in the literature of space missions. Even on the International Space Station (ISS), there is an amateur radio station.
90 7 PRIETO, Matías
But, why should it be implemented a radio amateur satellite? The reasons are simple, radio amateur bands are available to be occupied, the radio devices such as the transmitters and the receivers are commonly used for terrestrial communication, so they are affordable and well documented.
91 7 PRIETO, Matías
92 7 PRIETO, Matías
In our case, the choice of a low cost, low power, 434 MHz radio transmitter is determined by the mission specifications as a constraint. As a consequence, and taking into account the requirements for CubeSats with amateur radio payloads, it is needed a proof of frequency coordination by the International Amateur Radio Union (IARU).
93 7 PRIETO, Matías
94 7 PRIETO, Matías
As it was explained before, the definition of the transmission system main architecture, is highly linked to the availability of equipments and devices at the lab and the requirements of the mission. It was found that the most convenient implementation of the RTTY beacon is by using a simple 2-FSK RF transmitter, working on 433.92 MHz.
95 7 PRIETO, Matías
96 7 PRIETO, Matías
Functional and performance requirements for the communication subsystem:
97 7 PRIETO, Matías
* The on-board processor shall do the translation of the message to be transmitted into a digital signal, according to the Baudot code.
98 7 PRIETO, Matías
* The transmitter will be fed in its serial input with the translated bits stream.
99 7 PRIETO, Matías
* The transmitter will convert directly the bits stream into a 2-FSK signal.
100 7 PRIETO, Matías
* The carrier shifts will be +- 35 kHz. Which implies that there will be a modulation with non-standard carrier shifts. This is a normal condition as it was explained before. This modulation don't generate any issue.
101 7 PRIETO, Matías
* Baud rates shall be between 50 and 300 bauds.
102 7 PRIETO, Matías
103 7 PRIETO, Matías
The key points to understand the advantages of the transmitter are:
104 7 PRIETO, Matías
* Immediate availability
105 7 PRIETO, Matías
* Simplicity
106 7 PRIETO, Matías
* Affordability 
107 7 PRIETO, Matías
* Proof of appropriate spectrum and RF power characteristics
108 7 PRIETO, Matías
* Enough data rates capabilities
109 1 PRIETO, Matías
* Compliance with all the technical requirements and timelines planned for the project
110 1 PRIETO, Matías
111 8 PRIETO, Matías
The analysis of other subsystems like Attitude Control, Power Supply and Thermal Control are out of the scope of this project and are left for further projects.
112 8 PRIETO, Matías
113 12 PRIETO, Matías
h2. Summary
114 1 PRIETO, Matías
115 17 PRIETO, Matías
116 17 PRIETO, Matías
117 17 PRIETO, Matías
h2. References
118 17 PRIETO, Matías
119 17 PRIETO, Matías
[1] "NASA Systems Engineering Handbook":https://acc.dau.mil/adl/en-US/263346/file/40975/NASA-SP-2007-6105-Rev-1-Final-31Dec2007.pdf