1 Introduction

Since the CubeSat standard was introduced in 1999 [1], over 400 CubeSats have been launched by the end of 2015. A CubeSat is a satellite with standardized mechanical interfaces for a launch interface adaptor and comprises one or more units of 10 cm × 10 cm × 10 cm. There have been several global surveys on CubeSats in the past looking at their mission characteristics, implemented technologies and overall success rates [2, 3]. A recent study shows that about 40 % of the launched CubeSats were not successful and provides some qualitative analysis on the failure causes with an emphasis on the development process [3]. It concludes with the recommendations to improve understanding of the failure sources and study technological capabilities to look for trends and prediction. The objective of this paper is to provide the results from a survey on the implementation and reliability of CubeSat data and power interfaces.

1.1 Motivation for the survey

Standardization of interfaces has been one of the key pillars of the increasing popularity of CubeSats in terms of missions [3] and commercially available subsystems. A standard for electrical interfaces allows for easy integration of subsystems from different suppliers. The CubeSat specification limits itself to external dimensions and interfaces with the launch adapter [4]. There is formally no standard specification for CubeSat electrical bus interfaces. However, the wiring harness of the PC/104 embedded systems standard [5] has been adopted in many CubeSats missions and commercially available CubeSat subsystems. Those using the PC/104 standard also widely implement the I2C data bus for communication between subsystems. The PC/104 standard in combination with the I2C data bus is currently being associated with the CubeSat standard. However, it was already discovered in an earlier study that this de-facto standard has been applied in a rather inconsistent manner leading to potential compatibility issues when integrating several commercially available subsystems [6]. Next to this compatibility issue, many issues with the I2C data bus interface were found throughout the development and operations of Delfi-C3 and Delfi-n3Xt [7], two successful satellites of TU Delft’s CubeSat program. A more extensive survey and investigation into the electrical bus interfaces is considered to be a good starting point for further investigation into reliability aspects of CubeSats, as such interfaces introduce requirements and constraints to all subsystems. Second, this survey is intended as a first step in a thorough analysis which can be used as input for the design of future CubeSats as well as the development of a new potential CubeSat standard which is reliable and fulfils the needs of future generations of CubeSats.

1.2 Survey approach

First, a literature survey has been performed. In the majority of the publications on flight results, however, specific issues are not provided and/or discussed in detail. Therefore, the survey was complemented with an extensive questionnaire sent to the global CubeSat community. This provides a statistical basis, while the literature survey supports and substantiates some of the findings. Further literature study is subsequently used to analyse the results and to draw conclusions.

1.3 Conclusions from other satellite surveys

The reliability of launched satellites has been investigated by several researchers worldwide. According to a study of 129 satellites of all classes [8], at least 45 % of all satellite failures can be allocated to electrical faults. The electrical power subsystem (EPS) is accountable for 27 % and Command and Data Handling (CDH) for 15 % of the failures encountered, which together have a major impact on reliability. Looking more closely to the electrical interfaces, only 5 % of the failures are allocated to the power bus and there is no specific mention of failures allocated to the data bus. Another study [9] focused on the EPS specifically using data of over a thousand spacecraft launched between 1990 and 2008. For Low Earth Orbit (LEO) satellites, which are the orbital regime of the vast majority of CubeSats, 29 % of the failures on the electrical power subsystem are allocated to the electrical distribution. Of these failures, 80 % is a fatal failure. The overall average failure rate of the EPS is, however, just 3.8 % for LEO satellites. These two studies do not confirm the substantial relevance of the electrical interfaces on the reliability of satellites, in general.

There has been a study on small satellite reliability which analyses the anomalies of subsystems of 222 satellites up to 500 kg [10]. This study provided reliability over operational lifetime. One of the conclusions is that satellites below 10 kg show a relatively high infant mortality rate and short lifetime compared with satellites between 10 kg and 500 kg. Telemetry, tracking and command (TT&C), the Thermal Control System (TCS), and the mechanisms and structures (M&S) contribute most to infant mortality, while the EPS contributes to the largest amount of failures overall [10].

In a statistical study on the first 100 launched CubeSats performed in 2013 [3], mission failures of CubeSats are analysed on a high level. One major conclusion is that a third of all failed missions were never contacted after launch. Another 27 % of the failures can be attributed to a configuration or interface failure between communication hardware and 14 % to the EPS [3]. This study does not specifically address the electrical interfaces.

From all past satellite surveys, it can be concluded that electrical interfaces have not been identified as a significant contributor to mission failures. However, as CubeSats are just a small and relatively recent subset of the small satellite surveys [810] and the CubeSat survey [3] only shows reliability figures on a high system level, initial concerns stated in Sect. 1.1 cannot be relieved without further study.

2 General survey statistics

First, the questionnaire is introduced in Sect. 2.1. Section 2.2 provides overall CubeSat reliability results used to investigate the relevance of the electrical interfaces in particular.

2.1 Questionnaire response and processing

On the 4th of November 2014, a questionnaire has been sent out to in total 987 personal and general email-addresses affiliated with all of the launched CubeSats and many CubeSats in development at that time. It has been decided and communicated that the results of the questionnaire are treated anonymously, as full public disclosure might otherwise prohibit or discourage participation for some. The questionnaire consisted roughly of three sections with a total of 33 questions. The first section addresses the general reliability aspects of the represented CubeSat, the second section addresses the reliability aspects of the bus interfaces of the same CubeSat, and the third section addresses the expert insight of overall failure rates and causes for CubeSats, in general. This paper focuses on the second section and uses part of the answers of the first section to provide a general context. Many questions have pre-defined multiple choice/selection answers as well as open boxes for alternatives and/or clarifications. Care is taken to avoid that the pre-defined options would bias the outcome and this has been verified by a small test panel which is not directly involved in this study. The questionnaire closed on the 1st of January 2015.

There were in total 138 participants of which 113 have fully completed the questionnaire. For 13 missions, there were multiple participants per CubeSat. In this case, the CubeSat-related answers are analysed and merged to a single answer. Wherever required, voting (for multiple choice questions with at least three participants), averaging (for numeric questions), or analysis (using publicly available information) have been applied to merge the answers. Following this process, there are answers on 60 launched CubeSats and 44 which are in the development or awaiting launch. In some cases, contradicting answers could not be merged into a single unbiased answer and those answers are excluded from further analysis. For some questions, the answers are unclear or skipped by the participant. In this paper, the total number of CubeSats which have been analysed for each question is provided with ‘n’.

The participation on 60 launched CubeSats is 24 % of the total CubeSats deployed into orbit up to end 2014 and 29 % if the 48 Flock CubeSats from Planet Labs deployed into orbit in 2014 are only counted as one satellite. In Fig. 1, the participation distributed over time is provided and can be compared with the totals that are successfully deployed into orbit each year. The coefficient of determination for this aspect is calculated to be R 2 = 0.76 (R 2 = 1 would yield a perfect sample distribution). However, with the 2014 Flock satellites only counted once, R 2 = 0.93. Likewise, for the organizational type (educational, civil, military, and commercial), R 2 = 0.59.

Fig. 1
figure 1

Survey response and total CubeSats successfully deployed into orbit, distributed over launch years

2.2 General CubeSat reliability

The participants have been requested to categorize their CubeSat mission objectives and provide success rates for each category. Of the 60 launched CubeSats, the provided mission objective categories are education (n = 49), technology demonstration (n = 51), science (n = 27), commercial (n = 3), civil (n = 4), military (n = 1), and radio amateur service (n = 2). For further investigation, science, commercial, civil, military, and radio amateur service objectives are grouped as ‘operational’ mission objectives (n = 32). The success rates are defined and ordered as unsuccessful, minor success, partial success, primary success, and full success. The results are provided in Figs. 2 and 3. They are split in the current status and the expected final status. In the current status, missions which are not completed are also included and the overall success rates can, therefore, be lower than what potentially can be achieved. The expected final status is the most likely result (as foreseen by the participant) taken the current status into account and the potential future achievements for ongoing missions. Many missions have multiple objectives in different categories. The combination of education and technology demonstration is very popular (n = 42), while there are 20 missions with objectives in all three categories and only 10 missions in a single category.

Fig. 2
figure 2

Current success rates of launched CubeSats for education (left, n = 49), technology demonstration (middle, n = 51), and operational mission (right, n = 32) objectives

Fig. 3
figure 3

Expected final success rates for launched CubeSats for education (left, n = 49), technology demonstration (middle, n = 51), and operational mission (right, n = 32) objectives

For the educational success, many teams consider the successful launch of their satellite and/or minimal operations as a success of the educational objective. For technology demonstration, a minimum functionality of the satellite in orbit is required and it can be clearly seen that the success rates are lower for this objective compared with education. The demonstrated systems might, however, still not have to work completely according to specifications. For operational missions instead, the satellite really needs to work according to specifications to have a full success. For these most demanding objectives, the success rates are even further down and a vast majority of those CubeSat missions do not fulfill this objective completely. Only for 28 % of all missions (n = 60), all objectives have been met so far. The expectation, as answered by the participants, is that 35 % will eventually achieve full success.

The root cause allocation to subsystems for not meeting one or more of the mission objectives with full success is investigated and its results are provided in Fig. 4. The point of reference is the expected final success rates from Fig. 3 and includes fully determined root causes as well as the main hypothesis.

Fig. 4
figure 4

Root cause allocation for not achieving full success for education (left, n = 7), technology demonstration (middle, n = 24), and operational mission (right, n = 19) objectives

The electrical bus interfaces, which are the main topic of this study, are typically functionally allocated to the EPS and CDHS. Only for a single case, a hypothesis is provided that the data bus has been the root cause of not meeting one of the mission objectives. The EPS problems are allocated to batteries, solar cell degradation, and electronic malfunctions at the central EPS. There is no hard evidence that electrical interfaces have contributed to the mission failures of past and ongoing missions. It should, however, be noted that catastrophic failures on the critical electrical interfaces may lead to a sudden loss of satellite operation, which complicates root cause analysis. In addition, operational failures may have occurred after the mission design lifetime. Issues on the electrical interfaces which are non-catastrophic may still complicate operations and/or degrade the potential mission return. The potential correlation with catastrophic failures and other issues and electrical bus interfaces is investigated further in the following sections.

The mission design lifetime for the launched CubeSats (n = 59) is up to 6 months for 41 %, between 8 months and a year for 42 % and the remaining 17 % more than 1 year. The average mission design lifetime is 11 months with a standard deviation of 9 months, a minimum of 1 month, and a maximum of 5 years.

Figure 5 provides the operational status after a selected set of months since launch. The total percentage gradually drops with lifetime, as not all CubeSats have been in orbit for so long. Of the 14 CubeSats (23 % of total) which have lost contact within 3 years, 12 CubeSats (20 % of total) have not been operational for their entire mission design lifetime. This partially explains why so many technical mission objectives have not been fully successful. The maximum reported fully operational status (including commanding capability) is 10 years and the average so far is 1.2 years.

Fig. 5
figure 5

Operational status of CubeSat missions after specified period since launch as of November 2014 (n = 60)

3 Survey on CubeSat data buses

In Sect. 3.1, the data buses implemented are discussed. The data bus reliability is discussed in Sects. 3.2.

3.1 Data Bus Implementation

In Fig. 6, the types of data interfaces that are implemented in the CubeSats between the main subsystems and/or main components are shown. The data buses are analysed only on the physical layer, which is layer 1 of the Open Systems Interconnection (OSI) model [11]. Local interfaces on a printed circuit board, for instance between a microcontroller and its peripherals, are not analysed. Multiple different data buses can be implemented on a single CubeSat: 22 % have two, 29 % three, and 4 % four (n = 82).

Fig. 6
figure 6

Implemented data buses in CubeSats

The most frequently employed bus is the Inter Integrated Circuit (I2C) bus. This is explained by the fact that many COTS integrated circuits have an internal I2C controller and it is implemented in the majority of the COTS CubeSat subsystems. I2C is a two-wire serial interface which connects two or more nodes in a master(s)-slave(s) configuration with typical data rates of 100 kbit/s for the standard mode and 400 kbit/s for a fast mode [12]. Practical experience has shown that a minimum clock frequency of 10 times the baud rate is needed for reliable operation within microcontrollers [7]. The maximum bus length depends on capacity, shielding, and additional buffering [12], but the protocol is designed for short distances and, in practical cases, is limited to several tens of centimeters (many nodes using stacked connectors) up to several meters (few nodes, good wiring conditions).

Serial Peripheral Interface (SPI) is also widely implemented in CubeSats. SPI is a four-wire full duplex serial interface which connects one master with one slave at a time [13]. One line is a slave select, which can be multiplied from the master to connect multiple slaves, and is a form of physical addressing. The data rates are not bound by modes and can be several orders higher than for I2C. However, the slave needs to handle the throughput of the master without the ability to stretch the clock as with I2C, otherwise the data can be lost. Similar to I2C, this bus is designed for short distances up to several meters in the favourable conditions.

Recommended Standard 232 (RS-232) scores about equal to SPI in implementation rate. RS-232 is a serial data interface between digital systems and is full duplex [14]. It cannot be connected or expanded to more than two nodes. Its raw data rates (including protocol overhead) are up to 20 kbit/s according to the standard. However, in current practice, non-standard 3-wire and 5-wire implementations up to 115.2 kbit/s are used. The standard is designed for distances up to 15 m [14].

The controller area network (CAN) bus has been implemented only in a few launched CubeSats, but is becoming more popular. CAN bus is developed for automotive applications and is designed to be able to operate in harsh environments. It is a serial bus with differential signalling and failure tolerance at OSI layer 1 is possible for this bus. Data rates are up to 1 Mbit/s. Cable connections can span a distance up to 40 m.

Universal serial bus (USB) shows a similar trend as the CAN bus. USB is the currently most popular standard to connect computers with peripheral equipment. It has several backwards compatible modes with the current fastest being SuperSpeed + (USB 3.1) which supports 10 Gbit/s of data rate [15] over 8 wires (full duplex). USB can only be used to connect one master to one slave, which can be extended using a hub.

Universal Asynchronous Receiver/Transmitter (UART) is no exclusive data bus, but a piece of (integrated) hardware to manage the link between a microprocessor and a serial data bus and includes RS-232 and RS-422. SpaceWire is the only data bus designed for space applications. It is, however, only implemented in one CubeSat which is still to be launched. In addition, wireless standards are not widely implemented yet.

3.2 Data bus reliability

The questionnaire addressed the reliability of the implemented data buses. To exclude immature designs and to have sufficient statistical input, only I2C, SPI, and RS-232 for launched CubeSats are analysed in this section. The results for the implemented failure tolerance features at OSI layer 1 [11] for each bus is presented in Fig. 7. Except for the optional error line for I2C, the three buses do not have inherent failure tolerance at OSI layer 1. This means that most failure tolerance features presented in Fig. 7 are designed and implemented by the CubeSat developers. Single-wire failure tolerance means that the bus is still operational if there is a fault on one line. This can lead to maintained performance (e.g., in case of full redundancy) or to degraded performance (e.g., going from differential signalling to single-ended signalling by lowering the maximum data rate).

Fig. 7
figure 7

Implementation of failure tolerance features in CubeSats for different data buses

It can be clearly seen from Fig. 7 that the majority of CubeSats have additional failure tolerance features implemented for the three different buses. Very popular are bus lockup protection and supplementary watchdog circuitry (these features may be overlapping). For SPI, there are also many failure tolerance features implemented, although significantly less than for I2C. For both buses, however, in about 30 % of the cases, there is not just a single serial bus connector to all subsystems. Instead, there are separated buses connected to (groups of) subsystems of the same bus type. Redundant wiring and buses are not implemented widely, potentially due to limited availability of microcontrollers and peripheral devices with dual I2C or SPI controller and the complexity of such solutions. The RS-232 interface has the least amount of failure tolerance features implemented, but this bus standard can only connect two nodes, and for 87 % (n = 24) of the CubeSats, this is complemented with one or more of the other bus types.

Figure 8 presents the reported in-orbit issues for I2C, SPI, and RS-232. For I2C, bus lockups appear to be a major issue. Also for one CubeSat, I2C has led to a catastrophic failure (proven), while for two more I2C are a likely cause (hypothesis). For RS-232 and SPI, only few issues are reported. There are several possible explanations why I2C has a relatively high amount of reported issues:

Fig. 8
figure 8

In-orbit issues reported for three bus standards

  • I2C lacks separate lines for handshaking and control compared with SPI and RS-232.

  • For I2C, typically a higher amount of nodes is connected to the same bus than for SPI and RS-232.

  • I2C does not have differential signalling and is implemented without shielding in most CubeSats.

  • The state-machine of I2C hardware controller and firmware may have errors. This risk becomes larger when different microcontrollers are connected to the same bus.

Some examples of I2C problems are found in literature. The failure of the CP4 CubeSat of California Polytechnic State University is most likely the result of I2C data bus problems [16]. The Delfi-C3 satellite of TU Delft also experienced major I2C problems, which caused high bit-error-rates as well as sustained bus lockups [7]. These bus lockups were recovered by the power reset in each eclipse, because of the absence of a battery in this satellite. The Delfi-n3Xt satellite of TU Delft lost its transmission signal after completion of its primary mission objectives when an experimental transponder was switched on [17]. The main hypothesis for the root cause is that an I2C buffer has been blown up by the transponder, effectively terminating all internal data handling. During a late development stage, it was already discovered that the implemented I2C buffer has a potential failure mode which shorts the bus to ground.

4 Survey on CubeSat power buses

4.1 Electrical power subsystems implemented

A central electrical power subsystem (EPS) unit is typically responsible for the power conversion from the solar panels, the energy storage, as well as the distribution of power to the rest of the satellite over one or more power bus lines. The ability to switch subsystems on and off, overcurrent protection, and the power bus topology have an impact on the power bus reliability. A former study has shown that each commercial supplier has a different implementation on these aspects [6].

Of the combined launched and to be launched CubeSats (n = 84), 63 % have a custom designed central EPS unit, 19 % a COTS unit from GOMSpace, 15 % from ClydeSpace, 1 % from CubeSat Kit, and 1 % from Tyvak.

In Fig. 9, the topology and reliability features implemented on the CubeSats are provided. A shared line means that multiple subsystems are drawing current from a single power line. If this line is only protected at the central EPS unit, the subsystems allocated to this shared line pose a threat to each other. If they are, however, protected at the subsystems locally, this risk is mitigated. For individual lines to each subsystem, protection could be at the central unit and/or the local subsystem. As example for such power protection, in the MicroMAS CubeSat of MIT, Fairchild FPF2700 high-side current limit switches are implemented to provide load switching and overcurrent protection [18]. Another example is the protection circuit within Delfi-n3Xt which uses a dedicated circuit at each subsystem locally to protect both the main power bus as well as the I2C data bus [19].

Fig. 9
figure 9

Distribution topology and reliability features

4.2 Power distribution reliability

A 29 % of the launched CubeSats (n = 49) have reported in-orbit issues with the EPS. The issues are categorized and provided in Fig. 10. The rapid solar cell degradation is noteworthy, as two reported, this was due to missing cover glasses, while the third was not specified.

Fig. 10
figure 10

In-orbit issues reported for the EPS (n = 49)

For fully unprotected distribution lines, there is a risk to the overall EPS. A 10 % of the CubeSats (n = 50) have implemented unprotected shared distribution lines. One of them lost contact after 10 days, with a hypothesis of a radiation event resulting in a short circuit. A second CubeSat out of this five never made contact, for which the reason is unknown. Despite small sample size, these two examples exhibit the risk of implementing unprotected power distribution lines.

Several papers address the relation of power distribution protection features and radiation effects. It was reported that Cute-1.7 + APD have lost operability of their satellite about 3 weeks after launch, most likely due to radiation effects [20]. On ground, analysis revealed that a combination of a latch-up and a too high threshold for an overcurrent protection circuit have caused damage to the on-board integrated circuits [20]. The GOMX-1 satellite reported (intentional) power cycles of their payload triggered by bit-flips in the field-programmable gate array (FPGA) due to radiation effects, many of them occurring in high-energy electron regions, such as the South Atlantic Anomaly [21]. However, for GeneSat-1 analysis of in-orbit data of the performance of Peripheral Interface Controllers (PICs) indicated no CPU resets, latch-ups or single-event upsets during its 18 months of operation [22]. It can thus be concluded that susceptibility to radiation effects may be strongly related to the specific type of integrated circuits implemented.

5 Survey on CubeSat wiring harness

The connector of the PC/104 bus standard has become the de-facto standard wiring harness in CubeSats, as most commercial developers provide their subsystems with this interface. The PC/104 bus standard is derived from the ISA bus applied in personal computers in the past, and its initial release was 1992 [5]. It defines not only the wiring harness, but also the form factor of the printed circuit boards and their mechanical mounting [5] and is supposed to be able to stack embedded systems on top of each other. In Fig. 11, an example is provided showing the 104-pin stackable connector.

Fig. 11
figure 11

Example of a CubeSat on-board computer (TU Delft) with PC/104 connector

For CubeSats, many aspects of the PC/104 standard are not implemented. The commercial suppliers of CubeSat subsystem typically implement the I2C data bus, while the Industry Standard Architecture (ISA) bus is the intended data bus for the PC/104 standard [5]. In addition, the allocation and distribution topology for power are not taken over, nor standardized for CubeSats, leading to compatibility issues [6]. Therefore, when PC/104 is mentioned as standard in relation to CubeSats, this refers to a fixed physical wiring harness and the mechanical layout and not the data bus or pin allocation.

For all CubeSats, the specification or standard of wiring harness was asked for. These are grouped in ‘PC/104’ and ‘other’, as no other standard is clearly implemented by multiple developers. For the launched CubeSats, 35 % have implemented the PC/104 connector (n = 49). For the CubeSats not yet launched, this is 59 % (n = 32), probably due to the increasing availability of commercial subsystems with a PC/104 connector. For CubeSats with different wiring harness, the information provided is too limited and heterogeneous for statistical analysis.

Of the launched CubeSats, there are no in-orbit failures reported which are directly allocated to the wiring harness in the sense of wiring breaks or short circuits. The standard itself, however, partially drives power bus distribution and data bus selection, which is already treated in the previous sections. In Fig. 12, the design issues for all CubeSats (launched and to be launched) with the PC/104 connector are provided based on simple ‘yes or no’ questions. The wires are extended through-hole pins which can be stacked into the next connector. In some cases, an additional connector is stacked in between two printed circuit boards to be able to span a wider distance.

Fig. 12
figure 12

Design issues reported on PC/104 connector (n = 36)

It can concluded from Fig. 12 that a (small) majority states that the PC/104 connector is too big, while only a small minority considers the amount of pins to be too little. Thus, for a future standard, a smaller connector with fewer pins is recommended. The reliability of the connectors or wiring is not a major concern. Three additional issues (‘other’ in Fig. 12) are reported: I2C cannot handle long wiring, there are difficulties with mating/de-mating during the development phase and PC/104 structural layout does not create good thermal paths.

From literature, a few additional observations are made. According to Kimm and Jarell [23], the PC/104 CubeSat Kit from Pumpkin shows two weaknesses: the non-redundant architecture of the on-board processor and the fairly large size of the physical bus interface. It is also noted that the form factor makes it difficult to include redundant systems. They suggest to use CAN for a data bus in CubeSats and propose a protocol (at higher OSI layers) to handle data traffic. During the development of the EDSN satellite, it was found that low-cost consumer grade connectors sometimes provided physical alignment issues and even intermittent contacts [24]. It is recommended to use higher grade components [24].

6 Conclusions and recommendations

In this paper, the implementation and reliability of electrical bus interfaces are analysed through a literature survey and a questionnaire. In this section, the main results and conclusions are provided.

It has been found that at least 65 % of the CubeSats in this survey (n = 60) are expected not to fulfill all mission objectives. There is, however, no evidence that the electrical interfaces are a major cause for this. The fully operational lifetime of CubeSats is 1.2 years on average, while 20 % of the CubeSats have not been operational for their design life time.

Currently, the most popular buses for CubeSats are I2C, SPI, and RS-232. The I2C data bus shows many bus lock up issues on CubeSats (for three CubeSats, this bus is likely to have caused catastrophic damage, of which two beyond the mission design lifetime. Especially, the combination of unshielded pins of the PC/104 connector and the I2C data protocol is a concern.

While the EPS is a major source of in-orbit failures, most of those failures are not allocated to power bus interface. However, of the five CubeSats that have implemented no protection of the power distribution lines, two have failed after some days in orbit. For the majority of the CubeSats which implemented the PC/104 connector, it is stated that the connector is too large, but no catastrophic in-orbit failures have been reported, because of this connector.

For a future CubeSat bus standard, the following recommendations can be made:

  • The data bus should have a continuous nominal behavior, without major risk for bus lockups.

  • The power distribution lines should protect both the central EPS unit as well as the local subsystems against short circuits and overcurrent, including those induced by radiation effects.

  • The standard interface connector should be smaller than the PC/104 connector.

  • The standard interface should have a fixed pin allocation to achieve general compatibility between subsystems.

  • The standard interface connector should tolerate the long-term thermo-mechanical stress cycles induced by the LEO alternation between Sun and eclipse, proven by representative (accelerated) life testing.

An important aspect for a future bus standard is the overall redundancy and failure mitigation concept for CubeSats. If there will be redundant physical subsystems, the bus standard may need to accommodate failure detection, isolation, and recovery with specific wiring and/or circuitry. In addition, the data and power interfaces themselves may require redundancy. Further study into the needs and analysis on the impact of this aspect is recommended for the development of a new CubeSat bus interface standard. For improved analysis on this aspect and for CubeSats, in general, it is recommended that CubeSat developers publish more details about their in-orbit results, with an emphasis on the experienced issues, anomalies, and failures.