Requirements

High-level system requirements for SIDLOC are identified based on specified use cases and stakeholders’ input. The list of requirements is necessary in order to provide implementers a clear view and understanding of the system under development as well as defining standard interfaces for users of the system.

Management and Tracking

SIDLOC requirements are managed on GitLab under SIDLOC Requirements project. Each requirement is filed as a GitLab issue, with the Requirements label attached. Additional labels shall also be attached based on the requirement types that are applicable to it. A Requirement issue template is available for creating requirement issues conveniently and consistently. A requirement shall always relate to one or more use cases by linked GitLab issues, with the exception of design-only requirements. This use cases - requirement relations are used for origin tracking and quality assurance.

Specification Document

The System Requirements Specification is maintained as a LaTeX document. The document is authored under SIDLOC Overleaf project and mirrored to GitLab where it is rendered into a PDF file using GitLab CI. The list of requirements contained in the document is populated directly from GitLab issues using the GitLab API. Addition, deletion or modification of any issue, automatically triggers the re-rendering of the PDF file.

Releases

List of Requirements

ID REQ-16 - Compliance with radio regulations
Type Communications, Regulatory
Description Any usage of RF spectrum shall comply with the Radio Regulations. Usage of RF spectrum may be justified under Art 4.4 of the International Telecommunications Union Radio Regulations.
Rationale Due to the universal adoption goal and worldwide envisioned deployment and operation, any proposed technology shall make sure to adhere to the international set regulations (ITU RRs) for its spectrum usage. That adherence will greatly enhance the chances for wider adoption and friction-less operation.
ID REQ-17 - Identification and localization on a global scale
Type Operational, Communications
Description Identification and localization shall be possible at least once per orbit at any possible LEO orbital configuration. Mesh type network or data relay functionality implemented by technology and/or specified through the standard solutions may be considered.
Rationale Since ground station reception may not be available at some location, nearby spacecraft may be used for relaying information. Mesh type network or data relay functionality could mitigate loss of coverage or expand the spatial operational capabilities of the technology.
ID REQ-18 - Concurrent identification of multiple spacecraft
Type Communications, Performance, Operational
Description The system shall be able to concurrently identify at least 20 different spacecraft, at the RF level, assuming that these spacecraft are located within the receiving field of view of a ground station and no limits exist on the processing capabilities of it.
Rationale During the deployment the carrier may release multiple spacecrafts that should be identifiable right after their release. In addition, it is expected that the number of spacecrafts will increase drastically in the next decades. Therefore the field of view of a specific ground station will gradually contain an increased number of spacecrafts.
ID REQ-21 - Dimensions of beacon hardware
Type Interface
Description The beacon hardware in stowed configuration shall occupy less than 5cm x 5cm x 4cm on the surface of any spacecraft.
Rationale The beacon hardware shall fit within the PocketQube dimensions standard.
ID REQ-23 - Uniqueness of identification
Type Functional
Description The identification provided by the proposed technology should be unique among all different spacecrafts.
Rationale Any technology solution should provide unique identification due to the operational environment of swarm (multiple spacecraft) launches at the same time, and the need to have unambiguous identification.
ID REQ-24 - Automated localisation and orbit determination of spacecraft
Type Operational, Communications
Description The standard may provide unattended and automated localisation and orbit determination capabilities, using the extrapolated Doppler shift measurements.
Rationale The pre-launch TLEs have proven to be inadequate for early communication establishment with a spacecraft. These TLE sets usually become quickly (from some hours to some days) obsolete and inaccurate. In addition, only NORAD distributes TLEs that are periodically updated.
ID REQ-25 - Uniqueness of localization
Type Functional
Description The localization provided by the proposed technology should be unique among all different spacecrafts.
Rationale Any technology solution should provide unique localization due to the operational environment of swarm (multiple spacecraft) launches at the same time, and the need to have unambiguous localization.
ID REQ-26 - Concurrent localization of multiple spacecraft
Type Operational, Communications, Performance
Description The system shall be able to concurrently localize at least 20 different spacecraft, at the RF level, assuming that these spacecraft are located within the receiving field of view of a ground station and no limits exist on the processing capabilities of it.
Rationale During the deployment the carrier may release multiple spacecraft. Pre-launch TLEs may be inadequate for tracking, especially in cases that the deployed spacecrafts dimensions and masses vary. In addition, due to the large number of spacecrafts, which is expected to significantly increase in the next decades, the ground station field of view may contain several beacon transmissions that should be tracked concurrently.
ID REQ-31 - Availability of beacon hardware components
Type Design
Description Beacon hardware design shall not be based on EOL components.
Rationale The critical components must be available in order to support the design for long time.
ID REQ-33 - Spectrum utilization of beacon transmission
Type Communications, Regulatory
Description The spectral masks of the beacon shall not exceed the emission limits defined in SFCG 21-2R4.
Rationale The beacon shall make proper use of the spectrum and coexist with other beacons and spacecraft transmissions. It shall also use the most bandwidth efficient modulation schemes practicable for its missions.
ID REQ-44 - Compatibility between beacon and SatNOGS ground station network
Type Design
Description The design of beacon shall be compatible with the SatNOGS network of ground stations.
Rationale A dense network of ground stations increases operational reliability.
ID REQ-46 - Maintainability of beacon hardware
Type Design
Description The beacon hardware shall not require maintenance.
Rationale It must be assumed that beacon hardware cannot be repaired while in orbit.
ID REQ-47 - Maintainability of beacon software
Type Design
Description The beacon software shall not require maintenance.
Rationale It must be assumed that beacon software cannot be updated while in orbit.
ID REQ-48 - Limitation of transmission bandwidth
Type Communications, Regulatory
Description The transmission bandwidth of the beacon shall not exceed 4 MHz. The usable bandwidth of the beacon transmission shall also be limited to the individual allocations as specified by CEPT Frequency Allocations (2019).
Rationale The available bandwidth at the UHF band is quite limited. The occupied bandwidth of the beacon transmission should be as restricted as possible to minimize the impact to and from other spectrum users. This requirement also makes it easier for any regulatory recommendations, submissions to RR Board and resolution proposals, since it will not require additional changes to the band and allocation specifications per their frequencies.
ID REQ-49 - Accuracy of frequency offset estimation
Type Communications, Performance
Description The Doppler frequency offset estimation that is used for the spacecraft localization should have an accuracy better than 1 kHz, assuming no frequency offset in the ground station.
Rationale In order the system to provide a reliable spacecraft position, the standard should provide the necessary mechanisms for a fine frequency offset estimation.
ID REQ-50 - Stability of reference clock frequency
Type Performance
Description The frequency of the reference clock shall not vary more than +-20 Hz.
Rationale Using a more stable and accurate system reference clock improves the accuracy of the system to estimate the doppler induced frequency offset.
ID REQ-51 - Modulation of passband transmission
Type Communications
Description The passband transmission of the beacon shall be DS-CDMA (Direct-Sequence Code Division Multiple Access).
Rationale The localization and identification system should support multiple concurrent transmissions, while keeping the interference to other systems as low as possible. It should be able also to deal with interference from other unattended transmissions of other system too.
ID REQ-52 - Limitation of user bitrate
Type Communications, Performance
Description The user bitrate shall be 50bps or more.
Rationale Low bitrates increase the reception probability, but also increase the power consumption. In addition, low bitrates reduce the amount of beacons that may be received during a spacecraft pass at the ground station, affecting the performance of the frequency offset estimation that is used for the spacecraft localization.
ID REQ-53 - Limitation on orbit altitude
Type Communications, Operational
Description Identification and localization shall be functional at an orbit altitude of at least 800 km.
Rationale The ground station should be able to deal with a path loss induced by an altitude of at least 800 km. Higher altitudes may require modifications on the ground station and/or the beacon itself. Localization performance may also be affected on higher orbits, due to the reduced granularity of the Doppler frequency shift estimation mechanism.
ID REQ-54 - Limitation of power flux density at the Earth's surface
Type Regulatory
Description The beacon transmission shall fulfill the ITU Regulations for maximum power flux density on the surface of Earth.
Rationale The maximum power flux density regulations affects the selection of EIRP and bandwidth of beacon transmission.
ID REQ-55 - Management of spectrum multiple access codes
Type Communications, Operational
Description The DS-CDMA spreading and seed codes of the different spacecrafts shall be managed and regulated by a regulatory authority.
Rationale In order to take the full advantage of the DSSS, each spacecraft shall be configured with different spreading codes and initial seeds on the spreading polynomials. The spreading sequences shall provide good cross-correlation properties to enhance the uniqueness of the identification. A regulatory authority shall manage these codes and initial seeds, to avoid conflicts in the identification process. Due to the finite number of such codes, the authority may re-assign spreading codes to spacecrafts that are on different orbits, with low probability of being at the same field of view of a ground station.
ID REQ-56 - Detection of beacon short-circuit and latch-up failures
Type Design
Description Power supply shall be monitored to detect short-circuit and latch-up failures.
Rationale Power monitor shall be used in order to supervise critical components to protect the host spacecraft.
ID REQ-57 - Communication of beacon hardware with spacecraft bus
Type Interface
Description Beacon shall be able to communicate with bus via CANBUS. Beacon shall be able to tap unobtrusively on bus serial communication lines to receive bus data. It shall be possible for the spacecraft bus to command the beacon hardware to inhibit transmission (#94, #95) via an interface.
Rationale Beacon can utilize bus information to augment position and orbit determination. Beacon may connect to bus via CAN or by tapping on serial lines where bus information is transported. CAN was selected based on market research, literature review and prospective user feedback.
ID REQ-58 - Selection of beacon hardware components
Type Design
Description Beacon hardware shall be designed using commercial off-the-shelf components.
Rationale Use of COTS components reduces the cost of design, development and production compared to custom-made solutions.
ID REQ-59 - Detection of spacecraft deployment
Type Functional
Description The beacon hardware shall be able to detect spacecraft deployment.
Rationale The activation sequence of the beacon can only begin safely after the spacecraft has been deployed.
ID REQ-61 - Localization information on beacon transmission
Type Functional
Description It shall be possible for the beacon transmission to carry localization information. Localization information may be provided by the bus or the beacon hardware itself.
Rationale Localization, in terms of accuracy and time, can be improved by having localization information estimation directly available by the beacon transmission.
ID REQ-62 - Reliability of beacon software
Type Design
Description Beacon software implementation shall follow a set of quality assurance software development guidelines. Static code analysis and code style checking shall be used.
Rationale The beacon operation is considered critical thus the software shall be developed in a safe way and the behavior of it must be predictable in all cases.
ID REQ-63 - Power supply interface of beacon hardware
Type Interface
Description Direct or parasitic power (see #91 and #92) shall be supplied to the beacon hardware via bus interface.
Rationale An interface must be present when the beacon is not powered autonomously.
ID REQ-65 - Software interface for communication of beacon hardware with spacecraft bus
Type Interface
Description A software interface shall be available for communication of beacon hardware with spacecraft bus. The interface shall allow retrieval of positional data from bus. It shall also allow retrieval of spacecraft bus status.
Rationale Positional data available on the bus can be utilized to enhance beacon operation. Health data available on the bus can be used for rudimentary health reporting. Communication protocols such as UAVCAN and CANopen can be used.
ID REQ-66 - Limitation of beacon hardware power consumption
Type Performance
Description Beacon hardware power consumption shall be limited to allow sustained beacon transmitting on the specified transmission interval.
Rationale The power budget in all power supply method configuration shall be such that it does not impede the transmission of beacons on the specified interval required for successful localization and identification.
ID REQ-67 - Operational and non-operational temperature of beacon hardware
Type Performance
Description The operational temperature shall be -20°C to 75°C. The non-operational temperature shall be -30°C to 80°C. The beacon shall be able to operate within the range of the operational temperatures. It shall be able to operate after exposure to non-operational temperatures.
Rationale The operational and non-operational temperatures were used during component selection and when developing the thermal vacuum environmental test.
ID REQ-68 - Resistance to mechanical stress and vibration of beacon hardware
Type Performance
Description Beacon hardware shall be able to withstand mechanical stresses and vibration as described in the sine random quasi-static and shock tests of ECSS-E-ST-10-03C Claude 5.2 Table5‐1 without any damage.
Rationale The beacon hardware shall be able to withstand the mechanical stresses and vibration in witch is going to be exposed during the launch state.
ID REQ-70 - Mitigation of Single Event Effects (SEE)
Type Design
Description Beacon shall use error code correction memories to avoid catastrophic failure caused by single events effects.
Rationale Space harsh environment and long up-times increase the probability of SEE. MCUs, flash memory storage, caches and RAM should be error correction code (ECC) capable. Nevertheless, sporadic operation of the beacon can limit the window of opportunity for SEE to occur.
ID REQ-71 - Mechanical attachment of beacon hardware
Type Interface
Description The attachment mechanism shall not exceed a mounting surface of 5cm x 5cm (see #21).
Rationale Beacon hardware needs to be attached to spacecraft bus.
ID REQ-72 - Heat-dissipation interface of beacon hardware
Type Interface
Description The heat-dissipation interface shall not exceed the mechanical attachment surface (see #71).
Rationale Heat transfer in any direction is possible during operations (payload to bus or reverse).
ID REQ-73 - Supply voltage range
Type Interface
Description The beacon hardware shall operate nominally at any supply voltage level within the range of 3.3V to 14V.
Rationale This voltage range makes it compatible with commercial available electrical power systems.
ID REQ-74 - Limitation of received beacon transmissions by ground station network
Type Communications, Operational
Description Each ground segment shall require no more than three (3) beacons to be received on a single pass, in order to successfully identify and localize a spacecraft.
Rationale For identification and localization at least three beacons received per satellite pass per ground station are needed.
ID REQ-75 - Interval of beacon transmission
Type Communications, Operational
Description Transmission interval of beacon hardware shall be such that at least three (3) beacons shall be possible to be received per satellite pass by a single ground station.
Rationale For identification and localization we need at least three beacons received per satellite pass per ground station, this affects the transmission interval of the beacon hardware.
ID REQ-77 - Limitation of beacon hardware mass
Type Design
Description The mass of the beacon hardware shall not exceed 0.15kg.
Rationale It should be possible to integrate the beacon in a way which does not occupy a critical mass of the host spacecraft. The overall host spacecraft mass, including the mass of the beacon hardware should not exceed the mass limit defined in the PocketQube standard.
ID REQ-78 - Limitation of beacon transmission spurious and harmonic emissions
Type Communications, Performance, Regulatory
Description The total power contained in any single spurious emission and harmonic of beacon transmission shall not exceed -60 dBc at 4kHz measurement bandwidth with respect to CCSDS 401.0-B-29 and ECSS-E-ST-50-05C, Clause 5.5.
Rationale The beacon shall make proper use of the spectrum and coexist with other beacons and spacecraft transmissions.
ID REQ-79 - Qualification of beacon hardware components
Type Design
Description Beacon hardware should be designed using commercial off-the-shelf components with automotive AEC-Q100 qualifications.
Rationale Use components with AEC-Q100 qualifications increases the reliability of beacon hardware.
ID REQ-83 - Stability of ground station receiver oscillator
Type Performance
Description The oscillator stability of the ground station receiver shall be at most 1 PPB.
Rationale Reception of beacons from multiple stations that are synchronized improves calculations for localization and orbit determination. A GPSDO device can be used to provide such a stable frequency reference.
ID REQ-84 - Exclusive purpose of information transmitted by beacon
Type Regulatory
Description The beacon shall only convey information for the purpose of Identification, Localization and Space Traffic Management.
Rationale The system must be designed to serve only its intended purpose in order to minimize possible abuse.
ID REQ-87 - Accessibility of received and produced data
Type Operational
Description Received and produced data shall be accessible publicly. The data shall be available in CCSDS standard format. The data shall also be available in JSON format.
Rationale Several parties/actors are interested to access the received data from a satellite and the produced ones after data analysis.
ID REQ-88 - Detection of abnormal beacon transmission power output
Type Functional
Description It shall be possible to detect an abnormal transmission power output. The detection mechanism shall be implemented both in hardware and software.
Rationale It is assumed that beacon hardware may not be able to receive a remote shutdown command. Thus, in case of improper functioning, it shall be possible to mitigate the issue autonomously.
ID REQ-89 - Filtering of beacon hardware transmission
Type Design
Description The beacon hardware transmission shall be filtered to mitigate cases of abnormal transmission.
Rationale The beacon hardware transmission can fail either by excessive frequency drifting, unwanted spurious emissions or abnormal transmission in general. It is assumed that beacon hardware does not have any way to receive a remote shutdown command. Thus, in case of improper functioning, it shall be possible to mitigate the issue autonomously.
ID REQ-91 - Direct power supply of beacon hardware
Type Functional
Description It shall be possible to directly power the beacon hardware from the spacecraft bus.
Rationale Powering the beacon hardware from the bus allows placing within the spacecraft and can reduces the size of it.
ID REQ-92 - Parasitic power supply of beacon hardware
Type Functional
Description It shall be possible to power the beacon hardware by tapping on the spacecraft PVs.
Rationale Powering the beacon hardware from the PVs allows placing within the spacecraft and can reduces the size of it. It still however depends on the performance of them.
ID REQ-93 - Independent power supply of beacon hardware
Type Functional
Description It shall be possible to power the beacon hardware autonomously.
Rationale Autonomously powered beacons can be attached to non-powered objects. Such beacons can still operate even if the spacecraft is EOL. The power source can be solar cells and battery.
ID REQ-94 - TX inhibit of beacon hardware by spacecraft bus
Type Functional
Description It shall be possible for the beacon hardware to be commanded by the spacecraft bus to inhibit transmitting. The use of this interface shall be optional, based on the availability of the bus.
Rationale There can be regulatory and/or operational scenarios in which the bus must be capable of inhibiting beacon transmissions, especially in cases where a misbehaving beacon cannot mitigate the misbehavior autonomously.
ID REQ-95 - TX inhibit of beacon hardware by telecommand
Type Functional
Description It shall be possible for the beacon hardware to be commanded by telecommand to inhibit transmitting. The telecommand shall be authenticated by the beacon hardware.
Rationale There can be regulatory and/or operational scenarios in which inhibiting beacon transmissions must be done through a telecommand, especially in cases where a misbehaving beacon cannot mitigate the misbehavior autonomously. Since this telecommand is transmitted through an insecure medium, it must be authenticated by the beacon hardware by some means.
ID REQ-96 - Limitation of operational lifetime of beacon hardware
Type Operational, Regulatory
Description In case the beacon hardware is independently supplied power (#93) and has no means of inhibiting transmission (#94, #95), the operational lifetime of the beacon shall be limited through power supply energy depletion.
Rationale A misbehaving beacon can potentially cause harmful interference. If no means of inhibiting TX on such rogue beacons exists, then its operational lifetime can be limited by letting the battery deplete.
ID REQ-98 - Generation of space debris by beacon hardware
Type Regulatory
Description The beacon hardware shall not generate space debris in order to operate.
Rationale An antenna deployment mechanism using a heat wire (thermal knifes) can potentially release dangerous particles into space during or after antenna deployment.
ID REQ-101 - Deployment sensing interface of beacon hardware
Type Interface
Description The beacon hardware shall provide an electrical interface to identify whenever it is deployed.
Rationale Most of the launch providers dictate that any kind of transmissions should begin after the deployment of the spacecraft. The beacon shall be able to identify when it is deployed, so it can then start transmitting beacon frames.