from IPython.display import Latex
from IPython.display import Image
from IPython.core.display import HTML
- Both the spoken and the unspoken reasons.
This seems like the right question with which to start this class.
If you read grant applications, you will find all of the justifications listed above for sending something into space. If you talk to the people that write these applications, however, you will very soon come to learn that there are much more personal and much more difficult-to-articulate reasons to go to space. These reasons often and with a dot dot dot (. . .). Examples include:
I've had the good fortune to work with some people that are as accomplished in this field as a person can be. If you spend more than an hour with these people, you'll soon start hearing things like those listed above. You'll hear the same things from students in this field. However, it seems to me that people are generally embarrassed to say these things. I don't know exactly why that is, but I suspect that it is because these motivations are very hard to justify, and smart people don't like to say things that they can't justify.
I'm saying these things at the start of this class to assure you that you don't need to be embarrassed about those feelings in this class. They are shared by me, and by your classmates.
I'll mention also that if you are trying to articulate some of these feelings (i.e. if you're trying to find the words to explain these feelings), go to literature. This is why literature exists. Good literature and good art articulates those feelings which you can't find the way to express. So, if you're trying to explain your interests in the unknown to yourself in words, you might consider seeking out literature about exploration and the unknown. My favorite in this category is Moby Dick. There's a particular line in that book that articulated a feeling that I'd had for a long time, perhaps it will do the same for you.
This is spoken by Ishmael, explaining why goes to sea:
I have an everlasting itch for things remote. I long to sail forbidden seas, and to land on barbarous shores.
In order to get into space, you must go up at least a few hundred km, and then you must accelerate to ~7.5 km/sec. We use rockets in order to obtain that energy, but rockets are incredibly inefficient.
A tremendous amount of propellant is required in order to achieve the required $\Delta V$. Most space systems end up being close to 90% propellant by mass, which means that most of the energy (propellant) is spend accelerating propellant.
Then, once you're in space, surviving there is hard! Because this has historically been such an expensive destination that requires such specialized equipment, it has become characterized by small markets, unique parts, and labor-intensive processes. This might be beginning to change with the advent of smallsats, but space is still a tough place to get to.
This class is called Spacecraft Technology and Systems Architecture. It might alternatively be titled "How to Design a Spacecraft," since that's essentially what we'll be discussing throughout this semester.
This course exists because the spacecraft design process, and spacecraft themselves, are both sufficiently different from other engineered systems to warrant separate consideration. These differences are a consequence of the environment in which spacecraft and spacecraft design take place. By "environment" I mean both the literal space environment, which is unique, and the political and funding environment, which is also unique. Both of these factors lead to machines which not only look and behave differently from terrestrial machines, but that must be designed via processes which are specific to spacecraft.
Of course, there are plenty of ways in which spacecraft are similar to other engineered systems. Like nearly every other complex system, spacecraft are considered in terms of subsystems. We divide spacecraft into smaller systems, each of which with a specific set of responsibilities. The power subsystem is responsible for gathering and distributing power throughout the spacecraft, telemetry and command is responsible for maintaining a communication link with ground operators, attitude control is responsible for orienting the spacecraft, etc. We similarly divide cars, human bodies, computers, and other complex systems into subsystems. This makes designing and considering the collective system more manageable.
Much of this class will be spent walking through each of these subsystems. We'll consider the spacecraft one subsystem at a time until we've considered each individual component of the collective. Specifically, we'll consider power, communications, thermal, structures, attitude determination and control, guidance and navigation, avionics, flight software, ground segments, and launch segments. We'll also consider some additional subsystems required for specific mission types, like life support and entry descent and landing.
For each of these subsystems, I want to do the following. If there is a fundamental equation, or a set of fundamental equations, at the core of that subsystem, then we'll go over that equation. For communications it's the Shannon-Hartley Theorem, for propulsion it's the Rocket Equation, for ADCS it's Euler's rigid-body equations, etc. We'll take a look at the first principles for that subsystem. Then, I'll discuss conventional strategies for meeting the responsibilities of each subsystem. We'll discuss reaction wheels, thrusters, radio communication, etc. Then, because this is a university, we'll discuss some of the more cutting edge strategies that we can expect to become more common in the coming decades.
Perhaps obviously, based on the topics I've just listed, this is a breadth class as opposed to a depth class. For each of the subsystems that I just listed, one could take a semester-long course (or more) and read multiple textbooks on associated topics. The goal of this course is not to become expert in any particular subsystem, but instead to understand how each subsystem interfaces with the others, the responsibilities of each subsystem, and how each subsystem fulfills those responsibilities.
In summary, the course objectives are:
When learning abstract concepts, I've always found that it's good to have a concrete case study to which those concepts may be applied. With that in mind, this course involves a semester-long project with milestone due dates throughout the semester. This project is described in the syllabus, and I'll talk about it in some more detail at the beginning of the next class, after you've all had the opportunity to read about it. In short, you'll be working in small groups to design a spacecraft for one of five possible missions. The hope is that as we discuss each topic or subsystem, you'll be listening with your particular mission in the back of your mind.
For the rest of this lecture, I want to introduce many of the topics that we'll cover throughout this semester through a case study. I am going to consider an actual spacecraft, and we'll walk through the requirements and subsystem-level design for that spacecraft. I'm not only doing this to give you a sense for what this class will be about, though that is part of it. The other reason is that I think it's extremely important to start a class like this with the big picture.
Many of you have likely had the experience of working on a complicated task, getting buried in some minutiae, and losing track of the big picture. Have you experienced that "wait, what am I even doing?" moment? As you go into the weeds to figure out some technical aspect of a complex problem, it can be easy to forget the larger problem that you're trying to solve. That's a problem that you learn to avoid by stepping back now and then and reminding yourself of the larger goals. This is important to do for yourself, in order to keep yourself motivated and working on the right problems. It's also extremely important to do as an engineering manager. You'll find that as soon as an engineer loses track of why what he or she is doing is important, and how it fits into the larger picture, the productivity and motivation of that engineer plummets. Many of you will end up managing engineering projects, and you'll find that much of your time is spent reminding engineers how their tasks fit into the larger goal.
With that in mind, I want for us to start with the larger goal. Then, as we get into minutiae throughout the semester, we'll have this big picture step back and remind ourselves of. We'll do a couple more of these case studies throughout the semester. Hopefully stepping back like this gives us all some immediate context for why each of the topics that we'll discuss is important. With all of that being said, let's consider our spacecraft of interest: Cassini.
I chose Cassini for its familiarity, and because it's an example of an extreme success. I think you're all likely familiar with Cassini, so I won't spend much time introducing the mission. In short, Cassini was a mission to Saturn and the moons of Saturn. It launched on October 15, 1997 and last contact was September 15, 2017, almost 20 years later. In that time, it did the following:
It was, by all measures, a radical success. It was a success because of its design, and the process by which it was designed. Let us take a look at that process and that design. And then, because I can't help myself, we'll take a few minutes to look at some of the photographs that Cassini sent home.
The design of a spacecraft starts with very careful articulation of the requirements for that spacecraft. The requirements come first, before any aspect of the spacecraft itself is even considered. Then the spacecraft is designed in order to meet those requirements. We can draw a loose analogy to test-driven development in software engineering. In test-driven development, you write a series of unit tests for your software before you write the software itself. Then, you write the software and see if it passes the unit tests. When it passes all unit tests, then you know that your software is as complete as your unit tests are thorough.
In much the same way, we articulate a series of requirements, and then we consider our spacecraft design complete when it meets all of those requirements. The requirements come first. Spacecraft are pure function. Every aspect of their design and their appearance is a pure consequence of meeting requirements put in place before any aspect of the spacecraft was designed. The Hubble looks like the Hubble so that it can point very accurately and very quietly, and so it can accomodate a large optical payload. Voyager looks like Voyager in order to meet its own requirements. And Cassini looks like Cassini because of the requirements that it was designed to meet.
There's a subtle point buried in this. Spacecraft are always means to an end, there are never the end in and of themselves. Every spacecraft (to date) is launched in order to perform some task of scientific, commercial, or military value. The spacecraft design is entirely in the service of that goal, nothing else. This is true of a lot of other engineered systems, but by no means all of them. Consider cars, for example. Clearly some aspects of the car are ends in themselves. If cars strictly existed in order to get us from A to B, I argue that they would look quite different. There's an artistic element of some cars that enters into the equation, that doesn't enter into the equation for spacecraft. It's interesting to think about what spacecraft might look like if such things did factor into their design.
We're going to spend an entire lecture discussing how to write these requirements. Requirements are derived from stakeholder objectives. In the case of Cassini, there were many stakeholders. Many of the requirements came from stakeholders that were scientists, however. These objectives may be a bit fuzzy, but requirements are:
Here are some examples from Cassini's Phase A report. This report contains a very large number of scientific objectives, a few examples are given below:
Cassini's Phase A report includes a long list of scientific objectives at Saturn, the icy moons, the Jupiter flyby, Titan, and cruise. These objectives, you could say, are the point of the mission. From these objectives, we derive a series of very specific requirements for the spacecraft to meet. Again, the Phase A report contains a long list of these, I've only included a handful below as examples.
And many, many more. This is how Cassini's design began. We begin with objectives, turn those into requirements, and design our spacecraft based on those requirements. With that in mind, let's take a look at Cassini's design.
Image("Cassini.jpg", width=800)