## 2 BIRDS 1U Standard Bus System
A voltage regulator that uses 3.3 V input from one of the power lines supplies 1.8 V to the integrated circuit. In addition, a joint test action group (JTAG) connection is used to program the chip. Table 2 represents the list of CubeSats with their CPLD families and corresponding functionalities. The CPLDs are most commonly implemented within the telemetry command and data-handling subsystem. On the other hand, the CPLD in BIRDS-3 was implemented on the backplane board as an interface between the PIC and the mission payloads. The table also shows the propagation delay and internal voltage supply of the CPLD according to the datasheet. The propagation delay varies depending on the chip package, and the data are based on the 144-pin quad-flat package (QFP) chip if not indicated by the resources. The ispMach4000 ZE CPLD was chosen for its optimal performance in terms of propagation delay and power consumption in addition to ease of availability, implementation, and cost. Figure 4 illustrates how data communication is performed between the bus system and mission boards. The 11 digital interfaces from the bus are routed to the mission boards through the CPLD. Depending on the implementation, these interfaces can be UART, SPI, digital input/output (DIO), or their combination. There is also an SPI line for transferring mission data to the shared FM in the OBC/EPS board, and the CPLD manages these digital interfaces to allow mission payload communication to the bus system. In addition, Figure 5 shows how a CPLD on the backplane operates where the CPLD is programmed as a voltage follower, with the output pin logic levels matching the paired input pin. Digital interfaces can be rerouted without requiring hardware changes by reprogramming the CPLD. This  
Figure 3: Backplane board (**bottom** side). saves both cost and time when redesigning the board. This also makes the backplane significantly more adaptable, especially during the initial development phase when routing changes are expected. \begin{table}
\begin{tabular}{c c c c c} \hline \hline
**Satellite** & **CPLD Function** & **CPLD Family** & **Propagation Delay (Max)** & **Voltage Supply (Internal)** \\ \hline \multirow{3}{*}{AAReST MirrorSat [18]} & On-board Computer (OBC); & & & \\  & Support for switching between & & & \\  & the two Raspberry Pi compute & & & \\  & modules and power sequencing & & & \\ \hline \multirow{3}{*}{OPTOS [19]} & Distributed On-board & & & \\  & Data-Handling Terminal (DOT); & & & \\  & Interface between the CPU and & & & \\  & mission experiments & & & \\ \hline \multirow{3}{*}{ARISSat-1 [20]} & Integrated Housekeeping Unit & & & \\  & (IFIU); Glue logic between the & & Intel & \\  & video input processor, the & & & \\  & SDRAM, and MCU & & & \\ \hline \multirow{3}{*}{BIRDS-3 [21]} & Backplane; & & & \\  & Interface between the main PIC & & & \\  & and payloads & & & \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Comparison of CPLD family used in CubeSats. Figure 4: Block diagram of data handling between the bus and the payload. Using this standard bus system, the configurable interface board can be scaled up and adapted to different CubeSat sizes. As a result, resources can be more focused on developing the mission payload and instruments. Lastly, it allows more time for integration and system-level verification, which are critical for a reliable and successful mission [22; 23]. Since implementing a configurable backplane to larger platforms has not been achieved before, challenges such as managing communication between the existing standard bus system and multiple mission payloads, as well as meeting the mission requirements of complex payloads, may occur. To prove that the standard bus system can be scaled and address the challenges encountered when scaling up to larger CubeSat platforms, two cases have been studied. In Section 2.1, a backplane prototype was developed to handle several missions based on the limited number of available electrical interfaces of a standard bus.