Some thoughts on trade studies

When I was an undergrad student at a university in northern Indiana with a penchant for football, Wednesday and Thursday nights were reserved for one thing: homework.

I wasn’t necessarily driven to do homework on those days; it just happened that way. Monday and Tuesday were saved for poring through the week’s material from the various classes. Friday and Saturday were spent braving the wintry tundra with my friends, to go see a movie or go watch the basketball or hockey team play. And Sundays were reserved for my other job, acting as a sports editor for the student-run newspaper.

And so, in the middle of the week, I would toil away in the engineering library — and usually in my dorm room for a couple hours after the library closed — working out homework problems and writing papers. While the tasks could relate any one of a number of areas within engineering, I could always count on the fact that when I solved a problem, I could look in the back of the textbook and find “it”: the one single, absolute answer that determined whether I was right or wrong.

Life does NOT work like this.

I’m not referring to the fact that in life, answers are never pre-determined. In fact, it isn’t uncommon in my line of work to solve a problem only to discover weeks or months later that someone had answered a similar enough question years ago. What I mean is that there rarely ends up being only ONE solution to a problem. There are almost always several solutions to a given problem. In fact, I rarely have come across a case where there are no technical solutions; usually just ones that are unviable for other reasons, usually non-technical in nature.

I wrote earlier about one of the main jobs of a system engineer, developing requirements. Another is leading trade studies, which involve navigating the various options to find the optimal solution that best meets the needs of the project. A trade study draws upon many of the key talents that being a systems engineer requires. They must pull together a multi-disciplinary team, able to evaluate the various elements that make up the system as a whole. They must be able to define the characteristics of an optimal solution, which can be made up of variables that are commonly even in conflict with each other. They must be able to identify viable options from unviable ones, based on constraints and requirements set forth by the mission design. And they must maintain an unbiased view, free of preferences associated with their own knowledge and philosophy. I find trade studies to be one of the most challenging (and enjoyable) aspects of a systems engineer’s job.

One example of a trade study that the Psyche team faced during Phase B involved the power subsystem. During the proposal effort, the team spent well over two years developing a spacecraft that met the unique mission requirements that are inherent in a deep space mission, and yet emphasized low cost and risk. A word that was frequently repeated throughout development of the proposal was “heritage”, which refers to the level of similarity of the unit to previous usage. Heritage is key when it comes to a successful proposal. A project that can claim high heritage can be evaluated to have a lower risk of incidences such as cost and schedule growth, which is very advantageous in the eyes of a review board member. Heritage is not limited to spacecraft components, but elements such as flight software, the launch vehicle, and even how the mission is operated. NASA has a well-defined set of standards on how heritage is evaluated, summarized in the table below.

Within a proposal for a competed mission, the “heritage level” of a given subsystem or unit is defined by several different, yet equally important categories.

For the battery, a unit was chosen that met the very definition of high heritage. It had previously flown in a similar environment on a spacecraft, and had functioned very well. Upon reviewing and analyzing the design of the unit and its specifications, it was determined that practically no modifications would be needed to the unit for the Psyche mission. For all intents and purposes, it was like picking the unit right off the shelf.

After Psyche was selected, we began to sharpen our pencils and run through our numbers again. And over those six to eight months, a lot of things changed. Our potential launch date moved forward by a year. We also had the ability to perform more refined analyses to better estimate eclipse times. As a result, we discovered that our maximum eclipse duration — still a conservative estimate — had increased to the point where the battery configuration that was proposed was no longer sufficient. This didn’t come as a complete shock; it was a gradual change over a period of many months, and eventually it got to the point where the team had to take action. And so, the Psyche team assembled and began to perform a trade study.

Most of the trades that I take part in usually have three steps. In the first step, we took stock of our options, gathering them all together, and not throwing them away. We started with alternatives that we had evaluated way back during the proposal phase. We even gathered options that were not necessarily related to the power subsystem itself. One option, for example, consisted of changing our science operations to reduce eclipse time, thus reducing the time spent under battery power and the associated necessary capacity.

The next step was to start removing the options that were infeasible. By “infeasible”, I mean that there is some issue with the option that essentially prevents us from achieving the mission goals. For example, the option to change science operations that I mentioned above was removed, as it would unacceptably increase the operations time spent in some of the lower orbits at (16) Psyche. There was another option, involving the use of a different battery, which was eliminated as the development schedule was too long. If it was chosen, there was a chance that it could unacceptably delay the spacecraft build, potentially missing the launch period.

After all was said and done, we were left with five options, all related to a change in the battery. Two options involved modifications to the current battery. Another two involved variants of existing batteries that had an extensive flight history on spacecraft provided by our partner, Maxar Space Technologies. The fifth involved using a different battery entirely. All of them were feasible, and most were palatable. As I stated before, there wasn’t a single correct answer for this problem.

This leads to the third step; evaluating the various options against one another. In order to do that, one must come up with a trade-off methodology, which typically consists of various boundary conditions with respect to certain criteria. And, as with most trades involving spacecraft, there are a ton of them. The capacity of the battery is a large one, but there’s also cost, schedule and risk, to name a few. Mass is also a concern, not just for the battery itself, but whatever modifications are required in order for the spacecraft to support it.

Each of these criteria must be weighed, and the weighting is unique to each project. What may be critical for a deep space mission may not be as critical for, say, earth orbiting mission. The level of criticality may even change within a given flight project, as plans change and various other trades are performed. And the people that make up the trade study team may have different views of how critical certain criteria are. For example, the person in charge of keeping the mass budget may hold a mass increase to a higher level of importance than an objective viewer would.

This step invariably results in analyses being performed. In the case of this trade, one major analysis involved determining the battery capacity across various scenarios, particularly eclipses during the Orbital Operations Phase, when orbiting Psyche. As shown in the figure below, during an eclipse, there is a period when the spacecraft will be behind the asteroid, and the solar arrays will not generate power for the spacecraft bus. But in order to perform a bounding analysis, the team had to consider the worst-case scenario. And for us, that worst-case scenario would be if, right at the end of an eclipse, the spacecraft were to suffer an anomaly that would trigger a “safe mode”, in which — again, a worst-case scenario — the solar arrays would not generate power until the guidance algorithms were able to restore the spacecraft to an orientation where the arrays faced the Sun. And just because a spacecraft enters a safe mode, time and orbital mechanics don’t take a break; the team had to make sure the spacecraft has reoriented itself and obtained sufficient battery charge for the next eclipse, which is looming around the next orbit.

A graphical interpolation of the sequence of events that make up the dreaded “worst-case”, bounding scenario. (Not to scale)

This leads to a number of questions to be asked, across multiple disciplines from spacecraft design. For the fault protection group, one needs to know how long it would take to recover from a safing event. For the mission design group, one needs reasonable approximations of orbital durations and eclipse times. From the electrical systems engineers, one needs accurate estimates for the power budget under both nominal and non-optimal configurations. After gathering this information together, one can obtain accurate values for battery state of charge for these scenarios. I’ve included an example of one of those plots below, evaluating safe mode recovery time vs. battery state of charge, for four of the five options we were considering.

This plot shows maximum allowable “recovery time” from safe mode with respect to minimum acceptable battery state of charge (SOC) for several of the options considered.

As it turned out, we ended up going with one of the variants of an existing battery, currently being used by Maxar in their product line. There were some drawbacks to this option; for example, the mass of the battery was more than that of the other options, and its capacity was considerably larger than what was needed. On the other hand, the electrical and mechanical interfaces were relatively clean and well-known, having been flown on several communications satellites. This would help minimize risk during implementation. And in the case of Psyche, our mass margin was enough to accommodate the increased mass of the battery. Admittedly, this is a bit of an over-simplification; in all, there were almost a dozen variables that made up the figure of merit.

This is one of a number of trade studies that the Psyche team has performed over the last few years, as the project progresses through Phase B and into Phase C. In the meantime, feel free to shout out questions about trade studies, or anything else about Psyche that you’re curious about.