Built by the
C++
community.
Trusted by
the world.

How Boost.Asio and Boost.Serialization enabled a next-generation space communications system for the International Space Station

Prof. Sven G. Bilén, Ph.D. Professor of Engineering Design, Electrical Engineering & Aerospace Engineering at The Pennsylvania State University

Timothy M. Hackett, Ph.D. Associate Technical Fellow in Edge and Distributed Computing at Lockheed Martin Space

The Challenge: Building a Cognitive Engine for Space

Our research team at Penn State, in collaboration with Worcester Polytechnic Institute and NASA's John H. Glenn Research Center, set out to build something that had never been deployed in a real space system before: a multi-objective reinforcement-learning cognitive engine capable of autonomously optimizing radio communications aboard the International Space Station. The engine used deep neural network ensembles to manage radio resource allocation in real time, adjusting modulation and coding schemes, roll-off factors, and transmit power to simultaneously optimize six competing objectives: bit error rate, throughput, occupied bandwidth, spectral efficiency, transmit power efficiency, and DC power consumption.

We wrote the engine in C++11 for maximum portability between ground-based and space-based radio platforms. Unlike our original MATLAB prototypes, C++ does not come equipped with high-level constructs for networking, serialization, or matrix algebra. We needed production-quality libraries that could handle real-time UDP communications with commercial DVB-S2 satellite modems and allow us to save and restore the complete state of a learning system between orbital passes, all while meeting the strict licensing constraints imposed by ITAR and export control regulations.

Why Boost: Licensing, Reliability, and Portability

Choosing the right software libraries was one of the most consequential decisions in the entire project. Because our export-controlled software was destined for redistribution on NASA's STRS (Space Telecommunications Radio System) Repository, we required libraries with permissive, non-copyleft licenses. GPL and LGPL libraries were off the table. This constraint alone eliminated the majority of candidates.

Boost stood out immediately. Its permissive license meant we could integrate it into our cognitive engine and contribute the code to the STRS Repository without any risk of violating redistribution requirements. But licensing was only the starting point. What truly set Boost apart was the maturity and reliability of its libraries. When you are building a system that will operate on the International Space Station, you cannot afford to debug flaky networking code or fragile serialization routines. Boost gave us battle-tested components that worked.

Boost.Asio: The Communications Backbone

Our cognitive engine communicates with multiple external modems simultaneously. The ViaSat DVB-S2 receiver sends real-time signal quality telemetry over UDP, while the ML605 transmitter modem requires raw Ethernet frames to embed action tuples into Advanced Orbiting Systems (AOS) frames for uplink to the ISS. Each interface has different protocol requirements, different timing constraints, and different failure modes.

Boost.Asio handled all of this elegantly. Its asynchronous I/O model allowed us to manage concurrent UDP listeners and transmitters without resorting to low-level socket programming or platform-specific APIs. The abstraction layer meant that the same networking code we developed on our ground workstations could be ported to different target platforms with minimal modification. For a system that must operate reliably within a 40-millisecond round-trip time window between ground and orbit, the deterministic performance of Boost.Asio was critical.

Boost.Serialization: Preserving Learned Intelligence Across Orbital Passes

One of the key research questions in our experiment was whether a cognitive engine that retains its learned neural network weights from a previous ground station pass outperforms one that must relearn from scratch at the beginning of every contact window. Each ISS pass over a ground station lasts only minutes, and every second spent relearning is a second of suboptimal communications performance.

Boost.Serialization made it possible to archive and restore the complete state of our reinforcement-learning system, including all neural network weights, the training buffer contents, and application-specific parameters, to human-readable text files. When the engine restarts for a new pass, it can load the serialized state and resume with full knowledge of what it previously learned. This capability is foundational to the entire concept of persistent cognitive communications: a radio that gets smarter over time, pass after pass. The library's ability to serialize complex, nested C++ object hierarchies transparently saved us weeks of development time that would otherwise have been spent writing custom persistence code.

Boost as Part of the Broader Ecosystem

Boost's influence on our project extended beyond the two libraries we used directly. MLPack, the machine learning library we selected for our neural network implementation, uses Boost internally. Armadillo, our matrix algebra library, also integrates with the Boost ecosystem. This meant that our entire software stack shared a common foundation, which simplified the build process, reduced dependency conflicts, and made the system more maintainable. When multiple critical libraries in your project all trust Boost as their own dependency, that tells you something important about its quality and standing in the C++ community.

Impact and Results

Our implemented cognitive engine completed on-orbit experiments with the ISS via the SCaN Testbed in May 2017. The cognitive engine was tested through a total of 20 flight passes over NASA Glenn Research Center’s ground station providing performance results across a variety of link profiles. To the best of our knowledge, this marked one of the first published experiments of using a cognitive engine with a space-based asset and demonstrated that reinforcement learning-based multi-objective optimization is both feasible as well as useful for satellite communications.

The modular, object-oriented architecture we built was designed so that only the application-specific module needs to be swapped to adapt the engine for entirely different missions or optimization objectives. This reusability was central to NASA's vision for cognitive communications: systems that can be deployed across diverse missions without requiring a complete software rewrite each time.

Boost helped our small academic–government research team to punch well above our weight. Instead of spending months building and testing networking and serialization infrastructure from scratch, we were able to focus on what made our project unique: the cognitive algorithms themselves. For any team building mission-critical C++ systems under tight timelines and strict licensing constraints, Boost is not just a convenience, it is a force multiplier.

"When you're building software that needs to operate flawlessly with the limited flight pass opportunities of the International Space Station, you need libraries you can trust and that allow you to move quickly. Boost gave us exactly that: production-grade networking and serialization with a license that met NASA's requirements. It let us focus on the engineering instead of reinventing the wheel."

— Prof. Sven G. Bilén, The Pennsylvania State University

References:

Bilén, S.G. (2024). “Cognitive Radio.” In: Lakhtakia, A., Furse, C.M., Mackay, T.G. (eds), The Advancing World of Applied Electromagnetics, Springer, Cham. https://doi.org/10.1007/978-3-031-39824-7_16.

Bilén, S.G., D. Mortensen, R. Reinhart and A. Wyglinski, “Where no radio has gone before: Cognitive radios can keep deep-space missions connected to earth even when faced with Alien environments,” IEEE Spectrum, vol. 57, no. 8, pp. 44-50, Aug. 2020, doi: 10.1109/MSPEC.2020.9150556.

T. M. Hackett, S. G. Bilén, P. V. R. Ferreira, A. M. Wyglinski, and R. C. Reinhart, “Implementation and on-orbit testing results of a space communications cognitive engine,” in IEEE Transactions on Cognitive Communications and Networking, vol. 4, no. 4, pp. 825–842, December 2018.

T. M. Hackett, S. G. Bilén, P. V. R. Ferreira, A. M. Wyglinski, and R. C. Reinhart, “Implementation of space communications cognitive engine,” in 1st IEEE Cognitive Communications for Aerospace Applications Workshop, June 2017.

P. V. R. Ferreira, R. Paffenroth, A. M. Wyglinski, T. M. Hackett, S. G. Bilén, R. C. Reinhart, and D. J. Mortensen, “Multiobjective Reinforcement Learning for Cognitive Satellite Communications Using Deep Neural Network Ensembles,” in IEEE Journal on Selected Areas in Communications, vol. 36, no. 5, pp. 1030–1041, May 2018.

P. V. R. Ferreira, R. Paffenroth, A. M. Wyglinski, T. M. Hackett, S. G. Bilén, R. C. Reinhart, and D. J. Mortensen, “Reinforcement Learning for Satellite Communications: From LEO to Deep Space Operations,” in IEEE Communications Magazine, vol. 57, no. 5, pp. 70–75, May 2019.

P. V. R. Ferreira, R. Paffenroth, A. M. Wyglinski, T. M. Hackett, S. G. Bilén, R. C. Reinhart, and D. J. Mortensen, “Multi-objective reinforcement learning-based deep neural networks for cognitive space communications,” in 2017 Cognitive Communications for Aerospace Applications Workshop (CCAA), Cleveland, OH, USA, 2017, pp. 1–8.

P. Ferreira, R. Paffenroth, A. Wyglinski, T. M. Hackett, S. Bilén, R. Reinhart, and D. Mortensen, “Multi-Objective Reinforcement Learning for Cognitive Radio-Based Satellite Communications,” in 34th AIAA International Communications Satellite Systems Conference, Cleveland, OH, 2016.

T. M. Hackett, S. Bilén, P. Ferreira, A. Wyglinski, and R. Reinhart, “Implementation of a Parameterized Interacting Multiple Model Filter on an FPGA for Satellite Communications,” in 34th AIAA International Communications Satellite Systems Conference, Cleveland, OH, 2016.

AutoDock Vina is the most popular molecular docking program, with 40,000 citations, as of this writing. It is used widely to look for treatments for various diseases from cardiovascular and infectious ones to cancer. I created AutoDock Vina back when I was a postdoc at The Scripps Research Institute. And Boost C++ libraries were of great help.

The mechanisms of action of various drugs are different in each case, but what they have in common is that the drug (typically a small molecule consisting of dozens of atoms) binds a huge molecule, like a protein (consisting of thousands of atoms). This binding is normally non-covalent (think "physics", not "chemistry"). It is also quite specific – the shape and other properties of the drug have to be complementary to the protein, not unlike a lock and key. This binding interferes with the normal operation of the protein in question, and this may have some desired biological effect.

Modeling this binding process computationally is challenging, but, if done well, it can predict which small molecules would be promising as drugs.

When I got hired by The Scripps Research Institute almost 20 years ago, they had already been developing a molecular docking program, which they called "AutoDock", for many years. AutoDock was being used widely, including in huge efforts like the IBM World Community Grid, where volunteers contributed their personal compute to do docking calculations. In one such project, AutoDock was being used to look for new anti-HIV drugs. I estimated that in that single project, millions of dollars were being spent just on electricity (a cost borne by the volunteers). So performance was important.

Initially, my plan was to contribute to AutoDock, but after a few weeks on the job, I realized that the best path forward would be to write a new docking program instead. I thought I could re-implement the same or equivalent algorithm in a fraction of the lines of code, using modern (at the time) C++, employing STL and Boost.

While I didn't get fired right away, I'll say this: If you set out to do something ambitious in academia, the clock starts ticking for you, because while you are busy working on your new high-effort and high-risk project, you are probably not publishing some low-effort and low-risk work that is encouraged in academia. And what if your project fails? Rather perilous for your career.

To make matters worse, during this rewrite, my ambitions grew much further. I was no longer content with just a rewrite and started experimenting with alternative algorithms and scoring functions. (The scoring function tells us which binding is better.) Long story short, after 1.5 years, I released a new docking program and called it "VINA" (short for "VINA Is Not AutoDock"). It was superior to AutoDock:

• It was roughly 60 times faster, when using a single thread (potentially saving many millions in electricity and compute)
• Additionally, it supported parallelism across multiple CPU cores seamlessly
• It was significantly more accurate in its binding pose predictions, on average
• It supported all major platforms directly (AutoDock required a Unix-like environment)
• The code was a few times smaller

Later, I was asked to change the name to "AutoDock Vina". "AutoDock" became a brand, rather than the name of a particular program. Sadly, this is causing confusion to this day. Many people think that "Vina" was a new version of old software, but it was brand-new and simpler code implementing a more complex algorithm.

Boost C++ libraries were quite useful to me in cutting down on the development time, which as I mentioned was important. In particular, I used

• Boost.Thread – it enabled parallelism in a platform-independent way
• Boost.Serialization – for object persistence
• Boost.Math – for quaternions, which are used to represent 3D rotations conveniently (Boost.QVM would have been more appropriate, but I don't think it was part of Boost back then)
• Boost.ProgramOptions – for parsing command line options and configuration files, as well as to display the help message
• Boost.Filesystem – for handling files in a platform-independent way
• Boost.PointerContainer – for containers of pointers to objects
• Boost.Array – for "vectors" of statically known length
• Boost.Optional – for objects that may or may not be there
• Boost.LexicalCast – for parsing numbers, mostly
• Boost.Random – for thread-safe random number generation
• Boost.Timer – to show the users a progress bar, while they are waiting for the results

Since then, some of these libraries made it into the C++ standard, I believe.

What I really liked about Boost was that the libraries are peer-reviewed, raising expectations about quality and security. And I don't think I encountered a single bug in any of the Boost libraries I used. My thanks to the developers!