Standardization is one of the strongest drivers of speed, scalability, and risk mitigation in the industrialization of space. But most space technology is not standardized. Optical, hyperspectral, radar, and radio-frequency sensors all generate data in different ways. Their interfaces, protocols, data rates, and timing requirements vary greatly even though they are supposed to solve the same set of tasks.

Hence, a computer designed for integration with many different payloads must combine standardization with considerable adaptability. Solving this problem is far from trivial. A monolithic system may offer high performance but become very expensive to change, while a highly modular solution risks ending up in a plethora of underperforming variants. For the Unibap iX20, we took a different approach to this challenge through our expansion module concept. The core platform remains monolithic and standardized. The expansion module provides modularity and the mission-specific adaptation.

We call this standardized adaptability.

The final 20%

The standard configuration of the iX20 contains a broad selection of interfaces intended to address approximately 80% of anticipated customer requirements. Covering the remaining 20% through the standard platform is considerably more difficult. A customer may need an uncommon protocol, more connectors of a particular type, specialized electrical functionality, or an interface that was not even developed when the computer was designed.

Trying to include every possible combination would increase complexity for all customers, while still not guaranteeing compatibility with future payloads. The alternative is normally a customer-specific redesign. However, redesigns generate non-recurring engineering, or NRE, and can introduce new development, schedule, and qualification risks.

The expansion module provides a defined boundary for such customer-specific engineering. Instead of modifying the core computer, the required adaptation is implemented within an isolated, standardized mechanical, electrical, and thermal framework.

The first customer-specific expansion modules are now under development. Although it is still too early to quantify the reduction in NRE, the objective is clear: limit customization to the part of the system that is genuinely mission-specific. The goal is not complete standardization. That would be unrealistic. It is a standardized way of managing what must be custom.

Clear signal paths for unconstrained throughput

In my previous article on Value Throughput, I argued that the defining performance of a space edge computer is not simply how many operations it can perform. What matters is how quickly it can transform raw sensor data into both useful and valuable information.

That process begins with getting the data into the computer. The iX20 includes many different interfaces because it must communicate with both payload and spacecraft systems. Integrating the most demanding high-speed interfaces into this already complex environment creates challenges related to signal integrity, electromagnetic compatibility, routing, power, thermal design, and mechanical layout.

These challenges increase rapidly with data rate. Trying to accommodate every high-end interface directly in the standard configuration would risk compromising both the quality of the interface and the versatility of the combined platform.

The expansion module provides another approach. The most demanding interfaces can be placed in a dedicated sub-system optimized for the intended data flow, with access to up to eight 25 Gb/s GTY transceivers, six 10 Gb/s GTY transceivers, PCIe Gen4, USB 3.2, and GPIO. Depending on the implementation, this can support standard or mission-specific protocols such as SpaceFibre, Ethernet, Aurora, Camera Link HS, or WizardLink.

Thus, the high-speed data path can be optimized for the payload without redesigning the common iX20 platform around one particular sensor.

Edge-compute integrated into the core of future space sensors

A particularly interesting development direction is to move the expansion module even closer to the source of the data. Advanced sensors, such as synthetic-aperture radar and very-high-resolution optical instruments, may generate more raw data at the detector than a conventional spacecraft interface can practically transport. Consequently, data often has to be reduced before it leaves the sensor.

This creates a bottleneck before the space edge computer has had the opportunity to determine which parts of the data are valuable. Information, and consequently sensor performance, is therefore lost at the detector interface rather than through an informed processing decision.

To address this, we are investigating how an expansion module could become a full-fledged front end for the detector. Instead of first adapting the detector output to a narrower external interface, hundreds of gigabit of data could be routed directly into the core of the iX20.

There, it would enter a Value Throughput Pipeline.

Value Throughput Pipelines provide an overarching concept for how Unibap SDMA, LOOM, and SEQR work together to move, refine, and protect data. The raw sensor stream can be preprocessed, compressed, and condensed so that its volume is reduced while the information required by the application is retained.

The distinction is important. Data should not be removed merely because an interface cannot carry it. It should be removed because the processing pipeline has determined that it does not contribute sufficient value to the intended result.

That is Value Throughput at its essence: reducing data without unnecessarily reducing information.

Toward a universal payload interface

Satellite-platform providers face a closely related challenge. Many want to develop a standard spacecraft platform capable of supporting different missions and sensor suites. Although mechanical accommodation presents one challenge, electrical and data integration can be equally limiting. Every new payload tends to introduce a new combination of interfaces, data rates, protocols, and control requirements. Hence, the platform provider encounters the same 80/20 problem as the computer provider.

Combining the iX20 with expansion modules could provide a next-to-universal interface between the satellite platform and the payload. The iX20, its software environment, heterogeneous processing architecture, spacecraft interfaces, and Value Throughput Pipelines remain common. Only the expansion module changes with the sensor. Our savings on NRE in terms of time, risk and resources gets directly transferable to the customer.

This allows a new payload to be introduced without rebuilding the complete onboard processing system. More importantly, applications developed and verified for the iX20 can be maintained when the sensor changes.

The value is therefore not limited to simpler electrical integration. It also includes the preservation of software, qualification evidence, integration knowledge, and operational procedures between missions.

Change what must change, preserve everything that does not, and future-proof your investment in the process.

From customized modules to standard products

Not every expansion module will be customer-specific. Unibap’s early roadmap includes standard modules that could be purchased together with the iX20. Although release dates and internal priorities have not yet been fixed, the anticipated modules fall into three general classes.

• More standard interfaces.The standard iX20 includes many interface types, but only a limited number of each. An expansion module could add, for example, more UART or SpaceWire connections.

• High-end payload interfaces.Interfaces relevant to several data-intensive missions could be provided through reusable standard modules. Potential examples include optical Ethernet, 100 Gigabit Ethernet, and SpaceFibre.

• Additional performance.Later modules could add storage, AI accelerators, cryptographic hardware, or other specialized computing resources.

Because the modules are tightly integrated with the iX20 and have direct access to Unibap SDMA, additional resources can become part of the real-time Value Throughput Pipeline rather than loosely connected peripheral devices.

This could also provide an effective route for testing new high-performance computing technology in orbit. A new accelerator, storage technology, or cryptographic device could be evaluated as part of a space-proven heterogeneous system architecture, while the core platform and software environment remain unchanged.

A future ecosystem around Value Throughput

If the expansion module concept becomes sufficiently mature and standardized, it could eventually create opportunities beyond Unibap’s own module portfolio.

Sensor manufacturers, cryptography specialists, and space-computing providers could develop modules that connect their technologies directly to the iX20. The main benefit would not simply be compatibility with another computing platform. It would be the ability to tap directly into established Value Throughput Pipelines.

A sensor front end could introduce data at the acquisition stage. An accelerator could add processing capacity where it creates the greatest value. A cryptographic module could protect information without interrupting the end-to-end data flow. Third-party providers could therefore focus on the technology where they provide unique value rather than independently solving the complete onboard data chain.

Such an ecosystem still lies far into the future. It would require a mature interface standard, meticulous specifications, development tools, reference designs, and a clear framework for qualification and responsibility. Before these can be established, Unibap must first develop a much deeper in-house understanding through its own expansion modules. But it illustrates the full potential of standardized adaptability: not only enabling new hardware to connect to the iX20, but allowing it to contribute directly to the creation of Value Throughput.

Standardized adaptability

The expansion module may appear to be an additional circuit board. Its intended value is considerably broader.

For payload and sensor providers, it offers a path from unique or high-throughput detectors directly into an integrated onboard processing pipeline.

For satellite-platform providers, it offers a common electrical and computational boundary through which different payloads can be introduced without changing the underlying computer.

For both, it limits mission-specific development to the part of the architecture that actually needs to be different.

Space payloads may never become fully standardized.

The way we adapt to them can be.

Anders Persson , Head of Strategy and Products