Technical requirements¶

• Table of contents
• Technical requirements
  • Functional requirements
  • Performance requirements
  • Interface requirements
    • System/subsystems interactions blocks diagram
  • Environmental and reliability requirements
    • Environmental requirements
    • Reliability requirements
  • Subsystems functional and performance requirements
    • Communication System
    • Other subsystems
  • References

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]

Functional requirements¶

Functional requirements define what functions need to be done to accomplish the objectives of the mission. In this way, the following requirements are defined:

• The satellite shall send one RF beacon regularly with a period time equal to 60 seconds = 1 minute.
• The satellite may send its GPS coordinates information inside the beacon frame.
• The satellite may send system state information (like temperature) inside the beacon frame.
• A ground station situated at the Télécom SatLab (Toulouse, France) shall be inside the satellite footprint at least twice a day.

Performance requirements¶

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:

• The beacon signal shall comply RTTY specifications.
• The communication time with the ground station shall be long enough in order to assure that one complete beacon frame can be received.
• 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
• 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.

Interface requirements¶

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.

System/subsystems interactions blocks diagram¶

Figure showing the main system/subsystem interactions and interfaces

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:

• Interface Launcher - Satellite (L1).
  Type: Mechanical.
  Since the nanosatellite is based on a Pumpkin CubeSat 2U module, therefore it has to be compliant with CubeSat mechanical specifications.
  The CubeSat standard defines a complete set of technical requirements with mechanical, electrical and operational specifications. In the section Concept, it was introduced a list with the key points. More information is available from CubeSat Design Specification (REV 13). [2]

• Interface Processor - Power supply (L2).
  Type: Electrical.
  The power supply shall feed the processor with a DC source. Voltage: +5V. Typical operating current: 0.5 mA.
  A +3V backup battery shall be used.
  The other Power supply - Subsystem links shall be defined in the same way.

• Interface Processor - GPS receiver (L3).
  Type: Electrical, logical, protocol.
  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.

• Interface Processor - Beacon transmitter (L4).
  Type: Electrical, logical, protocol.
  The communication shall be in serial mode. Baud rate between 50 and 300 bauds.

Other type of interface may be for instance the RF modulation between two terminals.

• Interface Beacon transmitter - Ground station.
  Type: RF modulation
  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.

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.

Environmental and reliability requirements¶

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.

Environmental requirements¶

A complete study of environmental requirements are out of the scope of this project. Nevertheless, it can be introduced the main idea.

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.

Figure showing the main factors linked to environmental requirements

Once all the requirements are identified, then it should be defined the corresponding margins and design criteria to compensate them.

Reliability requirements¶

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.

For this project, it is found that:

• The major limitation in the CubeSat standard is its current lack of robustness and reliability. This aspect is even worse as the mission is set up for longer duration and higher orbital platform. For the scope of this project, the analysis of components reliability will be skipped.

• Regarding the download link performance, for the beacon transmission, the system may implement Forward Error Correction (FEC) techniques, such as Convolutional and/or RS channel encoding/decoding. The study of these aspects will be further completed during product design phases.

Subsystems functional and performance requirements¶

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.

Figure showing the flowdown of requirements

Communication System¶

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.
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.
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.

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).

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.

Functional and performance requirements for the communication subsystem:

• The on-board processor shall do the translation of the message to be transmitted into a digital signal, according to the Baudot code.
• The transmitter will be fed in its serial input with the translated bits stream.
• The transmitter will convert directly the bits stream into a 2-FSK signal.
• 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.
• Baud rates shall be between 50 and 300 bauds.

The key points to understand the advantages of the transmitter are:

• Immediate availability
• Simplicity
• Affordability
• Proof of appropriate spectrum and RF power characteristics
• Enough data rates capabilities
• Compliance with all the technical requirements and timelines planned for the project

The next step, as part of the product design phase, is to define the link budget, which will determine other lower level functional and performance requirements.

Other subsystems¶

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.

References¶

[1] NASA Systems Engineering Handbook
[2] CubeSat.org