1 Introduction

With new launches every year, and the use of 'mega-constellations' becoming commonplace, there is an increasing number of active satellites and other resident space objects (RSOs) in low Earth orbit. However, a collision between objects could be disastrous, having wide-ranging impacts on the collision orbit and all the satellites users within it.

The field of space traffic management (STM) is concerned with managing the orbits of resident space objects (RSOs) to avoid collisions and interference between them. This has become increasingly challenging in recent years due to the increase in RSOs in Earth orbit. In particular, the destruction of the Fengyun FY-1C satellite in 2007 during an anti-satellite missile test, and the collision between Kosmos 2251 and Iridium 33 in 2009, caused large increases in the debris population, with these incidents accounting for over 30% of all catalogued RSOs [1]. This evolution is evident, for example, from recent analyses performed by ESA [2].

If left unchecked, the RSO population will continue to grow, eventually reaching a critical mass beyond which Kessler Syndrome would occur, rendering orbits unusable [3].

This increasing congestion in orbit has become of great concern to space operators, with collisions no longer simply being a theoretical possibility. Driven by the risk to life posed by RSOs to manned platforms, such as the International Space Station (ISS), the US pioneered space surveillance network (SSN) provides the essential space situational awareness required to assure safe space operations. The SSN, taking some 420,000 observations per day [4], catalogues numerous objects and claims to have a near-complete database of RSOs down to 10 cm [5], with some coverage to 5 cm [6]. Once an RSO's orbit is characterised and is identified as a threat, the SSN can instruct the ISS to manoeuvre into a safe orbit [5], thereby allowing the SSN to provide a degree of collision forecasting. This represents the current state-of-the-art technology for RSO detection in low Earth orbit (LEO).

However, collision warnings are often ignored by satellite operators due to the impact upon the mission's lifetime that one or multiple collision avoidance manoeuvres would have [7]. This is affected by the warning tolerance, with a warning being triggered whenever the probability of collision is greater than 1 in 10,000 [8], meaning many warnings could be considered false alarms.

For private operators, their space situational awareness (SSA) must be obtained through other sources, such as subscription services to LeoLabs. However, the information provided by LeoLabs is focussed on tracking active satellites rather than cataloguing RSOs for collision avoidance [7]. Meanwhile, in Geostationary Earth orbit (GEO), the company ExoAnalytic is already providing operators with access to their own independent operational catalogue, which includes warning alerts for satellites, albeit for a hefty sum of around $1 million per month [9].

Space-based sensors have been introduced to support ground-based space surveillance networks [10,11,12], and they turned to be fundamental assets for current and future SSA programs [13, 14]. Space-based observations can guarantee better accuracies, versatile field of views and, most importantly, independence from day/night cycles and atmospheric weather conditions, when compared to ground-based optical observations [15].

The recent advances in the miniaturisation of space components and sensors, together with the enhancement of the computational capabilities of commercial-off-the-shelf (COTS) onboard computers, allow for the development of new SSA mission concepts that involve CubeSat platforms [16]. This is the case for mission concepts such as the Sapphire mission [12], or space-based telescope for actionable refinement of ephemeris (STARE) mission [17].

Following this trend, we propose a new mission concept that will improve temporal and spatial resolution of RSO orbit determinations compared to existing methods such as the SSN. Our concept is to produce a small-sat constellation for tracking of RSOs to increase the accuracy of collision warnings so that they can be more useful to spacecraft operators. This will be achieved using a distributed system of spacecraft to perform Orbit Refinement for Collision Avoidance (ORCA).

To make the mission financially viable, the design should use commercial off-the-shelf (COTS) components with a high technology readiness level (TRL), particularly CubeSat technology. The reduced cost from this will also act as an incentive for funding of the demonstrator satellite.

This paper will describe our design to verify the feasibility of the proposed mission concept. Mission areas such as its objectives, requirements, and business case will be defined in Sect. 2, followed by the mission's concept of operations (CONOPS) and architecture for the baseline mission (Sect. 3).

The payload, which is one of the key areas of innovation for this mission, will then be discussed in detail in Sect. 4. This will include the RSO detection strategy, the selection and specifications of the payload hardware and handling of the payload data.

The mission and constellation design will then be detailed in Sect. 5. This will describe how a CubeSat constellation will be used to achieve the mission objectives and why the particular design was chosen.

The CubeSat design section (Sect. 6) will give an overview of the design of the spacecraft's non-payload subsystems and how they have been designed to support the payload and mission architecture.

ORCA's cost budget will be discussed in the mission implementation section (Sect. 7) and will include a detailed breakdown of costs into categories such as hardware, licensing and insurance.

Finally, a series of final remarks and considerations will be presented in the conclusion section.

2 Mission Definition

2.1 Mission Objectives

The ORCA mission's main aim is to complement existing SSA systems such as the SSN by improving temporal and spatial resolution of RSO tracking within highly populated regions of LEO. In particular, the system will focus on the 800–1400 km altitude range. This will enable satellite operators to improve their SSA, with the resolution increases leading to more useful collision warnings that would be less likely to be ignored. In this way, ORCA would lead to more responsible use of space, avoid collisions between space users' assets.

2.2 Mission Requirements and Constraints

The development of the mission was driven by five main requirements:

  1. 1.

    The system shall detect RSOs as small as 300 cm3.

  2. 2.

    Global coverage of the 800–1400 km altitude band shall be achieved.

  3. 3.

    Within 6 h of a potential collision becoming known, relevant end-users shall receive state vectors for objects involved.

  4. 4.

    The platform shall use COTS technology to reduce cost.

  5. 5.

    The mission duration shall be at least 5 years.

Key constraints for the system were around cost and size. The team determined that a proof-of-concept demonstration mission should be achievable with a university's budget, with additional funding then used to implement the constellation. For the constellation to be economically viable, it had not to require an excessive number of satellites. While no particular number was set, this was borne in mind when designing the constellation. It was also decided that a CubeSat bus would be used as the spacecraft platform. This limited the volume and mass budgets as well as impacting the power budget, but the use of the CubeSat standard meant that cheaper COTS parts could be used, reducing the overall cost of the mission relative to a custom solution.

2.3 Users and Products

Once all satellites are deployed, and final operating capability (FOC) has been achieved, ORCA envisages two categories of users and their associated products:

  1. (a)

    Primary users: to guarantee the viability of the mission, the service provided is focused on the primary clients, satellite operators. The number of satellites that cross the region of interest is over 200 and will continue to grow with the introduction of megaconstellations such as OneWeb and Starlink. Satellite operators will be offered a continuous service after every collision warning occurred in the operative region, receiving updated ephemeris of the RSO and their own satellite if needed in time. Other potential users will be catalogue providers, which could receive updated information regarding each RSO analysed by the system. A riskier proposal is a pay-per-use model, charging operators per collision warning, although it is not considered in depth.

  2. (b)

    Secondary users: additionally, an archive service is planned which will provide the recorded state vector data of all tracked RSOs to institutions to use for further analysis. It is expected that academics and tertiary sector analysts will comprise of the secondary clients. Examples of such clients may include actuaries endeavouring to better qualify the likelihood of collisions for operators, which significantly impact insurance quotes [18]. These users would receive information on RSOs at a reduced rate, supplemented by primary user investment.

2.4 Stakeholders and Business Case

There are two possible stakeholders for the ORCA mission:

  1. 1.

    Governments of space-faring nations.

  2. 2.

    Commercial space operators.

2.4.1 Government Funding

As highlighted previously, space is becoming more congested with the frequency of RSO collisions set to only increase, especially in LEO. This puts government-backed space assets, which provide key services such as secure communications links and reconnaissance used by the military, at increased risk [18]. Such assets are of strategic importance, and governments are keen to safeguard them.

Encouraging a safer operating environment in space is in the government's interest. Economically, it is important to reassure investors that governments have a handle on the mounting "debris problem". Infrastructure projects such as ORCA are not always commercially attractive, with companies unwilling to pay the initial cost, despite the economic benefits in the medium to long term.

There is also geopolitical competition between space-faring nations. States may be willing to invest in space infrastructure to maintain "a stake" in space on the international field to maintain a level of dominance [19].

State investment could take the form of government subsidies for universities to fund and develop their own satellite to form part of the larger ORCA constellation. At a predicted cost of £250,000 per satellite, this is within the financial scope of relatively small government programmes and most moderately sized universities.

2.4.2 Commercial Funding

The dynamics of the space industry are changing. Over the last decade, private firms are no longer operating as contractors to state-owned space agencies but have themselves become key space actors [20]. Globally, the space economy has grown on average by 6.7% year on year between 2005 and 2017, almost twice the annual growth rate of the global economy [21]. Recent estimates put the value of the Space Economy at around $400 billion, with predictions of $1.1 trillion by the 2040s. This is obviously a sector with no shortage of funding. In Europe the privately-owned share of the space industry was estimated to account for 41% [22]. With such enormous investments in space assets, the threat of catastrophic collisions begins to make investments in SSA fiscally sensible. ORCA has the potential to fill this market gap by providing operators in LEO with much sought after SSA and improving on the SSN's catalogue.

Therefore, the project could be funded privately, potentially running as a subscription service similar to LeoLabs, which runs a commercial tracking service starting from $2500 per month [7].

3 Concept of Operations and Architecture

The ORCA mission will begin with a demonstration mission to prove the mission concept and technology feasibility. After this, the constellation will be established. This will involve several launches, with the CubeSats being deployed into two orbital planes, as discussed in Sect. 5. In-orbit testing will then be completed.

Once the satellites have been commissioned, the constellation will enter operational service. The satellites' default attitude will be to point their solar panels towards the Sun for battery charging.

Software on the ground will find potential collisions in the latest version of the SSN's catalogue and identify the RSOs involved. These will then be flagged as targets for ORCA. A constellation satellite that will be within visual range of a target RSO will then be reoriented so that the RSO will pass overhead through the payload's field of view. The CubeSats will maintain a constant attitude throughout the pass, removing the need for high slew rates.

As the RSO passes through the field of view, the ORCA satellite will take a series of images, showing the target in different positions in the frame. The satellite will then carry out the initial detection processing of these images as described in Sect. 4.2. The processed data will then be passed to the communications system and downlinked to the ground station at the next opportunity.

Ground processing will then determine the position of the RSO in each image. This will be used along with knowledge of the ORCA spacecraft attitude to determine the RSO's path through the frame, its speed and hence its orbit in terms of a state vector. The calculated state vector will then be passed to the RSO's operator or responsible party, who will use it to determine the likelihood of collision with the other RSO and whether to take action.

4 Payload

The utilisation of CubeSat technology, to limit the costs associated with the mission, represents one of the main drivers of the mission and, consequently, imposes strict requirements on the selection of payload and the detection strategies of RSOs. In the following subsections, the baseline configuration of the payload and a possible RSO detection algorithm are outlined, respectively.

4.1 Payload Selection and Design

A passive optical system has been selected to meet the mission requirements and, at the same time, to fit within the strict constraints on volume, power consumption, and weight imposed by the CubeSat standards.

A trade-off among Schmidt, two mirror Ritchey-Chrétien Cassegrain, Three Mirror, Newtonian, and Refracting telescopes, was made in order to select the best typology of telescope for this mission. The trade-off took into account key performance, such as the compactness of the folded configuration, complexity of the deploying system, as well as the intrinsic image quality achievable by such devices. The two-mirror Ritchey-Chrétien Cassegrain design, illustrated in Fig. 1, was selected because of its compactness in stowed configuration and simplicity of the deploying mechanism.

Fig. 1
figure 1

Telescope structure in stowed and deployed configuration

Full size image

The structure of the telescope is made of three carbon fibre cylinders nested when folded and released by a Pinpuller mechanism from RUAG [22]. Four small springs slow the motion of the moving cylinders during the deployment to protect mirrors and lens from shocks. An ad-hoc designed alignment mechanism can correct the position of mirrors and eventual misalignments due to temperature gradients or due to vibration during launch or flight. The mechanism uses two piezo-electric actuators from Cedrat Technologies [23] to finely correct the alignment of the primary mirror, and it operates along 2 axes. Such actuators require a specific control unit and have a mass \(180\,\mathrm{ g}\) for \(100\times 100\times 22\mathrm{ mm}\) dimensions. As a result, the overall size of the payload package is \(14\times 20\times 7\,\mathrm{ cm}\) when folded and \(40\times 20\times 7\,\mathrm{ cm}\) when deployed. The overall mass of the telescope is \(2.5\,\mathrm{ kg}\), including the deployment mechanism.

The telescope has an aperture of \(150\, \mathrm{mm}\) diameter and a focal length of \(350\,\mathrm{ mm}\), when fully deployed.

The image sensor is based on CMOS technology, which provides better performance than CCD sensors, in terms of cost and power consumption. The chosen model is the CHEETAH C4020 CMOS 8P by Imperx, that has a sensor resolution of \(4112\times 2176\,\mathrm{ pixels}\), with a pixel scale of \(3.45 \) μm [24]. The maximum frame rate is \(57\,\mathrm{ fps}\) and allows for multiple shots of the RSO when this is within the field of view of the telescope. The image sensor weights \(92\,\mathrm{ g}\), consumes \(2.4\,\mathrm{ W}\), and measures \(14.1 \times 7.5\times 25.4\,\mathrm{ mm}\).

The overall system (telescope + sensor) allows for a field of view (FoV) of 2.37° × 1.23° and a resolution of 2.03 arcsecond/pixel that guarantees an accuracy of 984 m at 1000 km range for a 5 cm diameter RSO that has a magnitude 12.9. This represents a reasonably good performance for the payload subsystem, which enables a feasible design of the overall constellation, as shown in Sect. 5. The maximum magnitude of the RSO object that is detectable by this system is 13.5.

4.2 Detection Strategy

The baseline configuration is built around a possible architecture of the RSO detection algorithm for the onboard elaboration of the images captured by the telescope. A trade-off was performed to select the most advantageous detection model based on the ORCA CubeSat hardware. The Global Motion Estimation method was considered but later de-selected since it presented a high processing power consumption and in return gave small accuracy improvements over the other methods [25]. The Background subtraction & AI method was selected instead because of the ease of implementation in-situ and promising results with potential for improvement [26].

This detection algorithm can work in two mutually exclusive modes, as shown in Fig. 2. In the telecommand mode, the cubesat receives from the ground station a set of pre-scheduled instructions to reorient the telescope towards specific target pointing directions. Thus, the CubeSat can detect known RSOs and refine the estimation of their trajectories through onboard processing of the data from the telescope. In the autonomous mode, no telecommand is received from the ground station, and the CubeSat autonomously reorients itself towards a region with a high concentration of RSOs. This mode requires that a pre-trained convolutional neural network (CNN) detects, recognises and matches the stellar background in the images taken by the camera with a pre-installed dataset. In this way, the algorithm can reconstruct the actual orientation of the telescope, and it will inform the subsequent steps in the detection.

Fig. 2
figure 2

Structure of the detection strategy algorithm

Full size image

Once the stellar background is identified, the operation of stellar subtraction is performed in order to eliminate the stellar background of the matched star dataset from the captured images. Then, the superimposition of all the subtracted images into one is performed to yield a trail of dots which represent the motion history of the RSO in the image plane.

It is worth pointing out that a perfect stellar subtraction is unlikely, due to possible inaccuracies of the telescope, noise of the sensor, mismatching of images and errors due to astronomical parallax. The discrepancies between the frames taken by the CubeSat and the onboard dataset of images will result in additional noise in the resulting image. Such noise can compromise the correct estimation of the trajectory of the debris, and further processing is implemented onboard to mitigate this problem. One of the processes entails building a detailed feature map of the strongest activations caused by the CNN during the detection and increasing the number of epochs to maximise the accuracy.

4.3 Payload Data Handling

The baseline configuration considers that the CubeSat is controlled by only one central computer. Such a subsystem is in charge of all satellite tasks, although the processing of the payload data represents the most demanding one. Indeed, the elaboration of the housekeeping data affects only for a low fraction of the overall data flow budget the throughput of the system. Thus, the baseline assumes that the same computer can handle both operations, albeit with two separate data buses.

The flowchart representing the path followed by the payload data is illustrated in Fig. 3, outlining inputs and outputs of the OBDH subsystem. Specifically, the data generated from the Payload subsystem has been estimated:

  • Raw data from the payload CMOS camera to the onboard computer: 268 MB. This is the max data which can be generated since a limit of 20 frames has been imposed for each detection event and a margin of 20%.

  • Processed data sent from the onboard computer to the comms for downlink each time an RSO is detected and tracked: 13 MB This value is significantly lower because the unprocessed data is expected to decrease by a factor of 10 after being subject to the detection algorithm and image processing. A 2:1 lossless compression is also performed.

Fig. 3
figure 3

Payload data flowchart

Full size image

A proto-version of the detection algorithm, performing the basic operations illustrated in Fig. 2, was developed and tested on a PC. The outcomes of the benchmark showed that the required RAM to implement the CNN and the stellar subtraction was 263 MB and 118 MB, respectively. Such characteristics, which included margin, represent a first educated guess of the required performance for selecting the onboard computer of the CubeSat.

5 Mission and Constellation Design

5.1 Orbit Selection

The orbit selection was primarily driven by the population density of various orbits. The constellation should target the most highly populated orbits that are most at risk of having collisions between local RSOs. The highest spatial density occurs in LEO at an altitude of around 800 km, with a further peak around 1400 km altitude (Fig. 4). Zhang, Wang and Zhang have also identified the 1200–1400 km altitude region as having critical density [27, p. 13]. It was also important that this region could be characterised for any inclination or right ascension. This means that global scanning of the 800–1400 km region became a top-level mission requirement.

Fig. 4
figure 4

Spatial density for a range of orbit altitudes [1, pp. 6]

Full size image

The payload uses an optical sensor design (as described in Sect. 4.1), making illumination a key issue for orbit selection. A constant illumination environment is preferred and would also benefit the power and thermal designs, as it would remove any periodic variations in available power or heat flux. These considerations led to the selection of a Sun-synchronous orbit (SSO) as the orbit for the ORCA satellites.

The altitude of this orbit was also driven by illumination considerations. Pointing towards the Earth would greatly reduce the signal-to-noise ratio (SNR) of the light from the target RSO versus that received from the Earth. This would make detecting the RSO extremely challenging, if not impossible. For this reason, the orbit altitude was chosen as 750 km, just under the lower edge of the target region, allowing the ORCA satellites to point away from the Earth when imaging targets. This altitude also places the satellites close enough to the targets to enable detection while being sufficiently distant that they remain outside the highest density region, reducing the risk of collisions.

If the payload sensor were to point towards the Sun, it would be blinded and permanently damaged by the solar radiation focussed onto it by the telescope. This meant that avoiding Sun pointing was of critical importance to the Attitude and Orbit Control System (AOCS). When a model of the constellation was constructed in STK (Fig. 5), this pointing was considered, with a notch added to the payload's viewable region to show the region that cannot be viewed due to its pointing towards the Sun.

Fig. 5
figure 5

STK model of orbit and constellation design

Full size image

5.2 Constellation Design

After ORCA's orbit had been selected, this could be expanded into a wider constellation design. Firstly, the payload range was considered when evaluating how many satellites would be required in a single orbit to give coverage around the whole orbit. Given the payload range of \(1000 \,\mathrm{km}\), it was determined that 14 satellites were the minimum for a single orbital plane such that the sensor ranges of the satellites in both planes just overlapped. This assumed that the payload could be oriented to any attitude.

Given the sensor range of \(1000\, \mathrm{km}\) and the selected constellation altitude of \(750\,\mathrm{ km}\), the payload can determine state vectors for RSOs up to an altitude of \(1750\,\mathrm{ km}\). The requirement for the constellation to be in SSO means the orbital planes both have inclinations of \(98.39^\circ \).

One plane has a right ascension of the ascending node (RAAN) of \(52^\circ \) (red payload range hemispheres in Fig. 5) and the other has a RAAN of \(59.5^\circ \). The \(52^\circ \) plane has a local time of descending node of 06:00:000 HMS while the \(59.5^\circ \) plane has a local time of descending node of \(06:30:000\, \mathrm{HMS}\). The 7.5° RAAN difference was chosen so that the ranges of the payloads in the two planes just overlapped when at the point where the two orbits are furthest apart. This meant that the constellation's scanning region could be expanded relative to if a single orbital plane were used.

The blue hemisphere shows the location of the primary ground station at Cranfield University. The notches in the payload spheres of view show a region of forbidden pointing as this would point the payload towards the Sun, permanently blinding it.

To ensure the constellation can provide a continuous service in the event of a CubeSat failure, two active spare satellites will also be launched into each plane, giving \(16\) satellites per plane and a constellation total of \(32\). The spares will be located between the other satellites and on opposite sides of their plane relative to each other. The spares in one plane will also be phased by \(90^\circ \) relative to the spares in the other plane to give the best coverage. In the event of a satellite being lost, the closest spare will use its propulsion system to perform a phasing manoeuvre that will bring it into the failed satellite's position. The active spares will be operational continuously from launch like the other satellites to further ensure continuity of service and make maximum use of their hardware.

While the constellation cannot scan an RSO outside of its range, if part of the RSO's orbit lies within range, it is guaranteed to be detectable eventually. When modelling the constellation (Fig. 5), two example RSO orbits were used (shown in yellow) to determine that a state vector could be found at least approximately once per hour for any RSO in a circular orbit within sensor range.

A previous study shows that constellations with 18 satellites could achieve up to 93 object detections per hours with accuracies down to 32 m and better performance with an increasing number of satellites [16]. The nominal ORCA mission considers a constellation of 28 satellites and therefore it is expected that better performances can be achieved.

5.3 Launch

The aim of the launch is to position the constellation's satellites in their final orbits in a way that has minimum impact on the CubeSat subsystems. This is to avoid affecting the limited mass, volume and power budgets.

In order to position the satellites into the required orbit, two Firefly Alpha launch vehicles will be used [28]. Each Firefly will house two small launch orbital manoeuvring vehicle (SL-OMV) deployers, with each SL-OMV carrying eight ORCA CubeSats [29]. Therefore, one launch will deploy 16 satellites into a single orbit plane using two SL-OMVs. Two launches will be used to place the full constellation of 32 satellites into orbit, with each launch targeting a single orbital plane.

The SL-OMV's orbital manoeuvring capability is used to phase the satellites appropriately around their orbits, avoiding the need for a propulsion system on each CubeSat that would impact the mass, volume and power budgets. A propulsion system on each satellite would also add complexity to ground handling processes.

Similarly, a series of dedicated launches was chosen over rideshares because it enabled direct insertion to the desired orbital planes, with the SL-OMV’s Δv used to correct any insertion errors and space the satellites around the plane. As two specific orbital planes had been selected for the constellation, it was important that the satellites be injected into these orbits rather than the orbit of a primary customer as would be the case in a rideshare scenario. Several dedicated small satellite launch vehicles such as Firefly Alpha are currently under development, meaning that by the time ORCA is ready for launch, low cost dedicated launch services should be available using these vehicles.

5.4 Disposal

Each ORCA CubeSat will be fitted with a disposal subsystem to ensure it can comply with ESA End of Life (EOL) requirements [30], granting the sustainability of the protected LEO and GEO regions and avoiding the rejection of the mission [31]. To minimise the risk of generating space debris, the reliability of the whole satellite (and the disposal subsystem individually) has to be above 90% [32]. The reliability diminishes with the harsh environment (radiation, RSO impacts…). This level will be checked periodically with a Kaplan–Meier analysis of the housekeeping data [33]. Violation of this criterion would force an immediate de-orbit with ground confirmation (without if the risk of imminent explosion reaches a critical level), to avoid the generation of further space debris.

A simulation in STELA (semi-analytic tool for end of life analysis) [34] and DRAMA (debris risk assessment and mitigation analysis) [35] showed that to satisfy the requirement to de-orbit within 25 years, a mean cross-sectional area in the tumbling mode of at least 1.26 m2 is needed. From a selection of state-of-the-art alternatives, the RODEO (roll-out de-orbit) device from CTD (Composite Technology Development, Inc) was chosen [36], with the Roc Fall from ROCCOR as a back-up solution [37, 38].

Figure 6 shows the final configuration after the deployment of the two de-orbit devices on board, each with a boom length of 5 m, a cross-section (sails) of 0.15 m in height and depth. An uncontrolled re-entry can be performed as the COTS elements of the spacecraft are built following the design-for-demise strategy [39,40,41]. The survivability was simulated in DRAMA [42] to verify the safety of this EOL manoeuvre.

Fig. 6
figure 6

Satellite view after RODEO deployment with STELA Mean Area Tool

Full size image

6 CubeSat Design

6.1 Attitude and Orbit Control System (AOCS)

The payload imposes stringent pointing requirements on the overall AOCS subsystems performance. Indeed, a non-accurate pointing of the telescope could result on blurry images and, therefore, inaccurate orbit predictions of RSOs. Thus, two main requirements have been imposed for such a subsystem: (a) the attitude control shall provide attitude determination accuracies less than 4 arcseconds, (b) the pointing of the CubeSat shall be maintained within 0.1° tolerance. Components also need to satisfy CubeSat standards and are constrained by the spacecraft's mass, power and volume budgets.

To meet the 4 arcsecond requirement, it was necessary to employ a star tracker for attitude determination. It was decided to use the Star Tracker developed by KU Leuven [43]. This Star tracker provided the best performance at the lowest mass and power costs. A series of sun sensors (nanoSSOC-D60) were also employed, as they are cheap, very small and light [44]. Determination of the solar vector is important to ensure the payload is never pointing towards the Sun.

To fulfil the \(0.1\, \mathrm{deg}\) attitude control requirement, a three-axis control mechanism was deemed necessary. As Control Moment Gyroscopes (CMGs) were unfeasible for this mission due to high power and mass requirements, ORCA incorporated four Reaction Wheels for three-axis control and redundancy. The model used was the large CubeWheel produced by CubeSpace, as these provided a maximum torque of 2.3 m Nm and momentum storage of 30 mN ms [45]. To provide desaturation, a three-axis magnetorquer was added (ISIS iMTQ), which has a maximum dipole of 0.2 Am2 that also can be used for detumbling at the mission start [46].

A propulsion system is also necessary to perform the initial phasing and position acquisition along the nominal orbit as well as to control and reject orbital perturbations for the station-keeping of the satellites.

Orbital determination is obtained via the use of GPS; each Mission ORCA spacecraft carries a GPS receiver, capable of orbit determination with position and velocity accuracies of \(10\, \mathrm{m}\) and \(25\,\mathrm{ cm/s}\), respectively [47]. The orbit is maintained via the use of a pulsed plasma thruster (PPT) which can supply a specific impulse of \(650 \,\mathrm{s}\) [48]. Based upon preliminary calculations, the thruster will require 340 g of Teflon to provide orbit control for the entire duration of the mission, with a 20% safety margin.

6.2 Communication

To maximise the available data rate, the communications subsystem uses a dedicated S-band downlink for the payload data, while TT&C data uses a separate UHF link in parallel (for both uplink and downlink). The UHF link transmits continually as a beacon for tracking purposes and is used in SAFE mode as well. Link budgets for each link have been calculated. Table 1 features a simplified link budget for the S-band downlink, which is the most critical given that the link margin is much smaller than the UHF links.

Table 1 Link budget of the S-band downlink
Full size table

The S-band link (2200–2290 MHz) uses the GOMspace ANT2000 patch antenna [49] and an Endurosat S-band transmitter [50]. According to the link budget calculations, in the worst-case scenario during the contact with ground stations the link margin is 5 dB (Table 1).

The UHF link uses an ISIS UHF antenna system for 6 U/12 U CubeSats [51] and the Endurosat UHF transceiver II [52] that handles both the uplink (400–403 MHz) and the downlink (435–438 MHz). According to the link budget calculations, during their contact with the main ground station the link margins are 33 dB for the uplink and 106 dB for the downlink.

The main ground station selected for the communications links is the Cranfield University ground station. Whilst at present it only features VHF/UHF capabilities, an upgrade to S-band capabilities is suggested, and is deemed feasible before the mission's launch. For link budget purposes, the ground station was modelled after the ISIS VHF/UHF/S-band full ground station kit.

An STK simulation of the communications system design corroborated the calculations by giving link margins that were found to be within the same order of magnitude, confirming the results obtained. It also confirms that the S-band downlink can transmit up to 375 MB of payload data to the ground station per pass.

6.3 Power

The three main operation modes for the electrical power subsystem are shown in Fig. 7. During the sun acquisition mode the satellite points the solar panels towards the sun to collect the maximum amount of solar energy to re-charge the batteries. During the debris detection mode the satellite orients itself to point the camera point towards the target RSO. It is assumed that a slew manoeuvre of maximum 60 degrees can be performed in order to reorient the payload towards the RSOs from sun acquisition mode and return to it. The transmit & receive mode will have the same attitude as the sun detection mode but with both S and UHF radio switched on to download data and upload commands to/from the ground station. In addition to the three nominal modes, a safe mode will guarantee minimal consumes, sun-pointing attitude and UHF link with the ground station.

Fig. 7
figure 7

The cycles of three operation modes

Full size image

An estimation of the power required for each of the modes is given in Table 2, where specific information about the duty cycle and the sun-incidence angle is also provided. The sun-acquisition mode takes into account the possibility of using the pulse plasma thruster as part of the AOCS subsystem. Even then, the power consumption remains well below the limits of solar power input and battery reserves.

Table 2 Subsystem level power budget for each operation mode
Full size table

Given the orbital parameters of the mission, the satellite goes through eclipse periods, where the solar panels will be unable to provide a constant energy source, even during debris detection and antenna orientation phases. To guarantee the reliability of the system, and balance the peak and valley of power needed, the battery pack is necessary.

The actual baseline configuration uses GaAs multijunction solar panels manufactured by SpaceQuest [53] and 18,650 lithium-ion battery cells. The number of battery charge–discharge cycles for the nominal mission duration is about 2.7 × 104 cycles. Thus, depth of discharge of 10% has been assumed to maintain the batteries efficient for the entire mission lifetime [42]. The sizing of such elements took into account the specific demands of each mode and using a conservative worst-case scenario approach. As a result, the required solar panel area 0.26 m2 and can provide 35 W. The dimension of the panels is bigger than the largest face of the 12U CubeSat not allowing for a simple body-mounted configuration. A deploying mechanism has been designed (Sect. 6.8) so that solar panels can be then deployed from their folded configuration during the LEOP operations.

The lithium-ion battery-pack contains 32, 18650 battery cells for a total mass of 1.54 kg [43]. The control unit can use up to 8 channels MPPT to achieve a higher power input. The typical power inputs and outputs during the operation, are shown in Fig. 8. The battery energy level in an orbit at EOL is shown in Fig. 9.

Fig. 8
figure 8

Power input and output in EOL

Full size image
Fig. 9
figure 9

Battery energy at EOL

Full size image

6.4 Onboard Data Handling (OBDH)

Payload, communications subsystem, telemetry and health sensors impose different requirements in terms of priority of elaboration and data rates that need to be produced by the onboard computer.

ConOps state that the payload will be able to capture relevant images for the debris detection every half hour, with a measurement interval of 0.8 s. Given the resolution and frame rate of the camera, the expected data rate in such phases is 280 MB/s. Thus, a specific data bus (MDR26 connection) is required to connect the camera with the onboard computer.

After processing this raw data, the onboard computer gives as an output 13 MB of data per detection that needs be transmitted to the ground. Because the data can be stored in the S-band transmitter's internal memory, the computer can generate data at a pace that does not depend on the S-band antenna's transmission rate. It takes about 30 min to store 13 MB to the transmitter's memory.

The information packages of the transceiver have such a low data rate (2.4 kB/s) that the data bus can handle them without storing them in memory.

Data rates of other sensors and devices have been estimated according to Reference [45] (Table 3).

Table 3 Data budget
Full size table

A hybrid OBDH architecture was designed to address the specific data flow requirements imposed by the sensors and devices within the spacecraft. Figure 10 summarises the ports and protocols used along with their maximum data bit rate. It is worth noting that all the channels can handle the required data flow from the devices.

Fig. 10
figure 10

OBDH block diagram

Full size image

The chosen onboard computer is the NanoMind Z700 [54]. It has two cores which can run up to 800 MHz and a FPGA. It is designed for CubeSats, and is adequately shielded against LEO radiation. It can store up to 32 GB, so it offers a wide data storage margin for the mission needs.

The motherboard links the computer with the relevant hardware. In this case, the NanoDock SDR, from GomSpace, provides the computer with several ports for the data buses [55].

6.5 Configuration

The configuration of the spacecraft was driven by the requirements imposed by specific subsystems and components. Table 4 summarises the main pointing and location requirements of the satellite components.

Table 4 Component pointing and location requirements
Full size table

The following figures (Figs. 11, 12, 13) show the final design of the ORCA satellite. In order to fit the required solar panels within the 12U CubeSat frame, a deploying mechanism was used to fold them during launch. Figure 11 shows the folded and unfolded configuration of the panels. It is also worth noting that all panels are located in one side of the spacecraft, in order to maximise the solar input when deployed, and protecting the telescope from the sun light. Figure 12 and Fig. 13 show the distribution of subsystems within the 12U CubeSat structure, where the volume margin for the components is very limited.

Fig. 11
figure 11

Solar arrays unfolded and folded

Full size image
Fig. 12
figure 12

CubeSat configuration

Full size image
Fig. 13
figure 13

CubeSat configuration (second view)

Full size image

6.6 Thermal Control

The thermal subsystem design is centred around the requirement to constantly maintain equipment temperatures within their limits throughout the mission lifespan.

Thermal design for the ORCA satellite is driven by two main constraints: the low mass and power budgets available for the subsystem, and the limited TRL rating of 12 U CubeSat COTS thermal solutions. The analysis for the final model was carried out using ESATAN software and analytically validated with MATLAB. This model can be seen in Fig. 14, in which the Sun is on the left and the temperatures shown are the average over the course of an orbit.

Fig. 14
figure 14

Final thermal model (\(^\circ{\rm C} \))

Full size image

The surface coatings used are aluminium Kapton for the majority of the CubeSat's exterior and optical solar reflector (OSR) to form a heat dissipating surface that acts as a radiator. Thermal copper straps are used to conductively connect the heat dissipating equipment with this radiative area. Finally, two simple electrical heaters were added for the GPS receiver and battery unit.

The model results show that the solar panels shield the rest of the satellite from the highest temperatures due to the nominal attitude of the spacecraft. This translates to the most severe temperature gradients. The rest of the component's temperature is heavily influenced by their respective power dissipation values.

Table 5 shows an extract of the temperature range limits and results for the nominal operational mode with the relative margins for each component. It is demonstrated how with these predominantly passive thermal control solutions, the temperature requirement is verified for all worst-case scenarios studied.

Table 5 Operational temperature limits and results for the nominal operational mode
Full size table

6.7 Structures

The structural design was constrained by two factors: the availability of COTS structures and the requirement to survive the hazardous launch environment. The launch phase induces in the satellite a combination of quasi-static and frequency-dependent vibration loads which must be withstood by the structure to create a safe environment for the payload.

After performing a trade-off among existing COTS 12 U structures, the 12 U structure from Innovative Solutions in Space, made of aluminium 7075 T6, was selected. This structure was modified to accommodate internal equipment by adding two apertures, one on the top face of the structure to ensure payload deployment and another on one the side for the thruster nozzle exhaust. The final structure design is shown in Fig. 15.

Fig. 15
figure 15

Final structure design

Full size image

A finite element model was created in Patran-Nastran software to simulate the selected structure. Quasi-static inertial and random vibration analyses were performed to ensure the structure's ability to withstand the stresses and displacements caused these loads. A frequency analysis was also performed to ensure the resonance phenomena was not present during launch phase. Post-processing of the final results and requirements fulfilment validated the structure and the launch vehicle selected for the mission. The first 3 vibration modes are shown in Table 6, which comply the requirement of natural frequencies higher than those of the launcher (> 25 Hz) to avoid resonance phenomena. A visual representation of the first mode is shown in Fig. 16.

Table 6 Vibration modes
Full size table
Fig. 16
figure 16

Deformation and strain energy for the first vibration mode of the structure (\(48.90 Hz\))

Full size image

Inertial quasi-static loads produced by the launcher induce a maximum stress of 47.2 MPa, a security margin of 11.165, and a maximum displacement of \(1.7\, \mathrm{mm}\), which is acceptable according to the spacecraft dimensions. Random vibration analysis is simulated to measure the accelerations on the equipment, and stresses on the solar panels, the structure and the interface with the launcher under these loads. A RMS value of \(4.425\, \mathrm{g}\) is experienced in the telescope under these loads, experiencing higher peak accelerations for low frequency values as seen in Fig. 17. Stresses on the structure under these vibration loads raise to a higher value of \(26.9\,\mathrm{ MPa}\) while the maximum force in the launcher and spacecraft interface is \(208.91\,\mathrm{ N}\).

Fig. 17
figure 17

Overall peak acceleration in m/s2. Random vibration analysis, telescope

Full size image

6.8 Mechanisms

The size and shape limitations of the ORCA CubeSats require the use of deployable solar panels, which operate with an actuation mechanism and an initial release mechanism.

The baseline design assumes that torsion springs included in hinges will provide the elastic energy for actuating the solar panel deploying mechanism. Two torsion springs are used per hinge and two hinges are used per solar panel.

The carbon steel ASTM A228 Music wire is used for the springs as it provides the highest resistance among the available materials.

The solar panels are released by melting two nichrome burn wire release mechanisms with a 4 Amp current flowing through them after launch.

7 Mission Implementation

7.1 Mission Development Timeline

A timeline for the development of the ORCA system is shown in Fig. 18. This describes the milestones leading up to an ORCA demonstration mission for initial operating capability (IOC), followed by the deployment of the wider constellation for final operating capability (FOC). While the timeline outlines the steps required for future development of the mission, these would be dependent on funding being secured to take the mission beyond its current hypothetical state.

Fig. 18
figure 18

ORCA development roadmap

Full size image

7.2 Mass Budget

The mass budget is shown in Table 7. The mass budget was constrained by the SL-OMV deployer, which can carry a maximum of 20 kg per satellite, of which 18.74 kg has been used for the ORCA design. This also fits within the limit for a 12 U CubeSat of 24 kg [56].

Table 7 ORCA CubeSat mass budget
Full size table

Each subsystem was given an appropriate mass margin based on the maturity of its technologies. Due to the mass of the solar panels and batteries, the power subsystem makes up the largest proportion of the overall spacecraft mass, with the payload the second most massive due to the telescope and its structure.

7.3 Cost Budget

The constellation’s fixed and recurring costs, as of April 2020, are shown in Table 8.

Table 8 ORCA cost budget
Full size table

The desired annual income for a profitable mission is GBP 13.25 M so, in order to provide an affordable and sustainable service, it should be well received by the estimation of around 200 satellites that will be crossing the region of service of this system when in operation, plus the possible future mega-constellations, such as One Web.

8 Conclusion

Our proposed ORCA system has been designed to determine the orbit state vectors of RSOs to support existing systems such as the SSN by enabling more accurate collision predictions. This will improve space situational awareness and help avoid RSO collisions, safeguarding the orbital environment for future use.

It is essential to recall that this design is not the finished product and requires more detailed design iterations prior to CDR and subsequent mission fruition. Nonetheless, the completed research in each necessary subsystem for the mission has demonstrated the feasibility of the design, while fitting into a 12U CubeSat format, thereby providing a small and cost-effective solution.

During the course of this project, the administrative perspective, which enables the successful implementation of the project, has been considered. This has included the identification of potential clients and key stakeholders, thereby strengthening the financial viability of the project. Coupled with this, detailed study of the technical aspects has provided a suitable optical payload to achieve the mission and an ensemble of subsystems to complement it.