- Chapter Glossary
- 8.1 Introduction
- 8.2 Avionics Systems Platform and Mission Development Considerations
- 8.3 State-of-the-Art (TRL 5-9): Command and Data Handling
- 8.4 State-of-the-Art (TRL 5-9): Flight Software
- 8.5 On the Horizon (TRL 1-4): Command and Data Handling
- 8.6 On the Horizon (TRL 1-4): Flight Software
- 8.7 Summary
- 8.8 References
(ASICs) Application-specific Integrated Circuits
(CDH) Command and Data Handling
(CRAM) Chalcogenide RAM
(DDD) Displacement Damage Dose
(DRAM) Dynamic RAM
(EPS) Electrical Power System
(FERAM) Ferro-Electric RAM
(FPGAs) Field Programmable Gate Arrays
(FSW) Flight Software
(I/O) Input & Output
(LEO) Low-Earth Orbit
(MRAM) Magnetoresistive RAM
(OBC) Onboard Computer
(PCM) Phase Change Memory
(SDRs) Software-defined Radios
(SEEs) Single-event Effects
(SEL) Single-event Latch-up
(SEUs) Single-event Upsets
(SRAM) Static Random-Access Memory
(SSA) Small Spacecraft Avionics
(SWaP) Size, Weight, and Power
(SWaP-C) Size, Weight, Power, and Cost
(TID) Total Ionizing Dose
Small Spacecraft Avionics (SSA) are described as all electronic subsystems, components, instruments, and functional elements included in the spacecraft platform. These include primarily flight sub-elements Command and Data Handling (CDH), Flight Software (FSW), and other critical flight subsystems, including Payload and Subsystems Avionics (PSA). All must be configurable into specific mission platforms, architectures, and protocols, and be governed by appropriate operations concepts, development environments, standards, and tools.The CDH and FSW are considered to be the brain and nervous system of the integrated avionics system, and generally provide command, control, communication, and data management interfaces with all other subsystems in some manner, whether in a direct point-to-point, distributed, integrated, or hybrid computing mode. The avionics system is essentially the foundation for all components and their functions integrated on the spacecraft. As the nature of the mission influences the avionics architecture design, there is a large degree of variability in avionics systems.
There are two major factors to consider for SmallSat avionics:
1. Scale of spacecraft: a traditional spacecraft is a high-size, weight, power, and cost (SWaP-C), flagship system, so it’ll have a high-SWaP-C avionics system, typically to reduce risk and address higher reliability requirements. A SmallSat is a low-SWaP-C, miniature system, so it’ll have a low-SWaP-C avionics system. Typically, due to low cost, more risk is often tolerable, but nonetheless, reliability enhancements can be applied to increase reliability. Individually, the avionics system scales with the spacecraft, however constellations of SmallSats can “match” the capabilities of a traditional spacecraft (using multiple cheap units versus one expensive unit).
2. Architecture design: the architecture design is not necessarily dependent on the scale of the spacecraft. In both traditional spacecraft and SmallSats, the avionics system can be either centralized or decentralized, simplex or fault-tolerant, and modular or monolithic. Traditional spacecraft are very expensive, and to reduce risk, the avionics may employ redundancy such that if one element fails, the entire architecture is able to continue, but SmallSat avionics designs are more centralized, whereby if one element fails, the system fails. Figure 8.1 illustrates an architectural block diagram of a centralized small spacecraft system. In anticipation of extended durations in low-Earth orbit (LEO) and deep space missions, designers are now incorporating radiation-hardened (rad-hard) or radiation-tolerant architecture designs in their SSA packages to further increase their overall reliability.
This chapter focuses significantly on commercial products and developments, however vendors are not the only ones developing avionics platforms. There are numerous government/academic efforts worth considering, with a few examples below:
- SpaceCube and MUSTANG, by NASA GSFC (government)
- Sabertooth by JPL
- CHREC/SHREC Space Processor, by NSF SHREC (academic)
- RadPC by Montana State University (academic)
Given the distributed and integrated nature of modern SSA, this chapter organizes the state-of-the-art in SSA into CDH (8.3) and FSW (8.4). On-the-Horizon activities (TRL <5) for CDH and FSW (8.5 and 8.6, respectively) highlight recent developments in next-generation SSA systems. Avionics Systems Platform and Mission Development Considerations (8.2) discusses how these considerations are being addressed and/or mitigated by state-of-the-art advances in CDH, FSW, and PSA products. A summary of future SSA systems is provided in (8.7).
The information described below is not intended to be exhaustive but provides an overview of current state-of-the-art technologies and their development status. It should be noted that Technology Readiness Level (TRL) designations may vary with changes specific to payload, mission requirements, reliability considerations, and/or the environment in which performance was demonstrated. Readers are highly encouraged to reach out to companies for further information regarding the performance and TRL of described technology. There is no intention of mentioning certain companies and omitting others based on their technologies or relationship with NASA.
There are many factors to be considered in selecting the optimum configuration and implementation of avionics subsystems, components, and elements for small spacecraft missions. Overall spacecraft concerns of Size, Weight and Power (SWaP) always need to be considered. Some of the more pertinent issues and concerns that all small spacecraft missions must address include:
- Mission applicability and tailoring
- Element, module, and component modularity and interoperability
- Manufacturing and production efficiency, complexity, and scaling
- Mission environment, especially radiation and long-duration space exposure
- Standards and regulatory concerns
- SWaP-C constraints
In addition to CDH and FSW, state-of-the-art SSA systems should consider the following subsystem/payload specific electronic systems:
- Small spacecraft platform size ranges and configurations
- Integrated avionics platform architectures
- Mission avionics configurations
- Spacecraft and mission autonomy
Flight payload and subsystems avionics elements include:
- Subsystem integrated onboard computer (OBC) controllers
- Integrated systems health avionics
- Onboard payload processors
- Cloud-based processors
Modular avionics architectures for small spacecraft can be characterized as either federated or integrated. In a federated avionics architecture, each subsystem of the spacecraft is considered an independent, dedicated autonomous element, with the avionic components performing all functions independently and exchanging data over standardized communications protocols and interfaces. An integrated avionics architecture is a shared, distributed functionality, that can be configured with distributed, heterogeneous and/or mixed criticality elements. In either case, modular avionics architectures can be configured with smart subsystem capabilities, redundant fault tolerant radiation, and anomaly mitigation procedures.
Constellation networks and swarms, synchronized formations, and other multi-satellite cluster formations are creating new opportunities for SSA. The increased need for synchronization, intersatellite communications, controlled positioning for integrated CDH functionality, coordination and conduct, operation of ConOps, and autonomous operations impose new constraints on the avionics system. This is true not only for single satellites, but now also for multi-satellite configurations, whereby overall mission performance is dependent on all the platform elements acting in a co-dependent fashion.
Current trends in small spacecraft CDH generally appear to be following those of previous, larger scale CDH subsystems. The current generation of microprocessors can easily handle the processing requirements of most CDH subsystems and will likely be sufficient for use in spacecraft bus designs for the foreseeable future. Cost and availability are likely primary factors for selecting a CDH subsystem design from a given manufacturer, but many groups develop their own custom platforms. The ability to spread nonrecurring engineering costs over multiple missions and reduce software development through reuse are both desirable factors in a competitive market. Heritage designs work well for customers looking to select components with proven reliability for their mission. SmallSat CDH should consider the following:
- Avionics and onboard computing form factors
- Highly integrated onboard computing products
- Rad-hard processors and FPGAs
- Memory, electronic function blocks, and components
- Bus electrical CDH interfaces
- Radiation mitigation and tolerance schemes
As small satellites move from the early CubeSat designs with short-term mission lifetimes to potentially longer missions, radiation tolerance becomes significant when selecting parts. These distinguishing features, spaceflight heritage and radiation tolerance, are the primary differentiators in the parts selection process for long-term missions, verses those which rely heavily on commercial-off-the-shelf (COTS) parts. Experimental missions typically focus on low-cost, easy-to-develop systems that take advantage of open-source software and hardware to provide an easy entry into space systems development, especially for hobbyists or those who lack specific spacecraft expertise.
Small spacecraft CDH technologies and capabilities have been continuously evolving, enabling new opportunities for developing and deploying next-generation SSA. When small spacecraft were first introduced, a primary purpose was to observe and send information back to Earth. As awareness and utility have expanded, there is a need to improve the overall capability of data collection for specific mission environments beyond LEO. Small spacecraft, including nanosatellites and CubeSats, currently perform a wide variety of science in LEO, and these smaller platforms are emerging as candidates for more formidable beyond-LEO missions.
The adoption of CubeSat and SmallSat technology is enabled by the miniaturization of electronics, sensors, and instruments. As spacecraft manufacturers begin to use more space-qualified parts, they find that those devices can often lag their COTS counterparts by several generations in performance but may be the only means to meet the radiation requirements placed on the system. Presently, there are several commercial vendors who offer highly integrated systems that contain the onboard computer, memory, electrical power system (EPS), and the ability to support a variety of Input & Output (I/O) for the CubeSat class of small spacecraft. A variety of CDH developments for CubeSats have occurred due to in-house development, the rise of new companies that specialize in CubeSat avionics, and the use of parts from established companies who provide spacecraft avionics for the space industry in general. While parallel developments are impacting the growth of CubeSats, vendors with ties to the more traditional spacecraft bus market are increasing CDH processing capabilities within their product lines.
In-house designs for CDH units are being developed by some spacecraft bus vendors to better accommodate small vehicle concepts. While these items generally exceed CubeSat form factors in size, they can achieve similar environmental performance and may be useful in small satellite systems that replicate more traditional spacecraft subsystem distribution.
The CompactPCI and PC/104 form factors continue generally to be the industry standard for CubeSat CDH bus systems, with multiple vendors offering components that can be readily integrated into space-rated systems. Overall, form factors should fit within the standard CubeSat dimension of less than 10 × 10 cm2. Spacecraft avionics components are performance-driven and not necessarily dependent on spacecraft platform sizes, but some noncontainerized spacecraft platforms may need to consider using higher TRL avionics products and whether or not these products are available. The PC/104 form factor was the original inspiration to define standard architecture and interface configurations for CubeSat processors, but with space at a premium, many vendors have been using all available space exceeding the formal PC/104 board size. Although the PC/104 board dimension continues to inspire CubeSat configurations, some vendors have made modifications to stackable interface connectors to address reliability and throughput concerns. Many vendors have adopted the use of stackable “daughter” or “mezzanine” boards to simplify connections between subsystem elements and payloads, and to accommodate advances in technologies that maintain compatibility with existing designs. A few vendors provide a modular package which allows users to select from a variety of computational processors.
A variety of vendors are producing highly integrated, modular, onboard computing systems for small spacecraft. These CDH packages combine processors and/or Field Programmable Gate Arrays (FPGAs) with various memory banks, and with a variety of standard interfaces for other subsystems onboard. FPGAs and software-defined architectures also give designers a level of flexibility to integrate uploadable software modifications to adapt to new requirements and interfaces. Table 8-1 summarizes the current state-of-the-art for some of these components. Since traditional CubeSat designs are based primarily on COTS parts, spacecraft vendors often try to use parts that have radiation tolerance or have been radiation-hardened, as noted in the pedigree column in table 8-1. The vehicle column shows which spacecraft classification corresponds to each onboard unit; “general satellite” classification refers to larger SmallSat platforms (i.e., larger than CubeSats). It should be noted that while some products have achieved TRL 9 by virtue of a space-based demonstration, what is relevant in one application may not be relevant to another, and different space environments and/or reliability considerations may result in lower TRL assessments. Some larger, more sophisticated computing systems have significantly more processing capability than what is traditionally used in SmallSat CDH systems, however the increase in processing power may be a useful tradeoff if payload processing and CDH functions can be combined (note that overall throughput should be analyzed to assure proper functionality under the most stressful operating conditions).
System developers are gravitating towards ready-to-use hardware and software development platforms that can provide seamless migration to higher performance architectures. As with non-space applications, there is a reluctance to change controller architectures due to the cost of retraining and code migration. Following the lead of microprocessor and FPGA vendors, CubeSat avionics vendors are now providing simplified tool sets and basic, cost-effective evaluation boards.
Several radiation-hardened embedded processors have recently become available. These are being used as the core processors for a variety of purposes including CDH. Some of these are the Vorago VA10820 (ARM M0) and the VA41620 and VA41630 (ARM M4); Cobham GR740 (quad core LEON4 SPARC V8); BAE 5545 quad core processor; and LS1043 quad processor. These have all been radiation tested to at least 50 kRad total ionizing dose.
The range of onboard memory for small spacecraft is wide, typically starting around 32 kB and increasing with available technology. For CDH functions, onboard memory requires high reliability. A variety of different memory technologies have been developed for specific traits, including volatile memory, such as Static Random-Access Memory (SRAM) and Dynamic RAM (DRAM), Magnetoresistive RAM (MRAM), Ferro-Electric RAM (FERAM), Chalcogenide RAM (CRAM) and Phase Change Memory (PCM). SRAM is typically used due to price and availability, with numerous SRAM choices (up to 4M x 39 [20 MB]). There are many manufacturers that provide a variety of electronic components that are space-rated with high reliability. A chart comparing the various memory types and their performance is shown in table 8-2.
CubeSat class spacecraft continue to use interfaces that are common in the microcontroller or embedded systems world. Highly integrated systems, especially systems-on-chip (SoCs), FPGAs, and application-specific integrated circuits (ASICs), will typically provide several interfaces to accommodate a wide range of users and to ease the task of interfacing with peripheral devices and other controllers. FPGAs are commonly used for these interfaces because of their flexibility and ability to change interfaces as needed. Some of the most common bus electrical interfaces are listed below with applicable interface standards:
- Serial Communication Interfaces (SCI): RS-232, RS-422, RS-485 etc.
- Synchronous Serial Communication Interface: I2C, SPI, SSC and ESSI (Enhanced Synchronous Serial Interface)
- Multimedia Cards (SD Cards, Compact Flash, etc.)
- Networks: Ethernet, LonWorks, etc.
- Fieldbuses: CAN Bus, LIN-Bus, PROFIBUS, etc.
- Timers: PLL(s), Capture/Compare and Time Processing Units
- Discrete IO: General Purpose Input/Output (GPIO)
- Analog to Digital/Digital to Analog (ADC/DAC)
- Debugging: JTAG, ISP, ICSP, BDM Port, BITP, and DB9 ports
- SpaceWire: a standard for high-speed serial links and networks
- High-speed data: RapidIO, XAUI, SerDes and MGT protocols are common in routing large quantities of mission data in the gigabit per second speeds
Deep space and long-duration LEO missions compel developers to consider reliability requirements and possibly incorporate radiation-mitigation strategies into their respective spacecraft designs. CubeSats are often either composed of only COTS components or a hybrid combination of COTS and rad-hard and radiation-tolerant components. COTS components typically offer superior performance, energy efficiency, and affordability compared to their rad-hard alternatives; however, COTS devices tend to be highly susceptible to radiation. The advantages of COTS components have enabled low-cost CDH development, while also allowing developers to leverage start-of-the-art technologies in their designs. A hybrid design combines COTS and rad-hard components, such as COTS processor and memory with rad-hardened supporting electronics (e.g., EPS, watchdog, etc.), to maximize the benefits of both technologies. These designs may also incorporate radiation-mitigation techniques to further enhance overall system reliability.
For space applications, the effects of radiation on electronic devices can vary broadly (35). Radiation effects are often categorized into long-term cumulative effects and transient single-event effects (SEEs). Long-term effects include total ionizing dose (TID) and displacement damage dose (DDD). TID, measured in krad, is the ionizing radiation absorbed by the device material over time causing parametric or functional degradation of the device. DDD is the nonionizing damage caused by particle collisions with the device structure over time. SEEs occur when a single radiation particle strike deposits enough charge to cause an effect. SEEs can be destructive or nondestructive. Single-event upsets (SEUs) are nondestructive SEEs that can affect the logic state of a memory cell. Single-event latch-up (SEL) are destructive SEEs that manifest as parasitic structures in CMOS logic or bipolar transistor structures, potentially causing a high-current state.
Other CDH element areas of consideration include: memory, imaging, protection circuits (watchdog timers, communications watchdog timers, overcurrent protection, and power control), memory protection (error-correction code memory and software error detection and correction), communication protection (several components), and parallel processing and voting.
The FSW, at a fundamental level, communicates the instructions for the spacecraft to perform all operations necessary for the mission. These include all the science objectives as well as regular tasks (commands) to keep the spacecraft functioning and ensure the storage and communication of data (telemetry). The FSW is usually thought of as all the programs that run on the CDH avionics, but should also include all software running on the various subsystems and payload(s).
There are many factors in selecting a development environment and/or operating system for a space mission. A major factor is the amount of memory and computational resources. There are always financial and schedule concerns. Another factor is what past software an organization may have used and their experiences with that software. The maturity of the software and its availability for the target subsystem or payload are additional factors to be considered in the final selection.
FSW complexity can refer to the architecture design (e.g., the interactions between subsystems, especially for spacecraft autonomy) as well as the number of operations to be performed. The more software is required to do, the bigger the task and cost. This complexity (and the associated verification effort) is what primarily drives the cost and schedule for a program or mission. Required reliability and fault management can also increase complexity and cost, regardless of the size of the spacecraft. Changing requirements is also a huge factor, which may be mitigated by involving the software team early in the planning process.
With the increase in processing capability with CDH and other processors, more capable FSW has been enabled. Traditionally, larger spacecraft require rad-hard processors which have poor performance, while CubeSats and SmallSats can take more risks with COTS processors that offer substantially more performance. Several advances have increased the processing capabilities available for CubeSats. Low-power ARM-based processors and embedded COTS SoCs, as well as advances in radiation hardened processors, have brought similar processing capabilities down to the small size of CubeSats. All of this has resulted in increased demands and requirements for FSW.
Generally, CDH and other subsystems need to be able to supervise several inputs and outputs as well as process and store data within a fixed time-period. These all need to be performed in a reliable and predictable fashion throughout the lifetime of the mission. The needs of each mission can vary greatly, but basic deterministic and reliable processing is a fundamental requirement. The following are important when considering FSW design:
- Implication of CDH processors on FSW
- Operating systems
- Software languages
- Mission operations and ground support suites
- Development environment, standards, and tools
The processor and memory available on the CDH can put significant limitations on the FSW. For some of the smaller jobs, or to reduce electronic complexity, smaller processors are used (distributed processing). These have typically been thought of as embedded processors, with many of them containing dedicated memory. Modern integrated space avionics, including heterogeneous and mixed criticality architectures, also impact operational constructs and can contribute to advanced configurations (such as multiple modular redundant systems architectures) which can allow advanced paradigms for radiation tolerance and system redundancies in critical small spacecraft missions.
In the context of SSA, a FSW framework can be described as a hierarchal architecture, sometimes referred to as a set of lego-like building block constructs, partitions, and functions. This emerging system-of-systems concept describes the large-scale integration of many independent, self-contained systems that work together to satisfy a global need. Examples of commonly used frameworks include:
- cFS (https://cfs.gsfc.nasa.gov)
- F’ (https://github.com/nasa/fprime)
- NanoSat Mission Operations Framework (https://nanosat-mo-framework.github.io/)
- Spacecloud (https://space-cloud.io/)
- ROS (https://www.ros.org/)
Operating systems manage computer hardware, software resources, and provide common services for computer programs. Examples of commonly used operating systems include:
System programming involves designing and writing computer programs with software languages that allow the computer hardware to interface with the programmer and the user, leading to the effective execution of application software on the computer system. State-of-the-art small spacecraft have used C, C++, Python, Arduino and other software languages.
Although not directly used on the spacecraft, mission operations and ground support suites must also use software and systems for testing, and to monitor, command, control, and communicate with the spacecraft, as well as display status and disseminate data across all aspects of a space mission (including spacecraft performance and procedures, systems health, science and technology data handling and management, and telemetry tracking and control). For smaller spacecraft and missions, it is usually best to use the same ground support software for mission operations, integration and testing, and development and testing. There are numerous open-source and proprietary tools and programs available for these activities. A small set of tools that have been used at NASA are described below. For more information, please refer to the Ground Data System and Mission Operations chapter.
Development environment, standards, and tools are used to design, develop, validate, and operate small spacecraft missions, with adherence to accepted software and space mission standards. Examples of commonly used development tools include:
- Version control tools
- Auto-generation of software
- Simulations and simulators
- Software best practices and NPR7150
Many CDH systems will continue to follow trends set for embedded systems. Short-duration missions in LEO will continue to take advantage of advances made by industry leaders who provide embedded systems, technologies, and components. In keeping with the low-cost, rapid development theme of CubeSat-based missions, many COTS solutions are available for spacecraft developers.
While traditional CDH processing needs are relatively stagnant, as small satellites are being targeted for flying increasingly data-heavy payloads (i.e., imaging systems) there is new interest in advanced onboard processing for mission data. Typically, these higher performance functions would be added as a separate payload processing element outside of the CDH function.
Next-generation SSA/PSA distributed avionics applications are integrating FPGA-based software-defined radios (SDRs) on small spacecraft (36). A SDR can transmit and receive in widely different radio protocols based on a modifiable, reconfigurable architecture, and is a flexible technology that can enable the design of an adaptive communications system. This can increase data throughput and enable software updates on-orbit, also known as re-programmability. Additional FPGA-based functional elements include imagers, AI/ML processors, and subsystem-integrated edge and cloud processors. The ability to reprogram sensors or instruments while on-orbit have benefited several CubeSat missions when instruments do not perform as anticipated, or when entering an extended mission phase that requires subsystems or instruments to be reprogrammed.
In keeping with trends seen in other disciplines and industries, the Industry 4.0 and “digitally managed everything” is absolutely of critical importance for technological and programmatic efficiencies in SSA systems development. Following are some modern tools, technologies, and approaches that should be considered when developing and deploying next-generation small spacecraft avionic systems:
- Artificial intelligence, machine learning, and machine vision
- Robotics and automation
- Model-based systems engineering
- Embedded systems / edge computing
- Cloud computing
- Augmented reality/ virtual reality / mixed reality
- Advanced manufacturing
- Digital twin
FSW is key to mission success. The field of software is a very dynamic environment that is continuously evolving. The challenges with flight software usually remain the same regardless of the size of the spacecraft (CubeSat to SmallSat) and are related to the size and complexity of the endeavor. Overall, FSW can be known to cause scheduling issues and implementation issues, especially during integration and test. There is usually a temptation to add additional features, and all these factors can drive up overall complexity of the FSW and increase risk to the mission as a whole.
It is essential that FSW be as simple as possible. It is critical to survey options and plan early in any FSW effort. Wherever possible, early development and testing should be performed. Efforts to add additional features should be looked at very critically with a strong effort to stick to the existing plan. With good planning and careful execution, a favorable outcome can be achieved. It is becoming more common to update software after the hardware is delivered (or even launched), and there are now software frameworks such as cFS that have features to enable software updates after deployment.
On the horizon FSW will soon include multicore processor operating systems and programming, as learning how to harness multicore processors differently than Microsoft Windows does will enable true real-time multiprocessing. On the horizon FSW will also include artificial intelligence (e.g., Nvidia); FSW for multicore, multiprocessor, and heterogenous platforms (e.g., AMD-Xilinx Versal); and FSW (middleware) for constellations of SmallSats with resource management, scheduling and task assignment, and fault tolerance.
Spacecraft autonomy is an emerging capability and SmallSat designers have particular interest in the following characteristics for autonomous systems:
- Situational and self-awareness
- Reasoning and acting
- Collaboration and interaction
- Engineering and integrity
Spacecraft autonomy can be considered as a part of management, direction, and control for all subsystems and functions in a spacecraft. CDH takes input from, and provides direction to, all subsystems (ADCS, Power, Propulsion, Comm, vehicle health, etc.). Those subsystems may also have a degree of autonomy depending on the complexity of its local “smart subsystems” processor. The NASA 2020 Technology Roadmap defines autonomous systems as a cross-domain capability that enables the system to operate in a dynamic environment independent of external control (37).
Some autonomous systems now implement a heterogeneous architecture, meaning they contain multiple processors with varying levels of performance and capabilities. For instance, higher performance modules and components can be used for sophisticated data processing, AI and onboard computing for both spacecraft and mission performance optimization—as well as real-time adaptive analysis of science data—while lower performance onboard processors and FPGAs conduct the routine spacecraft operations functions and interact with the subsystems which also may include distributed performance cascades.
Space applications now require considerable autonomy, precision, and robustness, and are refining technologies for such operations as on-orbit servicing, relative and absolute navigation, inter-satellite communication, and formation flying. An exciting trend is that small spacecraft missions are becoming more complex as these platforms are now being used for lunar and deep space science and exploration missions. Small spacecraft technology is expanding to meet the needs of increasing small spacecraft mission complexity. This has accelerated over the past few years to achieve the next gen goals of using small spacecraft to collect important science in deep space, and mitigate risk for larger, more complex mission-critical situations. In parallel, spacecraft electronics have matured with higher performance and reliability, and with miniaturized components that meet the growing needs of these now very capable spacecraft.
The2022 Small Spacecraft Avionics chapter has been updated with a broader, interrelated framework, where CDH, FSW, and smart payloads are not just independent space platform subsystems but are part of an integrated avionics ecosystem which includes all electronic elements of a space platform, now primarily digitally based and or managed. Also, SSA should not be considered as an isolated spaceflight technology component, but rather as a core digital engineering technology emphasis area, capable of taking advantage of and integrating products, processes, and technologies from other disciplines. To continue to be relevant and efficient, the SSA communities must remain cognizant and receptive of the continuously evolving nature of the digital based Industry 4.0 technology revolution now being evidenced in other related and/or associated vertical disciplines and solutions.
For feedback solicitation, please email: firstname.lastname@example.org. Please include a business email for further contact.
(1) GomSpace. “NanoMind A3200,” Technical Datasheet. [Online] 2019. Available at: https://gomspace.com/shop/subsystems/command-and-data-handling/nanomind-a3200.aspx
(2) ISISPACE. “ISIS On board computer,” Technical Datasheet. [Online] 2019. Available at: https://www.isispace.nl/wp-content/uploads/2016/02/IOBC-Brochure-web-compressed.pdf.
(3) Pumpkin Space Systems. “Processor-specific CubeSat Kit Components,” Pumpkin Products/Store. [Online] 2020. Available at: https://www.pumpkinspace.com/store/c19/Processor-specific_CubeSat_Kit%E2%84%A2_Components.html.
(4) Xiphos. “Q7S Specifications,” Technical Datasheet. [Online] 2020. Available at: http://xiphos.com/wp-content/uploads/2015/06/XTI-2001-2020-e-Q7S-Spec-Sheet.pdf.
(5) Xiphis. Q8S SPECIFICATIONS – Datasheet. [Online] 2020. Available at: http://xiphos.com/wp-content/uploads/2020/06/XTI-2001-2025-f-Q8S-Rev-B-Spec-Sheet-1.pdf.
(6) BAE Systems. “RAD750 3U CompactPCI single-baord computer.” BAE Systems: Space product literature. [Online] 2008. Available at: https://www.baesystems.com/en-us/our-company/inc-businesses/electronic-systems/product-sites/space-products-and-processing/radiation-hardened-electronics.
(7) BAE Systems. “RAD5545 Space VPX single-board computer.” BAE Systems: Space products literature. [Online] 2017. Available at: https://www.baesystems.com/en-us/our-company/inc-businesses/electronic-systems/product-sites/space-products-and-processing/radiation-hardened-electronics.
(8) AAC Clyde Space. “Command & Data Handling KRYTEN-M3,” Technical Datasheet. [Online] 2020. Available at: https://www.aac-clyde.space/assets/000/000/179/AAC_DataSheet_Kryten_original.pdf?1600342763.
(9) AAC Clyde Space. “Command & Data Handling Sirius OBC LEON3FT,” Technical Datasheet. [Online] 2020. Available at: https://www.aac-clyde.space/assets/000/000/181/AAC_DataSheet_Sirius_OBC_-_updated_tables_original.pdf?1599046187.
(10) Innoflight. “CFC-300: Compact Flight Computer,” Technical Datasheet. [Online] 2020. Available at: https://www.innoflight.com/product-overview/cfcs/cfc-300/.
(11) Innoflight. “CFC-400: Compact Flight Computer,” Technical Datasheet. [Online] 2020. Available at: https://www.innoflight.com/product-overview/cfcs/cfc-400/.
(12) Innoflight. “CFC-500: Compact On-Board Computer,” Technical Datasheet. [Online] 2020. Available at: https://www.innoflight.com/product-overview/cfcs/cfc-500/.
(13) Space Micro. “CubeSat Space Processor (CSP),” Technical Datasheets. [Online] 2019. Available at: https://www.spacemicro.com/assets/datasheets/digital/slices/CSP.pdf.
(14) Nanoavionics. “CubeSat On-Board Computer – Main Bus Unit SatBus 3C2,” Technical Datasheet. [Online] 2020. Available at: https://nanoavionics.com/CubeSat-components/CubeSat-on-board-computer-main-bus-unit-satbus-3c2/.
(15) Moog. “Radiation Tolerant, 75GLOP 3U SPaceVPX GPU Sinlge Board Computer,” Technical Datasheet. [Online] 2020. Available at: https://www.moog.com/content/dam/moog/literature/sdg/space/avionics/Moog-Rad-Tolerant-75GFLOP-3U-SpaceVPX-GPU-Single-Board-Computer-Datasheet.pdf
(16) Moog. “BRE440 RADHARD CPU,” Technical Datasheet. [Online] 2018. Available at: https://www.moog.com/content/dam/moog/literature/sdg/space/avionics/moog-BRE440-RADHardCPU-Datasheet.pdf
(17) SEAKR. Commercial Products. SEAKR: Catalog. [Online] 2020. Available at: https://www.seakr.com/catalog/
(18) Unibap. “iX10-100 SpaceCloud solution,” [Online] Available at: https://unibap.com/en/our-offer/space/spacecloud-solutions/ix10100/
(19) Unibap. “iX5-100 SpaceCloud solution,” [Online] Available at: https://unibap.com/en/our-offer/space/spacecloud-solutions/ix5100/
(20) Unibap. “e20xx/e21xx Qseven Compute Product,” Technical Datasheet. [Online]. Available at: https://unibap.com/wp-content/uploads/2021/06/1004001-unibap-information-sheet-on-unibap-e2000_e2100-modules.pdf
(21) Nara Space Technology, Inc. “Nara Space OBC Datasheet,” Technical Datasheet, 2022.
(22) Argotec. “FERMI: Deep Space On-Board Computer,” Technical Datasheet. [Online] Available at: https://www.argotecgroup.com/wp-content/uploads/2022/03/Argotec_FERMI_scheda_prodotto.pdf
(23) Argotec. “Hack: High-Performance Modular On-Board Computer,” Technical Datasheet. [Online] Available at: https://www.argotecgroup.com/wp-content/uploads/2022/03/Argotec_HACK_scheda_prodotto.pdf
(24) Resilient Computing. “Technology: RadPC – Radiation Tolerant Computing.” [Online] Available at: https://resilient-computing.com/technology
(25) Spacemanic. “Eddie: The computer, SM-OBC-MSP430,” Technical Datasheet. [Online] Available at: https://www.spacemanic.com/files/datasheet/datasheet-OBC_Eddie.pdf
(26) Spacemanic. “Deep Thought Onboard Computer, OBC-SM-DT-SAMV71,” Technical Datasheet. [Online] Available at: https://www.spacemanic.com/files/datasheet/datasheet-OBC-DT.pdf
(27) Novo Space. “SBC002AV,” [Online] Available at: https://www.novo.space/products/sbc002av
(28) Novo Space. “SBC003AV,” [Online] Available at: https://www.novo.space/products/sbc003av
(29) Novo Space. “GPU001AF,” [Online] Available at: https://www.novo.space/products/gpu001af
(30) KP Labs. “Antelope,” Technical Datasheet. [Online] Available at: https://kplabs.space/wp-content/uploads/Antelope_technical-sheet.pdf
(31) KP Labs. “Leopard,” Technical Datasheet. [Online] Available at: https://kplabs.space/wp-content/uploads/Leopard-technical-sheet.pdf
(32) KP Labs. “Lion,” Technical Datasheet. [Online] Available at: https://kplabs.space/wp-content/uploads/Lion-technical-sheet.pdf
(33) C3S Electronics Development LLC. “ON-BOARD COMPUTER (OBC),” Technical Datasheet. [Online] Available at: https://c3s.hu/wp-content/uploads/2022/01/C3S_OBC_datasheet.pdf
(34) EndroSat. “Onboard Computer – OBC,” [Online] Available at: https://www.endurosat.com/cubesat-store/cubesat-obc/onboard-computer-obc/
(35) National Academies of Sciences, Engineering, and Medicine. 2018. Testing at the Speed of Light: The State of U.S. Electronic Parts Space Radiation Testing Infrastructure. Washington, DC: The National Academies Press.
(36) M. Wirthlin, “High-Reliability FPGA-Based Systems: Space, High-Energy Physics, and Beyond,” in Proceedings of the IEEE, vol. 103, no. 3, pp. 379-389, March 2015.
(37) NASA. 2020 Technology Taxonomy. [Online] Available at: https://www3.nasa.gov/sites/default/files/atoms/files/2020_nasa_technology_taxonomy.pdf