What Can the Personal Computer Teach Satellite Designers About Disaggregated Satellite Architecture?

Key Takeaways

• PC history shows how standardized interfaces can separate functions without losing system coherence.
• Satellite networks can distribute sensing, computing, communications, and storage across separate nodes.
• Disaggregation gains resilience and upgrade speed when interfaces, timing, security, and control work together.

How the IBM PC Broke the Single-Vendor Machine Model

On August 12, 1981, IBM introduced the IBM 5150 Personal Computer at New York’s Waldorf Hotel. The base machine cost $1,565, contained 16 kilobytes of random-access memory, and had no disk drive. Displays, diskette drives, printers, memory expansion, and other capabilities could be added separately.

More consequential than those specifications was the architecture behind the machine. IBM used commercially available components, selected Intel’s 8088 microprocessor, obtained the operating system from Microsoft, and published enough technical information to help outside companies develop compatible software and peripherals. IBM describes the resulting open-system approach as a factor that made its PC a de facto industry standard.

Within a year, more than 750 software packages were available for the IBM PC, and dozens of companies were selling memory-expansion cards. Other manufacturers used IBM’s published specifications and independently developed compatible firmware to produce machines that came to be described as IBM compatibles.

The significance for satellite engineering lies less in the desktop computer itself than in the architectural decision behind it. A useful computing system did not have to be designed, manufactured, upgraded, and supported as a permanently fixed object. Processing, memory, storage, graphics, communications, input devices, and software could be treated as functions connected through defined interfaces.

That distinction reshaped the economics of computing. A graphics-card company did not need to manufacture an entire computer. A disk-drive manufacturer did not need to develop an operating system. Software companies could build applications for an installed base of compatible machines instead of creating custom hardware environments for every customer.

The PC remained physically concentrated inside one case, but its design had become a collection of replaceable functional blocks. The value of the system increasingly came from the relationships among those blocks rather than from an inseparable hardware package.

IBM’s later Personal System/2, introduced in 1987, demonstrates that modular architecture does not require every function to remain physically separate. IBM integrated input and output capabilities onto the motherboard that earlier PC owners commonly added through expansion cards. Functional boundaries could move as semiconductor integration, cost, performance, and manufacturing methods changed.

That pattern has direct relevance to spacecraft. Disaggregation does not require satellite designers to divide every spacecraft into the greatest possible number of independent vehicles. It allows mission functions to move among hardware, software, spacecraft, ground systems, and network nodes when separation improves replacement speed, survivability, performance, manufacturing economics, or flexibility.

The lesson from personal computing is not that everything should be separated. The lesson is that functional boundaries should be explicit enough to let designers decide where each function belongs.

Standard Interfaces Shifted Computing From Components to Networks

Expansion slots solved one part of the problem. Computing became much more flexible when standardized interfaces allowed functions to move beyond individual circuit boards and eventually beyond the computer chassis.

PCI-SIG specifications provide a present-day example. PCI-SIG defines standards intended to support industry-wide compatibility among peripheral component interconnects. Processors, accelerators, storage devices, network adapters, and other components can develop on separate product cycles because their interaction is governed by an interface rather than by a requirement that every component come from one manufacturer.

The commercial value comes from the interface contract. A supplier can improve one component without requiring every connected component to be redesigned. The system designer gains a larger supplier base and can substitute components when compatible alternatives exist.

IEEE 802.3 Ethernet extended comparable principles between machines. Instead of asking which storage device, printer, processor, or database belonged inside one computer, engineers could ask which resources should be reachable through a network. Standardized networking separated access to a resource from the physical computer containing it.

The Internet expanded that architectural separation. Applications could communicate with remote servers, information could reside on another machine, and computing resources could be shared across facilities. Physical location became less decisive to the application as networking protocols became more capable and broadly implemented.

Cloud computing pushed the separation farther. The NIST cloud definition describes on-demand network access to shared pools of configurable computing resources, including servers, networks, storage, applications, and services. A customer does not need to know which physical disk stores a file or which particular processor executes a workload. The service interface can matter more than the hardware location.

This progression produced an apparent contradiction. Consumer computing devices often became more physically integrated. Laptops and smartphones combine processors, graphics functions, communications interfaces, memory controllers, accelerators, cameras, and security functions into compact hardware assemblies. The larger computing system became more distributed at the same time.

Local hardware handles functions that benefit from low latency, immediate availability, privacy, energy efficiency, or independence from a network. Remote infrastructure handles functions that benefit from pooled computing capacity, large storage resources, centralized software, shared databases, or access from many locations.

Satellite systems can follow a comparable pattern.

An individual spacecraft may become more internally integrated through system-on-chip electronics, compact buses, integrated radios, software-defined payloads, and consolidated avionics. At the mission level, sensing, processing, routing, storage, navigation support, communications, and command functions can migrate across interconnected spacecraft and ground resources.

The useful comparison is consequently not “desktop PC equals satellite.” It is “networked computing architecture equals networked space architecture.”

Disaggregated Satellite Architecture Reframes Spacecraft Design

Traditional spacecraft engineering tends to concentrate mission functions inside an individual vehicle. An Earth-observation satellite may contain its sensor, onboard computer, storage, communications equipment, navigation receiver, attitude-control equipment, electrical power system, thermal-control system, and flight software. Data collected by the payload normally passes through that spacecraft before reaching terrestrial infrastructure.

This arrangement has strong engineering logic. Spacecraft operate far from repair facilities. Communications can be intermittent. Dependencies between vehicles create interfaces that must be designed, tested, secured, and maintained. A sufficiently autonomous spacecraft can continue performing useful work during periods when it cannot communicate with other nodes.

The disadvantage becomes more pronounced when an expensive mission depends on a small number of highly specialized spacecraft. The loss of one vehicle can remove a significant fraction of system capability. Hardware upgrades can require replacement of an entire satellite even if only one function has become obsolete. Development schedules can become tied to the slowest subsystem.

New Space Economy’s discussion of exquisite-class satellites examines this concentration of expensive sensors, processing, communications, and mission capability in comparatively scarce spacecraft. Proliferated architectures shift part of the value from the maximum capability of an individual spacecraft toward network capacity, redundancy, replenishment, geographic persistence, and the ability to introduce new technology more frequently.

A disaggregated satellite architecture separates selected mission functions physically, logically, or organizationally. A sensor spacecraft could collect raw information without carrying the largest processor available to the mission. Another spacecraft could process the information. A relay constellation could carry the data. Storage might reside on another node or on Earth. Mission software could assign workloads according to available communications paths and computing resources.

The arrangement begins to resemble distributed computing more closely than the traditional image of a satellite as an autonomous machine.

Physical separation is only one form of disaggregation. Software-defined systems separate functionality from permanently fixed hardware behavior. Virtualized computing separates workloads from specific processors. Hosted payloads separate payload ownership from ownership of the spacecraft bus. Commercial relay services separate communications infrastructure from the spacecraft generating the information.

The Eutelsat Quantum satellite provides a useful intermediate example. Launched in 2021, it was developed as a reprogrammable telecommunications spacecraft whose coverage, power, frequency allocation, and communications configuration could be modified after launch. Eutelsat Quantum remains one physical satellite, so it is not a physically distributed architecture. Its software-defined payload demonstrates how capability can become less dependent on a permanently fixed hardware configuration.

The architectural question consequently changes. Instead of asking what every spacecraft must carry, designers can ask which functions must remain local and which functions can become shared network services.

Personal Computer Functions Map Onto a Distributed Space System

The comparison becomes clearer when computing functions are mapped against spacecraft functions. The mapping is conceptual rather than literal. A spacecraft processor operates in conditions unlike those of a desktop processor, and an optical inter-satellite connection faces constraints that bear little resemblance to an electrical connection measured in centimeters. The architectural pattern still supplies a useful vocabulary for separating function from location.

The table compares common computing functions with possible counterparts in a disaggregated space system.

Sensing offers a straightforward example. Earth-observation spacecraft can generate much more raw information than a user ultimately needs. A conventional architecture sends large quantities of that information to terrestrial facilities for processing. Onboard processing can identify useful information before transmission. A distributed architecture can extend the idea by allowing specialized compute nodes to process information generated by separate sensor spacecraft.

Communications can separate in a similar fashion. A sensor does not necessarily require a direct high-capacity connection to every terrestrial destination if an orbital relay network can carry its traffic. The CCSDS Space Link Services standards address communications links between spacecraft and Earth and between spacecraft, supplying an international framework for interoperable space communications.

Storage presents another possibility. Sensor spacecraft can retain enough local capacity for buffering, fault recovery, and immediate operations, then transfer selected information to nodes with greater storage resources. Computing workloads can similarly move toward available processing capacity rather than remaining permanently attached to the sensor that generated the information.

A system organized this way could contain inexpensive sensor spacecraft optimized around collection rather than maximum onboard computing capacity. Optical links could carry selected raw or partially processed information to larger orbital computing nodes. Those nodes could perform image classification, data fusion, compression, anomaly detection, or other processing before forwarding a smaller and more useful information product to Earth.

That architecture does not require sensors to surrender local autonomy. A sensing node could maintain enough processing to operate safely, reject obviously unusable observations, encrypt data, manage communications, and survive network interruptions. Expensive computational functions could still be shared when connectivity and mission timing permit.

The result resembles the relationship between a network-connected endpoint and a data center. The endpoint retains the functions it requires to remain useful and safe. Shared infrastructure supplies functions whose economics improve when processing, storage, or communications capacity is pooled.

Operational Space Programs Already Show the Pattern

Military space programs provide clear demonstrations because resilience, replacement speed, interoperability, distributed sensing, and communications have direct operational value.

DARPA’s now-completed Blackjack program explored military use of commercial low Earth orbit manufacturing methods and distributed architecture. DARPA emphasized commoditized spacecraft buses, low-cost interchangeable payloads, shorter design cycles, frequent technology upgrades, mission autonomy, and distributed decision processing. DARPA now marks the program as complete and retains its program page for reference.

The connection to personal computing is architectural rather than technological. Standardizing enough of the underlying platform can allow specialized capabilities to develop on separate schedules. A payload does not have to dictate every property of the spacecraft bus, just as an application does not have to dictate every component inside a compatible computer.

The U.S. Space Development Agency is implementing the same general direction at much larger scale through the Proliferated Warfighter Space Architecture. The architecture distributes communications, missile tracking, warning, data transport, and related capabilities across many spacecraft in low Earth orbit rather than concentrating all capability in a small inventory of high-value satellites.

Interoperable optical communications are central to that design. SDA’s current optical communications standards include Optical Communication Terminal Standard versions 3.2.0 and 4.0.0. SDA identifies version 3.2.0 as its intended standard of record for Tranche 3, with a smaller number of terminals expected to implement version 4.0.0. The agency states that both versions are designed for backward compatibility and vendor interoperability.

SDA also publishes the Network Established Beyond the Upper Limits of the Atmosphere, or NEBULA, networking standard. Version 3.05, issued in November 2024, defines networking requirements for the Proliferated Warfighter Space Architecture and complements the optical-terminal specifications. This creates a layered standards model resembling terrestrial computing, where physical interfaces and network protocols solve different parts of interoperability.

As of August 11, 2026, Tranche 1 is still being deployed and transitioned toward operations rather than constituting a completed operational constellation. SDA’s July 16, 2026 launch placed 21 additional York Space Systems data-transport spacecraft into orbit and brought the publicly announced Tranche 1 on-orbit total to 63 spacecraft. SDA says these vehicles must proceed through checkout and orbit raising before transitioning into operations.

The planned complete Tranche 1 constellation consists of 154 operational spacecraft, including 126 Transport Layer spacecraft and 28 Tracking Layer spacecraft, plus four missile-defense demonstration spacecraft. SDA states that initial warfighting capability is expected to begin in 2027. The distinction matters because a constellation being deployed and tested should not be described as a fully operational network before the agency reaches that point.

Commercial space is beginning to supply another example. Axiom Space’s orbital data centers move the analogy from abstract architecture toward physical computing nodes in orbit. Axiom states that its first two dedicated orbital data-center nodes launched to low Earth orbit on January 11, 2026 with the initial tranche of Kepler Communications’ optical relay constellation.

Axiom describes an architecture in which another satellite can send raw imagery or telemetry through an optical connection to an orbital data-center node. The compute node can process, filter, compress, classify, store, or analyze the information and then forward the resulting product to Earth or another spacecraft. This arrangement closely resembles the separation between network endpoints and shared computing infrastructure found in terrestrial information technology.

Axiom says the nodes integrate optical inter-satellite links compatible with SDA Tranche 1 optical communications standards. That compatibility does not make the Axiom network part of SDA’s military architecture, but it demonstrates the commercial significance of a common interface. A spacecraft designed around a recognized optical standard has a better chance of communicating with independently developed infrastructure than a spacecraft dependent on a proprietary interface.

New Space Economy’s survey of orbital data-center companies describes how this market has moved beyond conceptual studies into early hardware deployments, demonstrations, regulatory filings, and competing commercial architectures. Large-scale orbital computing remains immature compared with terrestrial cloud infrastructure, but dedicated compute nodes now exist in orbit.

Disaggregation Creates New Engineering Costs

A networked architecture moves complexity rather than eliminating it. Separating functions creates interfaces, and every interface introduces requirements for communications, synchronization, authentication, fault handling, routing, testing, and operational coordination.

A computer designer can place storage a few centimeters from a processor and operate within controlled electrical and thermal conditions. Satellite nodes can be separated by hundreds or thousands of kilometers. They move according to orbital mechanics, visibility changes with geometry, optical terminals require accurate acquisition and pointing, and space-to-ground communications depend on ground-station access.

Latency creates another constraint. Some functions tolerate distributed processing well. Archival storage, image compression, data classification, or non-time-sensitive analysis may allow enough delay for a remote processing node to be useful. Guidance, attitude control, some navigation functions, collision avoidance responses, and tightly coupled sensor processing may demand responses too fast or dependable to rely on a distant node.

Local autonomy remains necessary. Disaggregation should not turn every routine spacecraft action into a network transaction.

Timing becomes more demanding when functions separate. Distributed sensors may need accurate synchronization before observations can be combined. Routing software needs information about link availability. Mission systems must distinguish among a failed node, blocked optical path, pointing problem, unavailable relay, delayed message, and rejected authentication attempt.

Cybersecurity grows more complex as the number of trusted relationships increases. One self-contained spacecraft can have a bounded set of communications interfaces. A distributed system may contain authenticated relationships among sensors, relay spacecraft, computing nodes, ground terminals, commercial networks, and user equipment.

Security architecture has to address identity, authorization, encryption, key management, software integrity, compromised nodes, routing manipulation, denial of service, recovery, and trust boundaries. The problem increasingly resembles distributed network security rather than traditional point-to-point spacecraft command protection.

Interoperability carries its own engineering cost. A standard must specify enough behavior to let equipment from separate suppliers communicate consistently. It must also leave enough room for technical improvement. SDA’s coexistence of Optical Communication Terminal Standard versions 3.2.0 and 4.0.0 illustrates the need to manage compatibility as communications technology changes.

Orbital mechanics add constraints unknown to terrestrial computing. A replacement server can be installed in a terrestrial facility without changing celestial geometry. A replacement spacecraft must reach an appropriate orbit, and a network may require insertion into a particular orbital plane. Launch availability, conjunction avoidance, debris mitigation, station keeping, radiation exposure, end-of-life disposal, and licensing affect the service architecture.

Power and thermal engineering also resist unlimited separation. A sensor still needs enough local electrical power to collect information. A processor still has to reject heat. An optical terminal consumes spacecraft resources regardless of where the application workload runs.

Disaggregation works best when architecture follows the physical requirements of each function. Tight control loops generally remain local. Functions tolerant of networking can move outward. Stored information can migrate more freely than attitude control. Mission planning can be distributed more readily than some fault-protection functions.

Personal computing reached a comparable arrangement. Processors maintain local caches rather than sending every memory request across a network. Cloud services coexist with local storage. Smartphones perform substantial processing locally even when network connectivity is available.

Spacecraft designers have the same freedom to combine local integration with mission-level distribution.

Disaggregated Satellite Architecture Changes the Space Economy

Architectural separation changes who can sell into a space program.

A highly customized spacecraft favors contractors capable of designing and integrating a complete satellite. Specialized companies still supply components and subsystems, but the spacecraft prime contractor controls many system boundaries and bears much of the integration responsibility.

Stable interfaces can move commercial boundaries inward. A company can specialize in optical terminals without manufacturing complete satellites. Another can supply standardized spacecraft buses. A payload manufacturer can concentrate on sensing. Software companies can provide mission applications. Ground-network operators can sell communications services. Computing providers can supply processing capacity without owning the sensor that generates the information.

DARPA’s Blackjack work on interchangeable payloads illustrates this industrial logic. SDA’s optical-terminal specifications seek interoperability across suppliers. CCSDS develops international communications standards that can permit separate organizations and national agencies to exchange mission data through defined protocols.

The PC industry expanded through comparable specialization. Intel did not have to manufacture printers. Microsoft did not have to manufacture disk drives. Storage companies could compete independently. Network-equipment manufacturers could develop products around common communications standards. Application developers could sell software to customers using machines assembled from components made by different suppliers.

A more disaggregated space industry could support similar specialization in spacecraft buses, optical communications, processing, storage, navigation augmentation, cybersecurity, mission software, operations, ground networks, launch services, and data products.

The economic boundary can move from spacecraft ownership toward service access. A satellite operator might own a sensor but purchase communications capacity. Another operator could own communications infrastructure and obtain computing capacity from a separate provider. Governments could combine sovereign spacecraft with commercial transport, storage, ground, or processing services.

Orbital computing extends that model. Dedicated processing and storage infrastructure can become a service consumed by spacecraft that do not carry equivalent computing resources themselves. A low-cost sensor platform could concentrate mass, power, and budget on the sensor, then use an external optical link when it needs access to greater computing capacity.

Such a design could also change spacecraft replacement economics. Sensor technology and computing technology do not necessarily improve at the same rate. If those functions are physically separated, a mission could replace a sensor generation without replacing the computing infrastructure, or expand computing capacity without launching an entirely new sensor fleet.

The arrangement carries commercial risk. A customer becomes dependent on interfaces, service availability, network coverage, pricing, security assurances, and provider continuity. Proprietary interfaces can recreate supplier lock-in even in an architecture marketed as distributed.

Open or broadly adopted standards can reduce that risk. They cannot remove integration work, but they can give customers more freedom to substitute compatible components and services.

New Space Economy’s analysis of Starlink laser communications illustrates another dimension of the market. High-capacity optical networking makes it possible for data to travel through space before reaching a terrestrial gateway. Extending compatible optical links to third-party spacecraft would make orbital communications infrastructure more analogous to a network service than to a radio carried solely for one satellite’s use.

A satellite economy organized around services would look different from one organized around complete spacecraft. Revenue could spread across computing, communications, storage, software, network management, cybersecurity, orbital logistics, data processing, and recurring infrastructure access.

That does not mean complete spacecraft manufacturing becomes less important. It means spacecraft manufacturing becomes one layer in a larger distributed system.

The PC Analogy Predicts a Hybrid Future for Satellite Design

Personal computing never moved in a straight line from integration toward separation. It moved in both directions at once.

Processors absorbed functions that once occupied separate chips. Motherboards incorporated functions previously supplied through expansion cards. Smartphones integrated cameras, radios, processors, navigation receivers, memory, security hardware, graphics processing, and specialized accelerators into compact devices.

At the system level, computing moved toward distribution. Storage spread across local devices and remote services. Applications moved among personal computers, mobile devices, servers, and cloud platforms. Processing resources became pooled. Data traveled through standardized networks. Software became less dependent on one physical machine.

That apparent contradiction offers one of the strongest lessons for spacecraft design.

Individual satellites are likely to become more internally integrated because mass, electrical power, reliability, packaging, and manufacturing economics reward compact designs. Semiconductor integration will continue reducing the need for discrete avionics assemblies. Software-defined radios and payloads will allow several functions to share hardware resources.

Mission architectures can become more distributed at the same time.

A sensing spacecraft can remain a tightly integrated machine yet depend on an external optical network. A communications spacecraft can route information generated by another operator’s satellite. Compute nodes can process information created elsewhere. Navigation and timing services can come from external systems. Ground software can allocate tasks among many spacecraft rather than command each one as a completely isolated asset.

The value of disaggregated satellite architecture lies in architectural freedom.

Functions do not need to remain physically together simply because earlier spacecraft placed them together. Designers can determine placement according to latency, power, thermal requirements, bandwidth, security, orbital geometry, survivability, replacement cost, manufacturing scale, and mission value.

Some functions will remain local. Others can become shared resources.

Interfaces determine how much freedom that architecture can support. The PC industry demonstrated that interchangeable hardware without interface discipline produces compatibility problems. Networks without common protocols form isolated systems. Cloud services without usable interfaces are difficult to combine. Space systems face comparable constraints with greater replacement costs because incompatible hardware may already be in orbit.

The most capable future space networks may consequently resemble layered computing architectures. A sensor layer collects information. A transport layer moves it. A compute layer transforms it. A storage layer retains it. Mission software allocates resources. Ground infrastructure connects orbital services to terrestrial users.

The physical spacecraft remain real engineering objects with their own power, thermal, guidance, navigation, communications, radiation, propulsion, structural, and fault-management requirements. The mission no longer has to be defined by the capabilities of any single spacecraft.

Axiom Space’s January 2026 deployment gives this model a concrete early example. Sensor data can, in principle, move to a separate orbital processing node through an optical relay. SDA’s architecture demonstrates another form, distributing communications and tracking functions across a proliferated network joined by standardized optical links.

The next architectural step is deeper interoperability among independently owned systems. A sensor from one supplier could use an optical terminal from another, send information through a third-party relay, obtain computing from another orbital node, and deliver the resulting product through a separate ground network.

That arrangement would resemble the commercial structure of terrestrial computing far more closely than traditional satellite procurement.

It would also introduce questions familiar to information technology. Who controls the interface specification? How is compatibility tested? What happens when a provider changes a protocol? How is workload priority assigned when network capacity is constrained? How does a customer migrate from one service provider to another? Which functions require sovereign control, and which can be purchased commercially?

These questions are partly technical and partly economic. Standards determine who can connect. Procurement rules determine who can compete. Security requirements determine which resources can be shared. Network architecture determines whether substitution is practical or theoretical.

The personal computer provides a useful historical warning as well as an analogy. IBM’s open architecture helped expand the PC market, but compatibility also allowed competitors to capture substantial value. Standardization can enlarge a market without guaranteeing that the company that initiated the architecture retains control of it.

Satellite primes, constellation operators, optical-network providers, orbital-compute companies, and software vendors could encounter a similar redistribution of value. A company that once sold a complete spacecraft might increasingly compete at one layer of a distributed architecture. Another company might control a communications interface or computing service used by many spacecraft.

The economic center can migrate even when the underlying mission remains the same.

Summary

The IBM PC’s lasting architectural contribution was not a particular processor, memory capacity, or disk format. Its open architecture demonstrated the commercial power of defining a computing system through interoperable functional components. Expansion standards allowed hardware to change independently. Networking moved resources outside the chassis. Internet services separated applications from local machines. Cloud computing separated many workloads from ownership of specific servers.

Satellite design is beginning to display comparable architectural behavior.

Traditional spacecraft concentrate sensing, processing, storage, communications, navigation support, software, and control inside individual vehicles. That arrangement remains appropriate for functions requiring immediate response, guaranteed local availability, safety autonomy, or independence from network connectivity.

Other functions can move.

Proliferated constellations distribute mission capacity across many spacecraft. Optical inter-satellite links turn those spacecraft into network nodes. Standardized terminals can permit equipment from separate suppliers to communicate. Software-defined payloads separate some mission behavior from fixed hardware configuration. Hosted payloads separate spacecraft ownership from payload ownership. Orbital computing can begin separating high-capacity processing and storage from the spacecraft generating the data.

The strongest analogy with personal computing is consequently not physical modularity inside a box. It is the separation of functions through interfaces.

A low-cost sensing spacecraft does not necessarily need to carry enough computing capacity for every possible workload if it can reach a compatible processing service. A compute node does not need to own the sensor whose information it processes. A relay network does not need to own the application generating the traffic. Storage can become a service rather than a fixed payload resource.

The likely outcome is neither completely monolithic spacecraft nor complete physical separation. It is a hybrid architecture in which individual spacecraft remain highly integrated machines and mission capability becomes increasingly distributed across networks.

Personal computing reached that arrangement decades ago. A laptop is highly integrated, yet much of what gives it value resides elsewhere: remote storage, network services, shared databases, cloud processing, communications infrastructure, and software maintained outside the machine.

Satellite systems can move toward the same architectural principle.

A spacecraft can remain an advanced machine without remaining a self-contained mission.

[meta keywords=“disaggregated satellite architecture, satellite systems design, personal computer architecture, modular spacecraft, proliferated satellite constellations, optical inter-satellite links, distributed space systems, satellite interoperability, software-defined satellites, orbital computing, orbital data centers, space-based edge computing, Space Development Agency, DARPA Blackjack, CCSDS, satellite network architecture, spacecraft modularity”]