For this user story, we’ve interviewed Benjamin Howard, an Engineer at Nonprofit Spaceship, to find out how their agile aerospace approach is helping them design a small spacecraft for exploration.
- Industry: Space
- Location: San Francisco, USA
- Employee count: 10
We know that you are currently still operating a bit under the radar, but what can you tell us about the vision at Nonprofit Spaceship?
We are undertaking a series of space science and exploration missions that are accomplished via small spacecraft.
What makes us a bit unique is that we are a non-profit organization, so our funding comes from donors who have a shared vision with us and who want to do space science and exploration in a way that it is encumbered by commercial interest.
Our team comes primarily from bay-area aerospace backgrounds, having worked at companies that would consider themselves to use an “agile aerospace philosophy”. What that means for us at nonprofit spaceship is that we are intending to iterate on the spacecraft designs and accept that early spacecraft may not work as anticipated.
By actually incorporating this learning approach into our plan we can ultimately achieve higher performance spacecraft and get there faster.
That sounds like a very ambitious goal. What do you have to do differently to the typical science missions?
Given that we are iterating on the spacecraft design it is really important that everyone is aware of technical changes as they occur: These may happen during any point of the development, from the early planning phase to later phases when work on subsystems has already begun, or even after our first spacecraft has been launched to learn for its next generation. The combination of this change management challenge and the fact that we are working in a distributed team makes it essential that we have a Single Source of Truth to track the spacecraft design.
How do you organize your agile collaboration for hardware design?
“Agile Aerospace” as I would define it, shares some commonalities with the agile software approach, but is also fundamentally different: In software continuous integration allows you to test and achieve stable versions at a very high cadence. And that cadence may be the same cadence at which you prioritize changes and plan team activities. In aerospace that is just not possible. You will still want some degree of planning on short timescales, e.g. at a 2-week cadence, to allow for changing priorities as new information comes in, but your opportunity to fully test your integrated spacecraft cannot possibly arise every two weeks. So the key difference is having separate cadences for team planning and for full spacecraft integration testing.
As long as one keeps early designs as simple as possible and accepts that while they may not have all the desired bells and whistles they will be a strong frame of reference for subsequent iterations, the agile philosophy can actually work for space.
What have been your reasons to choose Valispace to organize your engineering work?
Honestly, I’ve been waiting for something like this to exist for years. In the past I had just been kludging stuff together; so I was actually super excited to see that someone was doing it.
I have been seeing this as kind of a big void in the software tools offerings for aerospace.
The workflow and tools in Valispace are clearly thought through by aerospace engineers and by people who have been encountering those problems themselves and wanting to fix them.
What do you currently like best about using Valispace in your team?
For me, it is really most useful as a Single Source of Truth for what the spacecraft does and what its bounds are. And what I especially like is that it combines an intuitive graphical user interface with the ability to programmatically access data. So it can easily be adopted by people who want their code to automatically pull the latest specifications, as well as people who want to interact with an intuitive visual interface. And those people can collaborate on the same platform. It is really easy to adopt, because of the multiple ways of accessing the information.
What are your expectations and vision for data-driven engineering?
I think the key is for the tools to be flexible enough to be changed on the fly without breaking things. I would love to have an entire spacecraft and system model that can instantly adapt to any change, but the reality is that the setup of your analysis will have to evolve so that you can respond at different times in the design lifecycle to varying types of questions. While at the beginning of your project, you might make an analysis of how large your battery needs to be as a function of mission requirements, later you might want to switch the direction and understand how the results of the latest battery test will impact the mission outcome.
So your platform and process need to be able to adapt to these new questions.
Do you have a feeling for how much time you expect to save by using Valispace?
It’s funny: I do not think of Valispace so much as a time-saving tool, but rather is a way to avoid a feeling of panic in my chest all the time. Don’t get me wrong: I am sure it will save time.
Having a clear snapshot of the spacecraft that I can be confident is up to date decreases my stress levels significantly.