[ad_1]
When we think about space exploration, we tend to think of astronauts, rockets, or the International Space Station. Maybe we also think about a team of experts sitting in the office of a Chinese or American space agency, breaking out into fits of joy as they successfully land a new rover on Mars.
What we tend to miss is all the people who write the software that keeps the satellites orbiting and the rockets on track. Large numbers of people sift through data from satellite sensors or simulate rocket launches before they take place. They, too, are doing rocket science. But it’s less intuitive to think of them as such.
Many images we see in the media show expert teams congratulating themselves or cool rovers and rockets cruising in outer space. They satisfy our human curiosity and our everlasting thirst for crossing new borders and expanding our horizons. At the same time, these types of stories keep things simple enough. Anyone can appreciate the fact that humanity has landed a few rovers on Mars. On the other hand, it takes a heap of expertise to understand how that rover is built, what goes into steering it, and which technologies make it fit for life on Mars.
Many people want to know about space. They want to know what it looks like and what humanity is doing to explore it. But without detailed knowledge, it’s hard to understand how space technology really works.
That’s where being a software engineer helps. Even if you don’t know too much about physics, or about rocket materials, coders can understand what types of software technologies are used in space and why.
Although NASA makes a lot of its code public, it’s hard to find details on the day-to-day activities of a software engineer for space tech. A few stories are available from Elon Musk’s projects, though. Considering that working at SpaceX or Starlink is many an engineer’s dream, these will be my focus here.
Starlink, where satellites calculate their own routes
Back in 1945, when science fiction writer Arthur C. Clarke first proposed satellite TV, it sounded like a pipe dream. Even though it took three decades, this technology finally became reality. Nowadays, many people have satellite receivers on their roofs and think nothing of it. Satellites’ major advantage over cable is that they can reach rural areas, which wouldn’t be cost-effective with very long cables.
Similarly, satellite internet still sounds like a pipe dream to many people. But the demand is there: One in four rural Americans thinks that their lack of access to high-speed internet is a major problem. Spotty internet access is also a problem for moving objects like trains, jets, and ships. Anyone who has tried to use WiFi while traveling can attest to that.
These problems might get resolved soon, however. Starlink, a spinoff of private-sector rocket pioneer SpaceX, is laying the groundwork for more expansive internet access. First announced in 2015, Starlink internet is already available in many parts of the U.S. today.
To ensure that the internet isn’t too slow, the satellites need to be quite close to Earth. Because of that, they only remain overhead for a few minutes at a time. So, the ground-based antennas that they communicate with need to change which satellite they speak to very often. And the satellite network needs to be dense enough to provide the antennas with a signal at any given moment in time.
The network consists of hundreds of satellites; new ones are constantly being added and old ones replaced. As a result, Starlink software lead Andy Bohn says that the team doesn’t have time to put each satellite into its own designated orbit. Instead, every Starlink satellite navigates itself. To manage the busy traffic conditions, the Earth-side network gives each satellite a place to be, and the satellite steers itself into its spot.
This process requires a huge computational effort. First, the satellites don’t only risk bumping into each other. They can also collide with planes and other satellites in low orbit. Starlink satellites are already involved in half the near-collisions in space, where two objects get closer than one kilometer (0.6 miles) to one another, so this risk is real.
Second, the possibility of interference contributes to the massive computational requirements. When the signals of two satellites overlap, they can distort or even cancel one another. Avoiding interference requires putting the signals into slightly different frequency bands. But this isn’t as easy as it sounds, and a finite number of possible frequency bands. Therefore, two satellites with bands that are too similar can’t get too close to each other. This requirement further complicates the satellites’ navigation.
You might wonder why the satellites’ positions need to be calculated on Earth and not directly onboard the satellites. For one thing, if something goes wrong inside a satellite, it’s much harder to go there and fix it. In addition, things go wrong much more often in outer space than on Earth.
Because the sun’s radiation is much stronger outside the Earth’s atmosphere, bits can flip more easily. Bits, the zero-or-one encoding units of all computers, can corrupt entire software programs when they flip their value. To prevent this from messing up a satellite’s trajectory, different machines share software, and a correct copy of it can be reloaded in the event of corruption.
Software at Starlink is written in well-known programming languages. Because of its reliability and capability for bare-metal programming, Starlink uses C++ for most of the code in its satellites. The company also uses Python for some prototyping because it’s generally faster to build in. This mirrors what developers use in autonomous vehicle technology.
Satellite internet is a very ambitious project, and it comes with many difficult challenges. Starlink is undoubtedly the pioneer of this field, but other companies and space agencies are quick to follow. In a decade or two, it might be just as standard as satellite TV is today.
SpaceX, or trying not to fail
Similarly ambitious is SpaceX, of which Starlink is an offshoot. Launching rockets into outer space, docking with the ISS, or aiming for Mars requires near perfection in both hardware and software engineering. Tests can fail, of course. But in the final mission, nothing is allowed to go wrong. And if a part of the rocket system doesn’t work properly, all other parts need to compensate for that failure.
All flight software for SpaceX rockets is built around control cycles. First, all the inputs are read, such as data from sensors or commands from the ground. Then this data gets processed and important things get calculated, such as the position of the rocket or the status of the life support system. Then the program goes to sleep for a fraction of a second, to save compute power, after which the whole cycle starts again.
Different subsystems control different parts of the rocket. In order to prevent big disasters, these need to be isolated from one another. If, for example, something goes wrong in the guidance system that steers the aircraft, the life support system doesn’t need to go haywire as well. If one thing goes wrong, the show must still go on.
This setup differs from how many other tech companies operate. Take Google, for example. They record every failure, select those that seem most important, and try to draw lessons for the future from them. In other words, Google lets failures happen and tries to learn from them afterward.
For Google, this approach works perfectly well. But a search machine (and translator, document editor, cloud service provider, and more) operates a little differently from a rocket. If one process in Google fails, maybe a search query will return eerie results. If a manned rocket steers in the wrong direction, though, human lives are in jeopardy.
Because of the high-stakes nature of the problems it tackles, SpaceX tries its best to never fail. Although the company’s engineers do embrace failure for rocket tests, in those cases, they’re almost purposefully allowing the project to fail in order to learn for the future. When the rocket starts for an actual mission, however, everything needs to work. That means the rocket must remain intact even if a part of it fails.
Testing, testing, and testing code
Rocket software needs to be as reliable as possible. So, it comes as no surprise that the quality requirements are high at NASA and SpaceX, especially compared to regular commercial applications. Elaborate systems are in place to ensure that no one breaks the code by merging something faulty with the master branch. That being said, none of SpaceX’s tools related to testing are unheard of elsewhere in software development.
Before a developer can make a pull request, they need to meet a set of elaborate criteria. Before merging, the code gets tested twice, and it’s tested again after the actual merge.
SpaceX’s continuous integration environment is largely based on HTCondor, and its metadata is managed with PostgreSQL. In addition, the company uses Python for backend test running, build orchestration, and web services. For the front end of these web services, it uses Angular, JavaScript, and some TypeScript. In terms of containerization, SpaceX uses Dockers, along with a little bit of Kubernetes.
The choice of tools and languages is, thus, very similar to what you’d expect in a terrestrial company. Meeting the quality requirements and merging, however, is much more rigorous.
Building software that helps build rockets and satellites
In addition to the software that gets deployed in and around rockets and satellites, spacefaring projects also deal with application software. This type helps bring a rocket to the pad and get it ready to launch and entails areas like supply chain, manufacturing, finance, inventory, and more.
Following the trend across many industries, SpaceX’s application software has shifted from a monolithic architecture to microservices, specifically from AngularJS, C#, and MySQL towards Angular, PostgreSQL, and containerization. The advantage is largely the same as for all the other systems in SpaceX: If one piece is broken or waiting for repair, that delay doesn’t affect the other pieces that much.
What sets SpaceX’s application software division apart from its equivalents in other companies is that they have four very different projects to support: Falcon, which delivers cargo to outer space, Dragon, which focuses on human spaceflight, Starship, which will focus on interplanetary transport, and Starlink, for satellite internet. This scope of projects sets it apart even from NASA.
As in other areas, space tech uses largely the same tools and follows the same trends as others, but the scope and variety of the projects are a lot higher than in most terrestrial companies.
In other words, if you’re a seasoned software developer and you’re considering working at NASA, SpaceX or Starlink, you won’t need to learn about many more tools and frameworks. But you should get prepared for more varied tasks, higher quality requirements, and a more intense workday ahead.
Pe
Space software benefits earthlings too
It’s quite legitimate to ask why we should bother with exploring outer space when we can’t even handle our problems on Earth properly. Amidst an ongoing pandemic, racial and societal inequalities, floods and wildfires, plus all the smaller problems of life, shouldn’t we take our gaze off the sky for a minute?
No. It’s true that every rocket launch burns a horrendous amount of fuel. It’s true that every software developer working on starships is one who isn’t working on an app to beat a pandemic or on a payment processor for underprivileged communities. It’s true that every dollar invested in outer space isn’t invested in fair housing, better education, or preserving wildlife.
Those rocket launches, workers, and dollars come back in other ways. Open-source NASA software, for example, is available to help minimize aircraft emissions, calculate the size and power requirements of a solar power system, or optimize the efficiency of wind turbines. Therefore, by writing code for outer space, some developers just might be contributing to making other sectors greener.
In addition, the rise of private companies in space isn’t necessarily a bad thing. If a small group of wealthy people loses a part of their money by literally shooting themselves to the moon and beyond, so be it.
By developing smart regulations, we do need to ensure that these people don’t colonize space and repeat history. These regulations exist and ensure that no single country calls space their own territory, that every nation is free to explore it, that no entity is allowed to cause harm to space or the environment, and so on. As long as we make sure that these rules are respected, we’re not risking the future of less wealthy humans, we’re not wasting tax money, we can reap the benefits of open-source code, and we can satisfy our human curiosity for new frontiers. Sounds like a win-win-win-win to me.
This article is written by Ari Joury and originally published at Builtin. You can read it here.
[ad_2]
Source link
