Building Clarity Series: Daedalus Part 2
Preface:
It would be a test of patience to list out all the adjectives that can be used to describe the past year, but "calm" would not be on that list. (Ironically, this year's also been the most fun I've had in a long time).
The past few weeks have been turbulent to underemphasize the situation and with the troubles brewing on the horizon, I've had to work with an extremely compressed schedule.
When time is a luxury, I do what most people do and prioritize.
As a result, the weekly publications took a backseat to commitments at Boeing and building ManuSight.
However, I did find time this weekend to pen the next article in the series.
Recapping what the last article talked about, the goal was to explore how product and process complexity drives inefficiency. For this, we started on a journey to try to design a satellite catapulting system that can place swarms of repair sats in select orbits around the Earth (and potentially Mars).
Now, you should be asking why?
Yes. Why?
Just because I said I want to catapult satellites into space doesn't somehow magically make it the right thing to do.
I've spent my whole life (and will continue) going left when everybody went right and so asking "why?" comes naturally to me and so this article will set the stage on the "why?" as well as set up ManuSight for requirements tracking.
First Principles
I was in Detroit a few weeks ago to check up on family and on my flight back, had a 8 hour layover in Chicago. Finding a way to pass 8 hours in an airport's not very difficult but I was tired so I found a small café, ordered a macchiato and just sat there for 8 hours, watching people walk by.
It's amazing to realize that every individual that you see, whether on your drive to work, at the grocer, at the library, at the gym, has their own story that is unfolding. A story that is as intricately detailed as your own.
It's easy to forget that. The human brain tries to simplify everything. Every person soon boils down to a feeling, good or bad.
This simplification, an evolutionary trait to save mental processing power, can have disastrous effects. Wars have been fought (and millions dead) because people failed to understand each other and assumed to know the intent of the other party. I too am guilty of making such assumptions at critical junctures of my own life.
This morning, I was reading an English translation by Stephen Mitchell of Lao Tzu 's Tao Te Ching and stumbled on this:
Savor this.
It speaks volumes on understanding why simplifications, or more precisely assumptions, can be the death of all things right. They attempt the impossible: to reduce the infinite nature of what surrounds us into a quantifiable statement.
When I wrote that I was going to catapult satellites, I'm willing to wager that a fair few readers scoffed at the statement.
A friend of mine told me how ridiculous it sounds but on probing for his justification for saying so, he replied that "we’ve always been launching stuff on rockets".
I embrace first principles thinking and so, to me, precedents have little value except to indicate what has worked in the past (which, too, must be respected).
So let's go back to first principles and in this case, that means keeping an open mind.
Energy is Nature's Currency
Let me ask you this:
Given the choice of launching a 5000 kg mass from the surface of the Earth as a projectile versus using a liquid propelled rocket, which consumes less energy as a function of an altitude? What about 10000 kg? What about 50000 kg? What if the local gravity is less?
If you look around you, you are in a well. A gravitational well.
Space time warps around you and situates you in a divot that you can't escape from without paying a toll.
The toll is paid in the form of energy.
All things ideal, the toll would be the same but all things in nature operate inefficiently and so depending on how you do something, the toll you pay maybe 1.2x more or 12x more than what it should take in an ideal situation. Now, since nature only understands energy as its only currency, it’s in our best interest to get things done using as little of it as we can.
So when I wrote the last article, I wanted to answer the question of how the energy versus altitude profiles looked like for a projectile versus a rocket and which one's more economical.
领英推荐
Shown below are the graphs of the comparison. For the curious, the Python script used to generate the plot can be found at the end of the article.
Targeting for the lower end of exhaust velocities, assuming a methalox engine, the family of curves indicate that there is a break-even point on the total mass that needs to be delivered to a certain altitude. Constraining altitude, we can see that the energy profile for a projectile (relative to a liquid propelled rocket) is much less as the delivered mass gets smaller and smaller (the gap between the blue and red signifies energy difference).
Ideally projectile delivery to a certain altitude and then utilizing liquid propulsion to place into orbit would offer the most flexibility. This is exactly what SpinLaunch is doing (they're awesome so check them out!).
Great, so based on the graph, we know there might be a market for mixed launch system (projectile + liquid propulsion). But how confident are we in the math? Lo and behold, we enter the realm of risk analysis.
?
On Risk
Trying new things is risky but the flip side of risk is opportunity, and innovation comes from execution on the right opportunities. But how do you assess risk?
When I graduated college, I used to think analysis was the holy grail of engineering; that those tasked with executing FEA analysis with fancy heat maps of stress contours were "living the life". Then reality hit when I saw how detached most analysts at engineering firms are from the product. Most FEA results end their lives on a PowerPoint.
My heuristics have matured: You can either drown 1000 hours trying to predict system-level effects in software or just test the goddamn thing until it breaks. I always choose the latter. Test everything (if it's possible). Goal is not numbers but physical product.
Now I steer clear of analysts except in one very specific scenario as Jimbo so adorably points out below:
You can't always test everything on a system level. TPS is a good example. Testing on an individual panel might be possible but to mimic the effects on the level of an entire vehicle would be rarely, if ever, achievable except possibly an uncrewed flight where the loss of the test article/vehicle is tolerable.
In these scenarios, analytical models are intermixed with empirical models to try to predict system-level effects. This is where most firms lose out on the war of innovation.? ?
Often, how a firm goes about reducing risk (e.g. choosing what analytical models to use and the degree of testing to support system-level verification) can determine whether an entire project is a Starliner or a Dragon.
Risk reduction is one of the areas of any business where accumulated knowledge within the business is not a "nice-to-have" but a necessity. The goal is to reduce uncertainty and the ability to use previous lessons learned becomes vital.
This is nowhere truer than when prescribing requirements for suppliers.
Requirements, Requirements, Requirements
Rarely does an aerospace firm own the entire supply chain. Each product developed has lower tier suppliers that make subsystems (very similar to the automotive industry).
The communication between firms on what the needs are comes in the form of functional and interface requirements.
And suppliers take their "shall" statements very seriously. Very. Seriously.
?You can chart out a trend between the cost overrun on a project and the number of requirements it has to manage on the statement of work. The relationship would be exponential.
Most firms take the conservative approach of making requirements that are broad enough to protect themselves. Instead of saying "subsystem shall be capable of withstanding 10 g of acceleration along the body X axis", they will opt for "subsystem shall be undamaged during flight where the following table of acceleration combinations exist". In other words, they will overprescribe requirements.
Sadly, this happens even when the data is available to allow refining of the requirements, but the ownership and visibility of the data is buried within the sea of paperwork processed within the organization.
Suppliers, who have to verify these requirements, don't like this and so, starts a war of endless back and forth.
This is where I'm hoping ManuSight can step in to help by incorporating lessons learned into writing better requirements as well as coordinating communication between suppliers for quicker consensus on requirements. This is only one of the use cases of ManuSight but the one I will focus on for this series.
As shown below, I've imported the requirements from the previous article into ManuSight. The next article will show how ManuSight incorporates different data sources and defines dynamic properties for each of the entities shown below. This allows it to dynamically update requirements as new data pops up and allows the functional baseline to track changes in parent entities.
Appendix
import numpy as np
import matplotlib.pyplot as plt
for add in range(0,3):
ve = 2000 #Exhaust velocity is an assumed quantity (in m/s)
Mf = 5000+2000*add #Final mass at detach point. In kilograms.
g = lambda h: 9.81 if h > 200 else 0 #Local gravity. Variation ignored for preliminary analysis
C = 891*(0.032)*1000 #Mass energy conversion for liquid propellant system. Methalox assumed. in J/kg
deltaT = 4*60 #Burn time until rocket reaches seperation/detach point. Conservative.
mdot = 650 #Propellant system mass flow rate. in kg/s
Mi = deltaT*mdot+Mf;
CD = 0.5/Mf;
drag = lambda v: CD*pow(v,2) if v > 0 else 0;
V = lambda h,t: (ve*(np.log((Mi/(Mi-mdot*t))))-drag(ve*(np.log((Mi/(Mi-mdot*t)))))-g(h)*t)
h = [0]
E_proj = [0]
E = [0]
steps = 100000;
t_step = deltaT/steps
for step in range(0,60000):
t = t_step*step;
h.append((h[step]+V(h[step],t)*t_step+pow(V(h[step],t),2)/(2*9.81))*(1/1000));
E_proj.append(E_proj[step]+0.4*Mf*9.81*h[step]*1000)
E.append(E[step]+C*t*mdot);
plt.clf()
plt.plot(h,E,label="Rocket (Final Mass (in kg):"+str(Mf)+")",color="red")
plt.plot(h,E_proj,label="Projectile (Final Mass (in kg):" +str(Mf)+")",color="blue")
plt.xlabel("Altitude (in km)")
plt.ylabel("Energy (in J)")
plt.legend()
plt.grid()
plt.show()