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.
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.
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.
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
Type |
Design |
Description |
The beacon hardware shall not require maintenance. |
Rationale |
It must be assumed that beacon hardware cannot be repaired while in orbit. |
Type |
Design |
Description |
The beacon software shall not require maintenance. |
Rationale |
It must be assumed that beacon software cannot be updated while in orbit. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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). |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |