From Code to Constellation: Validating Space Innovations

The space industry is scaling rapidly. About 14,500 active satellites now orbit Earth, and roughly 90% of them fly in low Earth orbit (LEO). More than 41,000 satellites are planned across SpaceX, Amazon Leo, Qianfan, and other constellations. The applications are scaling with the hardware. Non-terrestrial networks (NTNs), standardized in 5G and now heading toward 6G, carry connectivity past the last cell tower. Direct-to-device is already in commercial service: Starlink's direct-to-cell links serve more than 150,000 daily users, and AST SpaceMobile has signed 50-plus mobile operators representing close to 3 billion subscribers. Phased array antennas, orbital data centers, in-space manufacturing, and habitation research are all moving from concept to build. Every one of those programs hits the same wall: proving the combined hardware and software performance of a launch-ready satellite. By combining design and test tools with command and control capabilities, space and satellite companies can confidently move from software conception to hardware validation.

The pace of a program depends less on the design than on how fast that design can be connected to real hardware and exercised. The problem is one of rapid test harnessing: how quickly a team can stand up a working command, control, and validation setup around its hardware, and how much of that setup survives the jump from the bench to orbit.

Why Rapid Test Harnessing Decides Who Ships

In the startup-centric space and satellite environment, designs are built and iterated in software. Proving them on hardware is where schedules slip. Under pressure to reach launch readiness, teams build quickly and treat test and validation as the step they can compress. At constellation scale, however, that math turns against them. If they ship a fleet of thousands of near-identical units, a 1% field failure rate equals 100 dead satellites, with no service to call once they are on orbit. By stopping the approach of hand-building the test harness every single time, space and satellite companies can keep validation off the critical path. An example is pairing Keysight's design and test tools with OpenC3's COSMOS command-and-control platform, shown in Figure 1.

Figure 1. Shown is a screenshot of the CmdTlmServer screen in COSMOS.

On the Keysight side, a small team can model and validate RF links, phased-array beam steering, and payload behavior under realistic orbital conditions before cutting flight hardware. PROPSIM channel emulation reproduces the Doppler, path delay, and fading of a LEO link on the bench, while SystemVue models the end-to-end payload so performance is characterized in simulation, not discovered after launch.

COSMOS supplies the control layer over that hardware. It sends commands, pulls telemetry, and runs scripted test sequences over standard interfaces, as shown in Figure 2. Because it speaks Standard Commands for Programmable Instruments (SCPI) to bench instruments and Consultative Committee for Space Data Systems (CCSDS) packets to flight hardware, the same harness that drives a benchtop power supply drives the satellite. Its containerized, Kubernetes-scalable architecture means the setup built for one prototype carries through FlatSat, integrated test, and operations up to a full constellation, without a ground-software rebuild at each phase.

Figure 2. Shown is a screenshot of the COSMOS telemetry viewer screen.

For a lean team, the result is shorter time to test results. The custom ground software that normally gets rewritten at every stage is already built. As a result, the schedule can be focused on proving that the system works instead of maintaining the plumbing that tests it. One approach is to use a command-and-control platform to connect, integrate, and orchestrate the hardware.

Do Not Test and Validate as an Afterthought

At the Space Symposium, Keysight and OpenC3 demonstrated their collaboration using a Keysight EDU36311A direct current (DC) bench power supply. Working from a testbench, they showed how COSMOS could command and monitor the supply directly over SCPI, the standard instrument command protocol, talking to it across the same local area network (LAN) interface that an engineer would use on the bench, as shown in Figure 3.

COSMOS connects to hardware through Transmission Control Protocol/Internet Protocol (TCP/IP), User Datagram Protocol (UDP), serial, Message Queuing Telemetry Transport (MQTT), and more interfaces out of the box. The power supply was one of several devices it orchestrated in the setup. Attendees could send commands to control the power supply and monitor the telemetry outputs of the CubeSat in real time, but the underlying point was that the same platform reads telemetry, issues commands, and coordinates every embedded device on the bench.

Figure 3. At the Space Symposium, OpenC3 showed how COSMOS could command and monitor a Keysight DC bench power supply over SCPI. Pictured are Clay Ito, Staff Software Engineer; Chris Haller, CMO; Ryan Melton, CEO; Jason Thomas, CTO; and Greg Bonn, COO.

For space payloads specifically, COSMOS handles CCSDS-formatted command and telemetry packets, the standard framing used across spacecraft buses. So the same system that drives a benchtop power supply also speaks the language of flight hardware. Because COSMOS is a containerized, microservice-based platform backed by a time-series database (QuestDB) and able to scale across a Kubernetes cluster, the setup that controls a single device on a bench extends to subsystem integration. It extends to operating a full constellation on orbit, all without re-architecting the ground software at each stage.

Get To Know OpenC3

Although COSMOS has been around for about 20 years, OpenC3 was only spun out of Ball Aerospace almost four years ago. Space has been the primary market for the COSMOS TRL-9 certified open-source command and control platform, but the company is now expanding into the defense market.

Currently, OpenC3 is investigating using COSMOS in drones with its MAVlink protocol plugin. Here, the use case is to control various payloads on drones. For drone manufacturers and those who are using payloads as a service, COSMOS can support payload control and mission planning.

Another potential use case is in pre-flight drone testing, mimicking the approach of FlatSat testing. Bringing together all drone components requires testing of every electronic portion, such as RF, power, and sensor integration, similarly to how it is done with satellites. Performing such testing on the ground eliminates the need to launch a rocket for flight testing.

DIY Vs. Designing to Win

OpenC3 works across the entire spectrum: from integration and test all the way through operations and operating constellations full of satellites on orbit. The ability to connect so many pieces of equipment explains why command and control software eases the load for designers, as shown in Figure 4. Yet the firm’s biggest competitor is the individual engineer, specifically the do-it-yourself kind of designer.

Figure 4. Pictured is an engineer testing equipment at a test bench with COSMOS running on their computer.

In today’s competitive landscape, many engineers opt to build the entire system on their own. They can create something that successfully gets them from one stage to the next. As they scale, however, the complexity of what they have built scales. They then have to worry about access, control, updates, security, and more, creating multiple pain points and costing months. Engineers reduce that complexity and move easily between different stages by using a single tool that connects to disparate hardware without deploying new code at each stage. COSMOS can read telemetry, command and control, graph everything going on, set up limits, and automate functions critical to mission operation.

Security risks also rise with the DIY approach. While Enterprise flies constellations, COSMOS Core is open source and currently deployed across thousands of installations. This aspect strengthens the software’s security, as being open source means many people are actively testing it. The code and the data are public, providing transparency into which versions of packages are being used. If vulnerabilities are reported, they can be patched quickly. Monthly releases also help to provide regular updates.

Advance Space and Satellite Designs with Confidence

A rushed, software-driven approach often sacrifices many of the test and validation steps needed to ensure system performance. This process is critical for systems operating in the challenging environment of space. Across industries, many developers are using AI to analyze or implement their designs. The reality is they still need the hardware, connections, and orchestration to enable the design to function so that it can be tested and validated, especially high-precision space systems.

Keysight supports end-to-end lifecycle space and satellite development, covering design, emulation, and test through deployment. With AI design capabilities, many performance details can be predicted and optimized. However, when it comes to actual hardware prototyping, design, and deployment, engineers need to test software plus hardware systems in real-world scenarios.

As airborne systems grow increasingly complex, drones through satellites may increasingly provide mission-critical services. By pairing Keysight's design and test tools with OpenC3's COSMOS command-and-control platform, designers can stop handcrafting their test harness and confidently validate the next generation of satellite innovations. With Keysight design, emulation, and validation tools and the ability to add command and control capabilities, startups through established companies can validate their hardware-software designs to increase confidence in real-world performance.

Find out more about Keysight’s space and satellite solutions here.

Visit the OpenC3 site to get started with open-source COSMOS Core.

Additional resources:

limit
3