 I'm Katie. I've developed some software that's running and has run on spacecraft that have gone to other planets, in one case, flying by Pluto last summer, which is arguably still the planet. Anyway, I thought it would be interesting to tell you a little bit about what it's like to program for spacecraft because it's so different from other kinds of programming. So you can conceptualize, if you're a programmer, a spacecraft as a network of embedded computers. And the reason I've made these clouds is because these are functions that a spacecraft does, and you might group them among different computers on the spacecraft, like you might have one computer doing command and data handling, you might have many computers, or you typically have many computers running the scientific instruments, and that code is typically developed entirely independently from the rest of the spacecraft, or you might have a couple of these functions in these clouds being performed by one computer. So just to give you an idea, like there are definitely multiple computers on any moderately sophisticated spacecraft, so what I'm going to talk about applies to most of them. So I'm starting from the very beginning as kind of what was originally a thought experiment for myself, but I think sharing my reasoning, if I kept asking why, again and again and again, I get to the very beginning, which is space is big, we can all agree on that. And as a result, spacecraft that need to explore different things have to go far away. I'm going to be talking about spacecraft that are interplanetary, meaning they go beyond Earth's orbit. And that means, since they're far away, the access is remote via radio signals, and those radio signals can take a long time to get to where they're going. For instance, from the Earth to the Moon takes about 1.5 seconds for a signal each way. To Mars, it can take between 4 and 24 minutes, depending on the respective positions of our planets in their orbits. To get to New Horizons, which is a spacecraft I'm still running, which just flew by Pluto last summer, it takes five hours each way. And the Voyager spacecraft, which are the farthest currently operating spacecraft that we've got, it's 18.5 and 15.5 hours respectively for each of those two spacecraft. So a spacecraft that's that far away needs to be able to act independently, it needs to be able to recover from faults and operate autonomously. Another fact, Earth is a gravity well, which means that space is expensive to get to, or at least it currently is. And when I say expensive, it currently and forever will be expensive in terms of kinetic energy, in the sense that the escape speed is always going to be 11.2 kilometers per second. And we're, of course, we're still using rockets. And there's a really interesting Wikipedia article on non-rocket space launch, if you want to look that up, that goes into alternatives. But for right now, space is expensive to get to in terms of energy and money. So spacecraft are expensive to build and launch. It takes about $10,000 to $25,000 per kilogram to get from Earth just to low Earth orbit. And that is far from getting you to interplanetary space. So launch costs turn out to be a large part of the cost of developing a spacecraft. So I said expensive to build and launch. And I'm going to get into the building part in a little bit. But just to talk about some of the total costs, like discovery program missions like messenger and Mars Pathfinder and Kepler are like a few hundred million dollars. New Frontiers missions like New Horizons are like up to 700 million. And then flagship NASA missions are like two to three billion dollars. That's like the Voyagers Mars Science Laboratory and the upcoming Europa mission. As a result of being expensive, interplanetary missions are rare. And so the people who run them and pay for them are a little averse to risk. So we need spacecraft to be highly reliable and to act very predictably. As a result, we tend to choose real-time, we tend to, we always pretty much choose real-time operating systems and use deterministic languages and techniques. So real-time operating systems, some examples of those are QNX, VX works, Nucleus, RTEMs, RT Linux. So there's a number of open source as well as proprietary real-time operating systems. And the key thing about real-time operating systems is not that they're fast. The key thing is that they are predictable. They guarantee a reaction within a certain amount of time. And timing on a spacecraft can be critical, especially times like if you're firing thrusters to change your trajectory or your attitude, your orientation. If you're using scientific instruments to measure something, you need to do it at the right time, especially if you're moving. You're probably moving pretty fast. And the thing you're measuring is probably not moving very fast compared to you. Or you might need to avoid a hazard. Like if you're flying close to the sun and you have a sun shield, you really, really need to have that sun shield in between you and the sun where you are the electronics. Or else you will die quickly. So you need to operate autonomously and with a very, very guaranteed quick reaction time. So determinism is another important part. And one of the main ways that we achieve determinism is by avoiding dynamic memory allocation after initialization, which it sounds like a big sacrifice to make for a programmer. But we all know that dynamic memory allocation can lead to slow and possibly indeterminate excess times. It can lead to memory leaks. As we just heard, it can lead to heat fragmentation. So we do not use dynamic memory in that way. Another tenet of the Church of Deterministic Programming is avoiding recursion. We use loops that must have a statically determinable upper bound on the number of iterations. We don't use direct or indirect recursion. So you can Google NASA coding standard for more information. A lot of it is simple defensive coding practices. But some like avoiding dynamic memory allocation and recursion are much more about being predictable and deterministic. So some examples of languages we use in order to achieve deterministic code. R C is a big one. Aida, which I haven't personally used. Fourth. So these are languages we've been using for the past few decades or so to program computers that run spacecraft. Another aspect of the determinism is that we need the databases that connect these computers on this network, on board the spacecraft, to be deterministic. If you remember early Ethernet networks, they were subject to collisions and the way you would back off from collisions would be with random back off periods. And the word random is like anathema to deterministic behavior completely. So we couldn't use anything like that. So we have databases and database standards that are not just deterministic, but completely determined. Completely scheduled where every transaction has a time slot that it happens. So everything happens exactly according to a schedule. There are newer standards though, coming out for spacecraft databases that are more akin to modern networks, modern Ethernet and Wi-Fi networks, in that they're full duplex and point to point and packet switch. And so they kind of avoid collisions and maintain determinism that way. So going on to hardware. If you are a spacecraft you probably don't have a lot of electrical power to work with. If you're far from the sun, you need to use non-solar power. And plutonium 238 is in a bit of short supply at the moment. If you Google NASA's plutonium problem, you'll find out about some of the reasons why. If you're on or orbiting a planet, you have nights. You're in the shadow of the planet. So limited power. Other aspects of space that affect hardware, it has radiation. And you'll notice I've introduced a loop into this diagram regarding the market for radiation-hardened hardware, where since spacecraft are expensive to be able to launch, missions are rare, meaning the market for radiation hardware is limited, meaning it's expensive. So we need to resist these radiation effects, especially in the semiconductors and electronics on board the spacecraft. You can't just shield the spacecraft with aluminum or something. The high energy particles don't care about your shielding, basically. So there's a bunch of things to do with physical design, error correcting memory, redundant elements, voting logic, where the memory, there's like three bits for every one bit, and the three bits vote on who's right. Watchdog timers, which are basically like a dead man switch that the processor presses every second or something, otherwise it gets reset. So we select older hardware, which means for software developers, we have resource constraints like the following. So the Voyager missions had a main processor that was 8,000 instructions per second, .008 MIPS, used a digital tape recorder, it did not have an operating system, and it was programmed in assembly language. You can see the stats there for New Horizons, which is the spacecraft that I programmed and helped run, and an upcoming mission with slightly better stats. But of course, if you can compare this to a modern computer or laptop or possibly even your phone, it's not that impressive. But I hope I've kind of explained why that is. The future opensource, reuse, don't have time to go into that, but that is the future.