Systems Engineering at SpaceX
SpaceX is currently in the press with many successes: In particular, the company has just successfully completed the first manned space flight in the US since 2011, when their Dragon capsule successfully returned two astronauts to Earth on August 2.
As systems engineers, we are particularly interested in how SpaceX approaches systems engineering. This article answers that question.
SpaceX was founded in 2002 and within 18 years has managed to roll out the entire space market? The company has been the market leader in satellite launches since 2017. This certainly has a lot to do with an excellent understanding of the market, but the technology also has to be right. And after all, space travel has done pioneering work in systems engineering.
Systems engineering philosophy
In the lecture "System Engineering: A Traditional Discipline in a Non-traditional Organization" (PDF) SpaceX answers this question.
As is so often the case in systems engineering, the Human at the center. SpaceX sets clear values regarding a culture in which reliability and safety have absolute priority.
Reliability and safety are SpaceX's top priorities.
So far, so good. I would be very surprised if other aerospace companies did not wish for such a culture (whether they actually promote it is another question).
The development philosophy is interesting: risk is traditionally managed through excessive up-front analysis, but SpaceX relies on rapid prototyping instead. In the 21st century, we have the ability to develop and test real systems in short development cycles. This involves rigorous testing at all levels - including on the finished rocket, right before launch.
The organization itself must be able to support such an approach. Therefore, in all departments of SpaceX Systems thinking taught and practiced. All departments also deal with the topic of integration. Integration is understood holistically.
Because the handling of information is so important, modern collaboration tools such as Jamaare appointed. Traditional bodies such as control boards and committees are no longer required.
This approach allows SpaceX to make changes in detail without jeopardizing the robustness of the overall system. This leads to sometimes drastic changes in the design:
"Tools not Rules " - "Test rigorously and often"
The V-model at SpaceX
SpaceX does not practice traditional decomposition. Instead, "key design parameters" are identified and tracked up to the design level. A classic design parameter is, for example, the weight of the rocket. This approach allows much more flexibility at the design level. Incidentally, this is the approach that the Valispace tracked.
This approach makes integration and integration testing more important than ever. Therefore, investing in a corresponding test infrastructure is also of strategic importance. SpaceX tries to make the tests as realistic as possible ("test as you fly"). This leads to many hardware-in-the-loop tests at component level, whereby the software is also included whenever possible.
SpaceX also carries out many tests that intentionally lead to the failure of a component. This allows failure scenarios to be investigated more realistically.
It goes without saying that all relevant tests are carried out repeatedly when changes are made.
This approach leads to a spectacularly high number of SpaceX explosions on YouTube, but most of them occurred during tests. So far, only four satellite launches have failed, out of a total of 86 missions.
Conclusion
How much organization and structure does a company need that develops highly complex systems on which lives have recently come to depend? Too little leads to huge problems - there is a reason that the complexity of an organization reflects the complexity of the product. But too much structure leads to a lack of agility - and not necessarily to systems that are more secure. As we unfortunately had to see recently at Boeing.
