The following content is provided under a Creative
Commons license.
Your support will help MIT OpenCourseWare
continue to offer high quality educational resources for free.
To make a donation or to view additional materials
from hundreds of MIT courses, visit MIT OpenCourseWare
at ocw.mit.edu.
PROFESSOR: Let's talk about the V-Model, here.
We are-- interesting, we have a little bit of a lag here.
So the lifecycle management is our last topic for today
and that sort of completes the V. And then
next [AUDIO OUT] manufacturing.
So what I'd like to cover today is essentially
a definition of [INAUDIBLE] mean by that,
and then focus on the lifecycle [INAUDIBLE] also known
as the [? ilities. ?] Discuss a little bit
where they come from, how much we know about them.
The bulk of the discussion is going
to be a case study called Reconfiguration
of Communication Satellite Constellations.
And this sort of explains the idea that system,
once you brought a system into operation, that's
not the end of the story.
The system is going to continue to live and change and be
modified over its life.
I'll try to summarize some of the key concepts
over the whole semester.
And then I have one slide on career and study
recommendations, if you want to go further
into systems engineering.
So lifecycle management.
So this is my definition of what lifecycle management is.
It's essentially the active engagement of-- it's the active
engagement of all the stakeholders with the system,
between the time when it starts to operate--
so you've done the commissioning,
you've done the operations--
until you decide to decommission and retire the system.
So it's during the whole operation life.
And what you want to do, is you want
to maximize the value that you gain
from the system's existence.
And so life cycle management starts
from the very, very, very start.
And so I listed here some activities
that are included in lifecycle management.
So obviously daily operations, you know monitoring,
is the system working as expected?
Training and certification of the operators.
Sometimes, you know, in long live systems,
the people who were the early operators, generation one,
are not necessarily the people who are going
to operate for the whole life.
So you have to have new people operate.
Maybe one of the most extreme examples of that
is an airplane known as the b-52.
Have you heard of this?
This airplane might be the first plane that actually has
a 100 year operational life.
And there are apparently Navy--
Air Force guys at MIT, you can confirm this,
that there's actually like--
the grandfather was the first generation
and there's like third generation pilots now flying
on the b-52.
That's what I've been told.
Did you hear this as well?
AUDIENCE: Yeah, That's correct.
PROFESSOR: Do some of these people?
AUDIENCE: No, I've never actually worked
on that airframe.
PROFESSOR: OK.
But anyway, so that's what I mean
by [INAUDIBLE] not just the initial operators,
but over multiple generations.
Then the third thing here is servicing.
And servicing comes in two flavors,
of preventive maintenance, you know
regular maintenance, and then corrective maintenance,
which we also call repair.
Dealing with small and large failures, recalls, anomalies.
This is a big deal in the automotive industry,
as we know.
Increasingly protecting the system
from either random or targeted attacks.
Cyber, physical, right, physical security but also cyber
security is becoming a huge topic.
Sharing and archiving the data that's
being produced by the system.
More and more systems produce larger amounts of data.
Well, what do you do with it?
How do you store that data?
Upgrading and retrofitting the system as needed.
So retrofitting means we're physically
changing the configuration of the system--
right?-- over its life to add new capabilities.
And upgrading; upgrading can be done sometimes
without having to change the hardware.
So you're doing a software upgrade, or software update,
software patching.
All of this would go under upgrades.
Cross strapping the system with other system
in a federation of systems.
So what I mean by this is a system
may have been designed just to operate on its own,
but now you're connecting it with another system.
This happened, for example, the electrical grid.
Right?
The early electrical grids were local, regional power grids.
And now we've connected them, in the US
we have three major grids, the eastern, the western, and then
Texas has its own grid.
Texas does a lot of its own stuff.
It's called ERCCOT.
And then here in Europe, you know
the European electrical grid is now continental-wide.
It didn't used to be.
And of course, that has big implications for operations.
Reducing the resource consumption
and environmental burden of the system over time,
and then finally, decommissioning
the system when it's time to do so.
And in many systems, this is a big challenge
as to finding when is the right time
to decommission the system.
And that's often the case when, you know,
the operating costs exceed the value that the system delivers.
So this is a pretty long list here.
And a lot of tasks, a lot of decisions to be made.
Any questions about this list?
I don't think it's complete, but this
is a lot of things you need to take care of during operations.
Here's a more graphical view of this.
So this is my sketch of the systems engineering lifecycle.
So this is part one, right?
Conceptual design-- conception, design, and implementation.
You start the lifecycle, you do something like a system
requirements review, understand the mission, the requirements,
the constraints.
You do conceptual design, that's where you do creativity,
architecting, trade studies.
As a PDR, you choose--
so in this case, you know, we're going
to go through this triangle concept
and then you design all the details within it.
That's where we do modeling, simulation, experiments, MDO.
And we iterate-- sometimes you have
to iterate this [? dashed ?] duration means
abandoning the concept you chose and go for a different concept.
That's usually undesirable.
After the CDR, we implement the system,
we turn information to matter, and this all
happens in a technological, economic, social context.
So then, the second part of it, which in many systems--
if this is 10 years, this could be 30 years or more--
is the actual operational space.
So the system has now been tested, validated, verified,
and deployed.
And now, you know, we operate the system.
Things break, we need to service it, and then I have this--
you see, there's two versions of the system.
One is solid, and the other one is kind of faint.
That's the virtual version of the system.
So one of the big concepts that's being pushed now,
certainly in the US by the DOD, but also other places.
Is the idea of a digital twin.
The idea of a digital twin is that there's
a physical system--
right?-- that exists, and then there's
a digital version, a digital twin of that system,
somewhere on a computer that mirrors exactly
what the real system is doing.
So if something breaks on the physical system,
well that same component fails in the digital twin.
And then, before you actually do a repair or any actions,
you execute those actions on the digital twin
to see whether the system will operate properly.
And so this is kind of the latest thinking,
is that for any system we should have a digital twin doing
operations.
Upgrading the system.
So in this case, we're adding things to it,
we're connecting it.
You know, and then at some point, the system does degrade.
Because, for example, you know, materials, age,
they get brittle.
Technology becomes obsolete.
You know, it gets harder and harder to maintain spare parts
or the suppliers of the original spare parts
went out of business.
So these really old legacy systems
can be very expensive to operate.
And then at some point you liquidate
and it's the end of the life cycle.
So I've already told you about one example of this,
which is the space shuttle.
And so I'm not going to belabor this again,
but I think it's a great opportunity to learn.
The space shuttle had a 10 year design life, roughly from 1971
until '81, first flight.
And then we operated the shuttle for 30 years
and we had a total of 135 launches during that time.
We spent $192 billion dollars on the shuttle program.
And if you average that, it's $1.5 billion
per flight, which is a lot more than was planned.
But just yesterday here at the EPFL,
we had the annual meeting of the Swiss Space Center.
And one of the astronauts here, Claude Niccolier
and his colleague, Professor [? Mehron ?]
gave a great talk about the Hubble
and the servicing of the Hubble and the amazing things we've
learned through it.
And you guys at MIT, Jeff Hoffman,
was part of at least the first servicing mission as well.
So there's incredible things that were done by the shuttle.
And so I think we need to acknowledge that, not just
the fact that it was very expensive.
It accomplished great things during its life.
But you know, if we had a chance to do it again, would we--
would we come up with the exact same system,
would we make all the same design decisions?
You know, we lost two of them.
Probably not, we could probably do something-- something
different.
So here's what we wanted, and then finally, we
got a much more complex system in the end.
And particularly my sense is that a lot of the things that
made the shuttle expensive to operate during its life
were things related to maintainability.
Right?
Reliability and so forth.
So the lifecycle properties, which I
want to talk about next.
So I'm just going to repeat the questions,
so you guys can hear as well.
So the question was about reusability.
So the shuttle was--
the orbiter was fully reusable.
The external fuel tank was not reusable.
Right?
And then the solid rocket boosters
were partially reusable because they
had to be stripped down, you know,
and rebuilt, essentially, for every launch.
The idea of Blue Origin and then Space-X Stage One,
flying it back to the launch site,
is absolutely the fact that if you can make it reusable,
then you can amortize the capex in that element
over multiple flights.
And it should drop, you know, the cost
by a factor of five or 10 or more.
Now, the devil's in the details, right?
So if you start and restart an engine multiple times,
you can have a big transient every time.
So was this system, in fact, designed
to withstand these transients?
Can it handle multiple starts?
What does it do to the materials?
And so forth.
And so to really model this ahead of time,
and then test it over the cycles is the key.
So in the shuttle, the big problems-- the two
major subsystems in the shuttle, in the orbiter,
in particular that made it expensive
and the difference between the top picture
and the bottom picture was a, the TPS, the thermal protection
system.
You know, every tile has hit a different curvature
in geometry, so really inspecting every tile,
replacing tiles, making sure that the TPS--
because just one weakness in the TPS
could basically be fatal on re-entry.
And so, TPS was very difficult and--
you know, as opposed to an ablative heat shield
that you just sacrifice the heat shield completely.
And then the other was the main engine--
the shuttle main engine.
Originally, the idea was to only do very deep inspections
and disassemble-- the disassembly of the shuttle
main engine after the first few test flights,
and then fly multiple times without having to really
re-inspect or disassemble the engine.
So they did the disassembly of the engines
after the test flights and then they just
kept doing it for every flight, where the original intent was
to only do it for the test flights.
And so the shuttle main engines were the second big cost driver
in operations.
So re-usability is a great idea, but to the degree
to which re-usability actually happens
in reality, that's really about detailed design decisions
you make.
OK.
So let me move on then.
When it comes to really understanding lifecycle,
I do want to point you to the 15288 standard, which
is the ISO 15288 standard, which has a fairly complete list
of system lifecycle processes.
So this is, essentially the system and software
engineering, system lifecycle process standard,
that has a whole range of processes that are described
in quite some detail.
And they're not just the technical processes shown here
on the right side, we focused a lot on those technical
processes in this class, the stakeholders, the requirements,
the architectural design-- which is essentially the conceptual
design--
but there's also the project processes, right?
Executing the project agreement processes.
So this would be negotiating contracts,
you know supply contracts, acquisition contracts, and then
all the organizational things you
need to do to create the right organization to execute
these projects.
So what's nice about the 15288 standard
is that it's a pretty broad standard.
OK.
So let me talk about the ilities of the lifecycle properties
in particular.
What they are and how we can describe them and how,
especially how they relate to each other.
And so the paper that underlie this
lecture that you need to get some more detail.
And this is one of them.
So this paper is called Investigating the Relationships
and Semantic Sets Among Lifecycle Properties.
And we published this about three years ago in Delft
at the CESUN Conference.
So the background on here is the following,
is that as you've seen, complex engineering systems
live for decades--
some of them even for centuries--
and the ilities-- by ilities, we mean
properties of systems that are not the primary functional
properties.
In software engineering they're often
called nonfunctional properties.
And the thing that's tricky about the ilities
is that you often only can observe them during operations.
So you know, you can test systems in the short term,
you can see does it work?
Does it fulfill its function?
But whether certain ilities are present,
it often only shows itself over time.
And so most of the research that's been done
and sort of quantifying the ilities,
has been looking at these properties one at a time.
So the questions we wanted to go here,
wanted to answer is, which of these lifecycle properties
are more prevalent than others?
You know, the top 20.
And then especially, what's the relationship
among lifecycle properties?
Do they form what we call semantic sets?
And then how could you use this information?
And so here, we're going to do this
using two different methods.
The first method is what I call prevalence analysis.
We're going to look in the literature and on the internet,
how frequently these lifecycle properties show up,
are mentioned, how much we know about them.
And then the second method is a cognitive method.
Where we ask people to give their understanding
of the lifecycle properties and put them into a hierarchy,
and then we'll compare the results.
So here are essentially the results
from the prevalence analysis.
And this is ranked according to the number of journal articles.
This is scientific papers written,
where this particular key word, by quality or reliability,
shows up in the title or in the abstract of the paper.
And you can see this is in units of thousands.
OK?
So quality is number one.
Right?
Quality is number one.
The most scientific papers are written about quality.
And you can see, it's almost a million journal articles.
This is-- I'll show this to you over time,
but since 1884 is the first year.
And the databases that we use for this are called it's
Compendex and Inspect.
These are actually combined-- if you
go to a website called engineeringvillage.com,
this is sort of a master database for scientific papers
and engineering.
That was the basis for this.
Number two, reliability.
Number three, safety.
Then flexibility, robustness, and so forth.
And the other bar, the gray bar, is if you Google essentially
for this particular keyword and-- you know, keep in mind,
this was done about five years ago--
this is the number-- the millions of hits
that you will get.
And, so you know, there's a factor
of 1,000 difference here between journal articles
and hits on internet.
But still, you can sort of compare the two.
And so, in some sense, the black bar
is the totality of scientific knowledge
about this lifecycle property.
And then the gray bar would be the amount of information
or uses--
usage of that knowledge, at least as far
as it's represented on the internet.
And what's interesting is, in some cases
the black bar is smaller than the gray bar, which
means that common usage is [? leading. ?]
So sustainability would be an example.
Everybody talks about sustainability,
companies have--
they say, our system is sustainable because, you know,
it uses less resources, it produces less emissions.
But the actual amount of scientific knowledge,
the actual amount of research as to what
really is sustainability and how do you design for it,
is actually smaller than the usage.
And then there's areas where it's the opposite.
Like for example, modularity.
Right?
You see that in modularity.
So in the relative sense, academic interest is leading.
We see there's quite a lot of literature on modularity.
In mathematics, you know, modularity and software,
modularity and design, but most people--
you know, modularity per se is not so interesting
and so exciting to the general public.
So keep in mind that for some ilities,
there's an imbalance essentially,
between our understanding of--
the scientific knowledge, our understanding
to be design, how to design for it, and you know,
how frequently at least a keyword is used.
Now here, this is a little bit more--
this is a little bit harder to see.
This is essentially looking at these lifecycle properties
over time.
So what this graph those you know
is starting here in 1884, cumulatively the number
of journal articles published about each lifecycle property.
And roughly what way you can think about this
is that there's some lifecycle property, the top four--
five that we've been actually working on for a long time.
Even safety, you know, there's some interesting articles
in the 1890s about safety for example, in mines.
You know, coal mines.
There's an article about how does
the impact of lighting-- better lighting-- on safety
and productivity in 1890.
And so they show that just providing better lighting,
actually has a dual benefit; fewer accidents,
fewer fatalities, and better production output.
And so that's-- and this was a scientific study that was done
by comparing data in different mines and actually performing
some experiments.
Then you have a group of life cycle properties
that we only started really thinking about and publishing
about I would say, around World War Two.
Such as usability, maintainability,
and my interpretation of this is that especially
during World War Two, a big difference made logistics.
How easy was it was it to use different weapons?
How easy was it to maintain equipment?
It became a huge determining factor
in the outcome of the war.
You know, for example, in North Africa in the North African
theater, you know tanks, trucks being exposed to the sand
and so forth.
So people really started thinking
about the military, started thinking heavily
about the importance of maintainability
in the design of these systems.
And after the war then, a lot of these concepts like usability
and maintainability started spreading
into general civilian life and products and so forth.
The third type of ilities are the newer ones
that we've done research on just since the 70s,
in the last 30 years.
So here in this category I would put things
like sustainability, recyclability, evolvability,
even interoperability-- which means the ability of systems
to connect together and work across system boundaries.
Those are pretty recent lifecycle properties
and we're still actively researching them.
So another way to show this is by essentially making a network
of these lifecycle properties.
And so the way-- this is still all using this prevalence data.
Essentially what you see here is a network diagram
that has these lifecycle properties in a network
relationship.
Let me just explain, so the size of the nodes
relates to how much knowledge we have.
Essentially the height of the bars that we saw earlier.
And then the strength the thickness of the line
relates to the strength of-- really
how closely are these two ilities related.
And the way this is calculated it
is using the so-called 2-tuple correlation.
So you take, essentially, articles that have--
you look at articles that have, for example reliability
and maintainability in the same article.
Right?
And then you divide that by the total number
of articles on reliability and or maintainability.
And that's a ratio between 0 and 1.
And then this graph was produced with a cutoff strength of so.
1, right?
So if there's more than 10% of articles
list these two properties together,
then there will be a line here.
And the stronger the line, the thicker the line is,
the more closely, the more often these concepts
are mentioned in the same article
or the same piece of work.
So that reflects the strength of relationship.
Now, what's interesting is when you first look at this,
you don't see much.
But after you look at this for a while,
you start to realize a few things.
First of all, in the center of the graph
we have the classic ilities of engineering.
Quality, safety, reliability, and I would argue flexibility
as well.
Those are the top four that we saw before.
And then around the periphery of the graph,
we have lifecycle properties that are more recent.
We haven't really thought about them too much,
we don't fully know how to design for them yet.
And if you look at them in groups,
I will argue that there are three major groups here.
So the first group in the upper left
is things like maintainability, durability, reliability,
quality, and so forth.
So this is all about, is the system made well,
with high quality, particularly early in its life.
Right?
Then we have a group here on the right, and this is about,
is the system easy to change.
Is it easy to change the system configuration-- flexibility,
extensibility, modularity and scalability, interoperability.
Those are all different sub-flavors, if you want,
of being able to modify the system over its life.
And so that's a group of ilities that that goes together.
And then the third one is resilience, robustness,
quality, safety.
And so this is really related to performance
of the system under different types of uncertainty.
You know, either environmental variability
or failures in the system, and the ability of the system
to withstand, or at least perform--
you know, have good residual performance
even in the face of failures.
So that's, I think, an important way to think about it.
And when you're writing requirements for systems--
like the system should be resilient.
Then this helps understand well, what
are the other properties that are linked to it
and that maybe support that?
OK, any questions here or at MIT about--
this is sort of method one, is get data
about the lifecycle property and put them in relation
to each other.
Any questions?
Johanna, any question there?
AUDIENCE: I have a question.
So is this chart that you have now actually used
in the initial design and like conception [? con-ops ?]
to like try to tease out the interdependencies,
or is it too abstract and just more of an educational tool.
PROFESSOR: It's really at this point--
you know this is fairly recent.
And this was just done in the last few years.
So I don't think this has fully penetrated system engineering
practice yet.
But the point-- the point that I want to make here is that
there's a huge--
there's a huge gap right now between when people
in briefings you know, either at the Pentagon
or at a corporate headquarters say,
you know we want a sustainable product
or we want-- we're a software company,
we do optical networking and we want
we want to have the most resilient design
of the industry.
You know, they'll put that as a goal for the project.
The question then is, well OK, that's fine.
But what does that really mean?
What does it really mean, resilient?
You have to operationalize that definition such
that you can derive from it lower level requirements
that you can actually go and design to,
that you can test for.
So what this helps you to do is understand
what may be supporting--
what are supporting elements that
will be related to resilience.
You know, what are supporting concepts, supporting
lifecycle properties that this property that you're
looking for is linked to?
Right?
So it's an evolution-- you know, we know how to design now
for speed and energy efficiency, and you know,
the sort of things that were really hard to do 20,
30, 50 years ago.
It's pretty standard practice now.
You know, how do you design for optimal interoperability?
We don't quite know yet, but we're finding our way.
And so what I believe is that especially
the lifecycle properties on the outer periphery of this chart,
those are the ones that need more work and those are
the ones that we're really learning how to operationalize.
Does that make sense?
AUDIENCE: Yeah, thanks.
That makes sense.
PROFESSOR: OK, good.
Let me talk about the [? message ?] too.
So this was basically trying to get to-- how do people,
how do humans--
there's semantics, semantics means the meaning of words,
right?
Semantics is the science of the meaning of words.
How do they interpret these lifecycle properties?
And so humans have a deep and possibly varied
understanding of the semantics of these lifecycle properties.
So what was done here was that a list of 15 life cycle
properties, many of them are overlapping with the ones you
saw earlier, were presented and then the challenge was to--
the question that these four groups--
12 participants, four groups--
had to say, is there a hierarchy here?
Are some higher level lifecycle properties are some of them
lower level properties that support these.
So there was a round one, find the parent-child relationships,
describe these.
Interviews, and then the second round.
So here's essentially what was the results of the first round.
So four different groups, so each of them
basically came up with its own version of a hierarchy.
They didn't talk to each other, they
were firewalled from each other.
And in all cases this notion of value robustness
came out on top.
So value robustness means the system should deliver value,
right, to the stakeholders.
Despite failures you know, environmental changes,
so value delivery of the system is the top, the most important
thing.
Then what's different here is how do you achieve that?
So for example, you see group one had
robustness and changeability.
So robustness typically means even
if you don't make any changes to the system, it should continue,
you know, it should be survivable.
It should be versatile.
Changeable means you actually modify
the system over its life.
And then we have lower level properties like modularity
or reconfigurability.
And you know, there were differences between the groups
but not as big as you might think.
So in the second round, as a result of the second round,
then this so-called means to end hierarchy was constructed.
So means means, you know, these are the enabling lifecycle
properties and ends means this is the final, sort of this
is really what you want to achieve.
And so this was the result of that.
So again, at the top we have this notion
of value robustness.
And this is achieved by a combination
of survivability robustness and changeability.
And then these, in turn, are achieved by lower level
lifecycle properties.
And then at the lowest level we have
things like interoperability, modularity,
reconfigurability, and so forth.
And the difference between the solid lines
and the dashed lines here is that if it's a solid line
and these are directed arrows, that
means that three or four out of four groups, right?
So the majority of groups had this
is a particular parent-child relationship.
And if it's a dashed line it means only two out of four.
And if it's only one out of 4, it's not shown here.
OK?
So this is kind of a combined result across the four groups.
So you know, what can we take from this?
So first of all, lifecycle properties
are absolutely critical.
You'll find us in mission statements,
you know, you'll find it in even in advertising.
Right?
A lot of companies say we have we have a robust solution,
we have a sustainable system, we have resilient networks.
So it really is a huge, huge selling point.
It's very critical.
What I encourage you to do as system engineers is
take a critical look at this and say, well how resilient
is resilient?
You know, how many subsequent failures of the system
can you tolerate?
Sustainability; what does that mean
in terms of kilowatt hours per hour of usage?
You have to get down to the details
to start quantifying what these lifecycle properties mean
and compare them among systems.
Despite differences, the two methods that we just looked
at-- so one is the prevalence analysis and the other one is
the human semantic exercise--
despite differences, the high level conclusions were similar.
So some ilities are closely related to each other and form
semantic sets, meaning they're tied together by both
[? synonymie ?] or polysemi relationships.
[? Synonymie ?] means they essentially mean the same--
they're synonymous-- they essentially mean the same
thing.
polysemi means-- it is one word, but it
means you can have possible sub meanings.
Right?
So the idea of groups of semantic sets.
And those groups essentially are robustness--
so this is the ability of the system
to perform its job despite either internal or exogenous
disturbances.
Right?
That's robustness.
Flexible or changeable, which means that you
can modify the system easily.
You know, if you operate the system for a while
and then you realize, Ah, I need the system
to do something else.
Or I need to adapt it, or make it bigger, or make it smaller,
or add some function.
So you would modify the system and that's
flexibility or changeability.
And then resilient and survivable
is very specifically the ability of this system
to continue performing despite failures or attacks.
Right?
That's what resilience really means.
And so those seem to be the big three semantic clusters that we
see in life cycle properties.
And then the third point here is there
appears to be a hierarchy of life cycle properties with two
or three levels.
Where we have the lower level properties of systems
like modularity, for example.
Really your customer probably does not
care about modularity, right?
If you advertise the modularity of the product, some
of the more educated, some of the more technically
savvy customers, they may understand what that means.
But most of your customers really
won't appreciate modularity because it's
kind of a low level form-oriented technical
property of the system.
But what they will appreciate is the ability of the system
to be reconfigured or adaptive for different pieces,
so interoperability, modularity, et cetera
are low level lifecycle properties
that act as enablers of a higher level lifecycle properties.
And so future work--
future work in this area is to both just
to apply these methods to a broader set
abilities, larger group of test subjects and more data,
but also from a practical standpoint
to operationalize better.
How do we write requirements?
How do we actually design for the lifecycle properties
like resilience, flexibility, changeability.
How do you really design it?
So go from the keyword to real engineering
by operationalizing the sub-attributes or factors
in the system.
OK?
So that's a quick summary of life--
you know, I could go on for hours about this.
I'm very passionate about this topic
and I will say that people who have
dealt with large complex systems you know, whether you're
operating the transportation system of a city
or in airline operations, or you're
running the IP infrastructure of a major corporation.
These words, these words are real.
These words are you know, real dollars, real challenges.
This is really where the action is
in a lot of these large complex systems.
OK.
Any comments or questions about lifecycle properties?
What they are, how they relate to each other,
why they're important.
Voelker, did you want to maybe say something?
OK.
All right.
So let me talk about--
try to make this a little more real.
Let me talk about a case study, a very specific case
study about communications satellite constellations.
And this is the second paper that underlies today's lecture.
And so let me give you a little context for this first.
So this work here was originally published about a decade ago,
in March 2004.
And that was a few years after the Iridium and Globalstar--
these the two well known communication satellite
constellations--
had been launched.
And I have to give you a little context, when I first
came to MIT in the mid 1990s, there
was a huge interest in this area of satellite constellations.
You know commercially, scientifically, in fact,
the impression was there were so many applications for satellite
compilations filed, that we're going
to have so many satellites up there you won't even
see the sun anymore.
It was just like thousands and thousands of satellites.
And the Iridium and Globalstar were really
the first two constellations that were fully
developed, launched, and both of them
failed commercially within a very short time,
a couple of years.
And so after this happened the whole market and interest
in satellite constellations collapsed for a long time,
until about two years ago, two or three years ago.
Now people talk about these constellations again.
You know, constellations of [INAUDIBLE],, Iridium Next.
You know, there's sort of new enthusiasm ,
new wave of enthusiasm for constellations.
So this paper, and this case that I want to tell you about
is really about the first wave.
And in terms of the ilities, the one
that that I'd like to explain to you about here
is flexibility and scalability.
Rather than thinking about a system as something
that you design and build all at once,
how do you design a system such that you can gradually
deploy it?
We call that staged deployment approach.
And what's the benefit of that?
So here's some pictures you see on the right side,
this is what the original iridium satellites look like.
They actually use phased array antennas--
and actually both use phased array antennas.
So you have individual elements here.
And by differentially phasing the signal,
you can actually steer the beam.
This was a very new technology at time.
And then the Globalstar satellite
shown at the lower picture.
Here is a little bit of that data.
So both of these were launched in the late 1990s.
Iridium has 66 satellites, Globalstar 48.
Iridium is a polar constellation,
so the satellites go almost directly over the poles.
Globalstar is a walker constellation, so inclined.
Doesn't quite give you full global coverage,
it's about plus or minus [? 78 ?] degrees,
so you can't use Globalstar at the poles.
The altitudes are a bit different too.
Iridium is at 780 kilometers, while Globalstar is at 1,400.
Which-- I know at least one or two of you are working
on the Van Allen--
the Van Allen Belt Commission.
Right? [? The cube stats ?] to measure the Van Allen Belts.
Somebody mentioned that today, who was that?
No?
Did I hear that wrong?
It was mentioned, right?
So who was that?
Arnold, and he's not here.
Ah, see.
So 1,400 kilometers, are you actually pushing,
you're starting to push the lower edges of the Van Allen
Belt. So one of the big, you know, in some sense,
it's easier to be higher because you need fewer satellites
to cover the whole earth.
But the higher you go, the more exposed
you are to the radiation environment.
You get closer to the Van Allen Belt,
so that's the big trade-off there.
You know, the mass of the satellites,
they're between 450 and 700 kilograms, transmitter power,
around 400 watts.
You know, which is not that much, if you think about it,
right?
That's four very strong light bulbs, the old style
light bulbs.
And then what's very different, again,
is the multi-access schemes.
So Iridium used time division multiplexing and Globalstar,
which was supported by Qualcomm, used essentially CDMA.
So you don't chop your frequency band into separate channels,
you use the whole frequency band and then
you use a pseudo random access code
that essentially de-convolves the signal for each channel.
The number of channels, about 72,000,
about 120,000 duplex channels so that you can actually-- duplex
mean you can carry on a two way conversation as opposed
to just be asynchronous.
And then you can see the data rates, quite low,
like per channel.
4.8 or kilobits per second, 2.4, 4.8, 9.6 for Globalstar
it's enough for having a conversation.
And total system cost, Iridium was about $5.7 billion dollars
and Globalstar about $3.3 million.
Not including the cost of the ground stations.
Both went bankrupt relatively quickly after they launched.
However, they've been operating really since then, right?
Since this time.
Iridium Next is currently under development
and is scheduled to launch in 2017.
Globalstar is publicly traded and actually valued
as a company at $1.9 billion dollars.
So they're actually both--
you could almost argue that they were
a decade ahead of their time.
And
I want to tell you a little bit about the story of, especially
Iridium.
So here's a couple of press releases, so things that
have been written in the press.
So look at this one, 26th of June, 1990.
Motorola unveiled a new concept for
global personal communication. [? Bases ?]
a constellation of low earth orbit cellular satellites.
August 18th 1999, nine years later, last week Iridium LLC
filed bankruptcy court protection last investments
are estimated at $5 billion.
So the question is why did it happen?
The technology actually worked quite well, it
was not a technological failure, it was a business failure--
but I would argue a system's failure.
To think about the problem differently,
so the fundamental challenge is to properly size
the capacity of a large system.
So if you're designing, you know,
a car factory, a new power system
and for a future uncertain demand,
it's very difficult to do this because demand is uncertain.
So is it better to oversized the system or are you conservative
and you make it smaller?
Market assumptions can change, right?
In a seven to eight years.
So essentially the v, right?
Like getting back to the v. Each of those two systems,
Iridium and Globalstar, it took them essentially a decade,
almost 10 years-- right?-- to go across the whole v.
And when you make your requirements,
your stakeholders, all the stuff in the upper left portion
of the v, there's so many years that elapse between when you
make those assumptions, you write those requirements,
and when you actually go to market a lot of things can
change.
And that's fundamentally the challenge here.
Just to illustrate this for you, showing some data,
this is cellular this is not space space,
this is on the ground.
Cellular subscribers for mobile phones.
I know this is hard for your generation
to sort of understand this, but we actually
didn't have mobile phones or there were these clunky bricks
in your car.
You know, it's really remarkable what happened.
So look at this data, in 1991 which
is when the system was just being developed,
there were less than 10 million mobile phone users in the US.
It just wasn't-- it was very expensive,
it was just not widely--
that technology hadn't been, the networks weren't there.
You know, so the green bars where the forecasts that was
done in 1991, as to how quickly the mobile user
market would evolve in the US.
So their prediction was that by 2000, a decade later,
there'd be just shy of 40 million users.
OK?
Now the dark blue bar is the actual evolution.
So actually by 2000 you know the US now has 310 or so million
inhabitants.
So by 2000 there were 120 million users.
So the forecast that was done 10 years earlier
was off by a factor of three.
That grounds, the terrestrial mobile networks,
developed three times faster than had been predicted.
Now that's great for the terrestrial people, right?
AT&T and Comcast-- not Comcast, Qualcomm, et cetera.
But the problem is, of course, that because you know ground
based communications was so much easier,
a lot of the market that had been anticipated
for the satellite based communications
was essentially eaten away by this competitor,
by the ground based competitor.
VOELKER: [INAUDIBLE]
PROFESSOR: Yeah, OK.
Can you still hear it, MIT, are you still with us?
AUDIENCE: Yes.
PROFESSOR: Yes, you are.
OK.
Voelker wants to say something.
VOELKER: Actually, the figures that you showed [INAUDIBLE]
and for once, Americans did not look over the pond.
Because at that time in Europe, the GSM systems
came really strong and very quickly.
In the early 90s, you could have already had your Sim card
in your cell phone [INAUDIBLE] and in fact in America
then, you could only buy the telephone with all the Sim card
in-- you had to buy the whole system.
And so as the system was controlled
by the large companies and not by the users,
the large companies, Motorola, thought
that they could impose their satellite
system on the markets.
And in this case, the country to the--
video recorders, hi fi systems earlier, Europe
went much faster than America.
And actually European GSM market--
cell phones, as you know them--
went much quicker.
And then Nokia, which is actually European,
overtook and it took probably the next decade for Americans
to catch up.
So finally here this was, a combination of people
had the product and they just couldn't get in the US.
So they were limited to their own markets,
and not to sell their products to the rest of the world
as they had done in the past.
PROFESSOR: Yeah, good point.
And in fact, you know one of the things that--
I think both Globalstar and Iridium had to do--
and this was a very late decision, just
in the last couple of years here before launch,
97, 98, is to make their handsets dual use.
Like that if you were in an area where
there was a cellular network, the phone
would switch to that because that would be cheaper,
and if you didn't have cellular network
access it would automatically try to communicate
to the satellite.
So there was a lot of--
there were a lot of issues that came up
by essentially the markets, I think in Europe, your point,
well for-- about the GSM, and in the US just
developing quite differently than had been anticipated.
OK so I want to give you a little bit about sort
of economics.
In the end a lot of this is driven by money, by economics.
And so this is satellite economics 101.
The key question here is how expensive is it--
what's the cost, and then what is
the price that you can charge for one minute of service,
right?
One minute, one unit of service.
And so look at this equation here.
This is CPF, stands for cost per function.
And so in the numerator we have the lifecycle cost, which
is your initial investment.
And then we will essentially capitalize
that with some interest rate k.
Plus then, for each year of operation,
you have the operational costs for that year you have to add.
So that's your initial--
that's your development costs, your manufacturing costs
for the satellite, including the launch costs.
And then the ops costs would be operating your ground stations,
your networks, any replenishment costs,
they would be in your ops costs.
And then you divide this by what's
called here the number of billable minutes.
That doesn't mean you're actually going to bill people,
it means just they are potentially billable minutes.
So that's the capacity of the system,
[? see ?] the best times you know, 365 days,
times 24 hours, times 60 minutes,
times what's the load factor.
So the load factor is essentially
the capacity utilization of the system that you anticipate.
OK.
So that's the basic equation for calculating
CPF, cost per function.
Plug-in some numbers here.
These are the numbers that have been assumed,
you know a $3 billion investment, 5%
interest rate, $300 million per year of ops cost, 15 year life
cycle--
this is the capital T, over 15 years.
100,000 channels-- that's your capacity.
Number of users in this case, so the load factor
is simply the number of users times the average activity
per user.
In this case, it seems to be 1,200 minutes per year,
about 100 minutes per month.
OK?
So that gets you--
that gets you a CPF of $0.20 per minute.
And based on that you can-- the business case
was made based on these kind of numbers.
And so 3 million users, just 3 million subscribers, right?
Not 3 million users at the same time,
that number would be much smaller.
That number can't be bigger than 100,000
because that's your capacity.
So for example, if you run--
if you run a fitness club, right?
At any given time in your fitness club
you can have 50 or 100 people actually working out,
but your number of customers, your subscribers,
should be 1,000 or 2,000.
And if they all show up at the same time
you're in big trouble, right?
So that's the difference between number of users
or the number of subscribers and number
of active users at any given time.
That's a big part of managing these kind of systems.
However, what actually happened is the number of actual users
grew much slower.
So if you plug-in some different numbers,
let's keep all the numbers the same,
except for the subscriber base-- the number of users.
In this case we're going to assume 50,000 users instead of
the three million.
This is closer to what they had after about
a year of operation.
Now your CPF goes to $12 per minute,
which is noncompetitive.
Right?
Except for some extremely, like, military applications or making
some emergency phone calls on an oil rig,
you know, on the ocean.
Most people at the time--
now and at that time--
would never pay that for one minute of service.
And so that was the fundamental problem,
is that the user base did not materialize as fast as planned.
Therefore this cost per function was way higher
and they did charge, you know, $3 to $5
per minute of usage of the system, which
as you try to squeeze your existing users more,
you're not going to get the ramp up and scale up in the system
that you need.
That was the fundamental problem with the economics
of the system.
So let me talk a little bit about the design decisions
the conceptual design of what this design space looks like.
So fundamental-- oh, the other thing I should mention to you,
what was interesting is after the bankruptcy, both of Iridium
and Globalstar, both of the chief engineers for both
of these systems took refuge at MIT.
Essentially, they came to like--
Joel Schindall, who was the chief engineer for Globalstar,
great guy, both very competent people, came to MIT--
still there, still a professor there.
And then Ray Leopold was one of the three architects
for Iridium, also came to MIT during the time.
So I had extensive discussions with them,
and what you see here on slide 25
is one result of those discussions.
Which is, the key design decisions
that they have to make, fundamentally, there is--
you won't be surprised to see this,
this is the magic number seven, right?
Seven key design decisions.
When you design a satellite consultation for communication
purposes, constellation type--
polar or walker, orbital altitude,
minimum elevation angle above the horizon--
that you can communicate--
satellite transmitting power, the size
of your primary antenna, your multi-access scheme.
So this is time division or code division multiplexing.
And then the last one is about the network architecture--
do you have inter-satellite links, yes or no?
Inter-satellite links means satellites
can talk to each other.
And Iridium chose that, Globalstar did not.
So in Globalstar, the Globalstar satellites cannot talk to each
other directly in space.
They can only talk--
it's a bent pipe system to a ground station.
OK?
So if you this is like the morphological matrix
that you learned about, you just pick design decisions
in this morphological matrix and you come up
with an architecture.
In fact, a full factorial search of the space
would reveal 1,440 different satellite architectures.
So that's on the input side, what's the output vector?
What do you care about in terms of output of the system?
Well first of all, performance.
So the performance-- this is for voice communications.
In a sense it applies to data communications as well.
It is your data rate per channel, right?
4.8 Kbps, your bit error rate, like
what is the average number of bits that are wrong?
10 to the minus 3.
That's actually pretty-- not a very--
that's not a very stringent requirement.
And the reason is this is for voice communication,
this is not for sending, you know, commands to a spacecraft
going to Mars.
If you send commands, it would have to be 10 to the minus 10,
or 10 to the minus 9.
Much, much better bit error rate.
But this is OK for voice.
And then the link fading margin, 16 DB.
This is the strength of the signal, which
which will dictate whether or not
you can use the phone under trees or in buildings.
So you want this number to be higher, but the higher it is,
you know given the power you have
on the satellite, the fewer channels you have.
So there's trade-offs.
So what was done here is to keep the performance foxed,
and so that you can compare architectures,
compare apples to apples.
Then we have capacity, which is the number
of simultaneous duplex channels.
And then finally, the lifecycle cost
of the system, which includes research development, test,
and evaluation, satellite construction and test, launch
and orbital insertion, and then the operations
and replenishment.
So if the satellite fails in orbit,
either you have to already have prepositioned to spare,
or you're going to launch a replacement.
And this actually happened in both cases,
both constellations.
So in order to then, connect the input to the output,
you need to build a simulator or a model of this system.
And this is a high-level view of what that model looks like.
So we take our input, our design decisions,
and certain constants that we assume-- a constant vector.
And cascade this information from the constellation module,
takes the altitude and the minimum elevation angle,
and produces--
t is the number of satellites and p
is the number of orbital planes, so this
is sort of orbital dynamics.
The spacecraft module calculates the satellite mass,
the satellite network builds essentially the communication
pathways.
The link budget will calculate the capacity of the system.
You know, given those performance constraints.
The launch module will determine how many launches
do you need, from where.
And then the cost module basically calculates
the total cost of the system, the lifecycle cost,
and finally you get essentially a trade-off of lifecycle cost
versus capacity of the system.
Let me just show you some, you know, you say,
well that's tying together a lot of information
into a multi-disciplinary model.
So what kind of information do you have?
You have a mix, really of physics based models--
so this is a very well known equation, the eB/N0, that this
is the energy bit over noise ratio.
This is a closed form physics-based equation that
tells you how much energy is there per bit--
what's the signal to noise ratio on a per bit basis.
And this is a function of transmitter power, receiver
and transmission gains, various losses in the system.
And then some of the equations--
some of the information is empirical.
For example, the relationship between spacecraft
[? wet ?] mass and payload power.
You know, if wanted to have a closed form or you wanted
to have more detail, you would have to almost build
a CAD model, right?
A separate model.
You'd have to-- for each of the 1,440 architectures,
you'd have to manually construct an individual detailed design.
And that's not feasible, so what you do instead
is you use some prior data-- and you can see here
a scaling relationship.
It's not perfect, but we have error bars,
we know how good it is.
Satellite mass, satellite wet mass
is a function of transmitter power and, in this case,
propellant mass.
So two kinds of equations.
Benchmarking.
So once you have this model, you need to ask the question,
how can I trust this model?
Does it give me a reasonable answers?
And in this case, benchmarking the process
of validating simulation by comparing
the predictive response against reality.
So just quickly here, showing you four kinds of data.
So one is the simultaneous channels of the constellation,
this is the prediction of capacity.
You can see it's pretty good.
In this case, the model is actually a little conservative.
So the blue bars are the actual planned capacities.
The red ones or magenta is simulated,
and you can see that the simulation under-predicts,
slightly, the true capacity of the system.
Life cycle costs, you saw that Iridium was just a bit more
than $5 billion.
Globalstar was between $3 million and $4 million.
And so here we're in the right ballpark.
And then in terms of satellite mass
and the number of satellites in the constellation required,
we matched that very closely.
And the reason for this is, fundamentally
this is just geometry.
Right?
If I can tell you the altitude and the minimum elevation
angle, and I'm telling you I need I need global coverage
and I want dual redundancy, so you can always
see at least two satellites, it's
just geometry to be able to figure out how many satellites
and how many orbital planes you need.
And that's why the model, or the simulation,
and reality match very, very closely.
So this gives you some confidence
that this model is reasonable.
So what you can do with it is now
what we call Trade Space exploration.
Which is, in a sense, what you did for the [INAUDIBLE]
competition.
So this picture here, this graph shows you the life cycle
costs over those 15 years, versus
global capacity of a system.
Each of these blue dots represents one
of those 1,440 architectures.
And you can even see on this, where Iridium actual
versus simulated falls and where Globalstar actual
versus simulated falls.
So both of them were actually off the Pareto frontier,
which was interesting and led to quite some discussion.
And you can-- the Pareto frontier itself
was, of course, very useful.
One of the reasons that Iridium is not on the Pareto frontier
is that fundamentally, polar constellations are inefficient.
And, if you think about it, when the satellites are
crossing over the poles, they're very close to each other.
And they're actually not crossing
exactly over the poles, or you could actually collide, right?
So you offset them slightly to avoid collisions.
But some of the satellites actually
get turned off when they cross the poles.
So you're not utilizing your assets super efficiently
in the polar constellation.
Which is one of the reasons why they are not
on Pareto frontier.
Now, the way you would use this in a traditional system
engineering approach, which is traditional system engineering
approach means give me the requirement,
write down the requirements, and then find the minimum cost
design for that requirement.
So a requirement could be we need a capacity of 50,000,
for example, and then you find this intersection
with the Pareto front, and that's
the minimum lifecycle cost design that
gives you that capacity.
Right?
And that's the system you pick, and that's
what you go and build.
And that's essentially what they did.
The problem with this if there is high uncertainty
is, the true requirement is kind of unknown.
The market will tell us in the future what
the true capacity should be.
So how do you deal with this?
Well, you could be--
we're going to be on the safe side, right?
We're going to oversize-- so if the true demand,
the true capacity that you would need,
is higher than what you just had,
your system is going to be under capacity, right?
Your system is going to be undersized
for what it should be.
And so what happens in practice?
What do you think happens in an under capacity situation?
What would you say?
The system is too small relative to the market that you're in.
You're not capturing as much as you can,
meaning a competitor will probably capture.
I mean, I guess you can change your price policy,
but fundamentally, you're missing out
on market opportunity.
The other situation, which is actually what happened,
is that the demand is much less than we anticipated.
Your system is oversized and remember,
once you launch a satellite constellation,
it's not like a fleet of taxis, right?
Where you just park them in a parking lot.
You've already-- the fixed cost is very high.
So if demand is below capacity, you have all this investment
here, lifecycle cost has been wasted because you
oversized the system.
And the challenge is that the true requirement
is kind of like this-- there's this probability, density
function.
Right?
It's a probabilistic requirement, essentially.
And there's no set of experiments because of all
the [INAUDIBLE] uncertainty.
It's not a systemic uncertainty.
There's no set of experiments you
could do today that will help you refine the requirements.
Now they did do market studies, but again those market studies
were years ahead of when the actual system was launched.
So they were unreliable, fundamentally.
So what I'm arguing here is in this kind of system
where you have large uncertainties
as to the true requirements, you shouldn't just
guess and then put billions of dollars on a guess.
This is like playing in the casino, right?
Essentially.
What you should do is think about the problem differently.
And in this case, the answer is staged deployment,
or one of the answers is staged deployments.
So you build a system such that it can adapt itself
to the uncertain demand.
So you build, initially, a smaller, more affordable
system.
But-- and then the system has already
built into it the flexibility or scalability
to expand if needed.
But only if needed.
And there are two major economic advantages to that.
One is that you don't need to spend all the capital up front.
As so you're deferring capital investment.
And you retain the decision freedom to reconfigure or not,
and that's typically what we call the real option.
You've created a real option for the future.
So the question, then, is well how valuable is that?
It is worthwhile doing this staged deployment approach?
So there's probably different ways of doing this,
and I just want to share with you--
and this is from the paper-- how this was done.
So step one is you partition your design vector.
So you basically decide which part of the system
is flexible-- because you can't make everything
flexible typically-- what part is flexible
and what part is fixed, is the base, you can't change it?
So in this case usually the idea is
that the satellites themselves, the design
of the satellite, the transmitter power,
that their protocol, and the network architecture
should be fixed, right?
Those things are difficult to change.
We're going to allow the astrodynamics, the actual shape
of the constellation, to be flexible.
So keep the satellites the same, only
change the arrangement in space.
So what you do is you partition the design vector
into the flexible and inflexible parts.
And when you do this, in step two, what's
nice about this is you can then actually find families
of designs, right?
You can find families of designs where the--
we have a little lag here--
that you can find families of design
that share the constant parts.
That have the common--
So what's shown in this graph here-- this is again,
our design space, kind of zoomed in a little bit more--
every one of these points that are connected with these lines
uses the same types of satellite [INAUDIBLE]..
Same transmitter power, same antenna diameter,
and all of them have inter-satellite links.
So effectively, you're partitioning
the design say into subsets that share common features,
and then we call this a family of designs.
And the idea is to start small, so on the left side,
and then you grow the system over time right?
But only if needed.
So when you do this, you 1440- strong design space turns out
to be decomposable into 40 different paths.
Now, which path would you choose here?
Well you want to be as close to the Pareto front possible.
So this is an example of all of a path.
In this path, if we started on the lower
we would start with 24 satellites
and then we would actually move them to a lower altitude.
And add 30 more in step two, and then you
would gradually grow the constellation over time.
You see that?
This is actually not too different from how
GPS was done, right?
The GPS constellation was deployed in phases,
but it was not market driven, it was just
sort of phasing the development for risk reduction,
and spreading off the capital.
The other thing that's interesting
here is that as you grow the constellation,
it moves further away.
It moves further away from the front.
So when it's small, this particular [INAUDIBLE]
is close to being optimal, and as you scale it
up it becomes more sub-optimal.
And there's other paths that have the opposite behavior;
where when small it's kind of suboptimal,
and as you make it bigger, it gets closer to the optimality.
Pretty interesting.
So that's step two, find the paths.
Step three, you now have to model the actual uncertainty.
And in this case there are different ways
to model uncertainty.
In this case, what we used was a GBM model--
geometric Brownian motion.
This is well-known in physics and applied
to statistics, physics, this has been applied
to the stock market, right?
And the idea here is that in this case,
the man behaves like a particle in a fluid.
Right?
That's kind of moving in an unpredictable fashion.
So this is the basic equation for-- this
is a discrete version of geometric Brownian motion,
you have some trends nu, nu times delta-t,
so this is the delta and demand, or the change in demand,
divided by demand, so this is normalized change in demand,
is nu times delta-t, so your trend times
delta-t plus sigma times epsilon times square root of delta-t.
Epsilon is a standard, normally distributed
random variable between 0 and 1, and epsilon and sigma
is your volatility, essentially.
So here's some examples, if you start
with an initial demand of 50,000,
which is what they actually saw as an initial demand early
on, you have a growth of about 8% per year.
This is your trend.
Plus in this case, a volatility of 40%
per year, which seems high but in this kind of very
new technology, new system, is actually not that far fetched.
You get three different-- these are just three examples of how
demand might evolve.
These are just three scenarios.
So demand can go up, it can go down, and--
GBM is very nice, but one of the downsides of GBM
is there's infinitely many scenarios that you can generate
because it's fundamentally-- even though it's
discretized in time, it's not discretized and in demand.
So a simpler version of this, a more discrete version,
is a so-called binomial lattice model.
So the way this works is again, you
start with some initial demand here on the left
and then you discretize this such that moving through time,
you can look at different scenarios.
Right?
These scenarios could be-- the best scenario
is things just keep growing.
Right?
Grow, grow, grow.
Here, time, the 15 years, have been sub-divided
into five three-year periods.
So here's a sample scenario, demand goes up, goes up,
and then it goes down twice, and then
it goes up again in the period.
And so this is a discretized random walk.
And you can choose the numbers, so the sigma, the volatility,
the amount of the up and down movement, and the probability,
p, of going up, and then the probability of 1
minus p of going down, are chosen such
that they're consistent with the GBM model.
So this model is the equivalent of the GBM model,
it's just discretized.
So the beauty of this is that you can now
simplify this to 32 different scenarios
instead of infinitely many.
And each of those scenarios is not equally probable.
There is actually probability weighted scenarios,
depending on what nu and sigma are that are underlined.
So now we have 40 paths, right?
We have 40 evolution paths of the system
and we have 32 different future scenarios.
So what we do now in the next step, four,
is to put the two together and calculate
the cost of each path.
Calculate the cost of each path with respect
to each of the demand scenarios, look
at the weighted average of all the possible paths, and the one
thing--
the one tricky thing about this is
you need to build in a decision rule.
Such that, if the system--
if demand exceeds capacity the system,
you're going to expand and move to the next stage,
you're going to stage deploy the next phase.
And there's many different ways of doing this decision rule.
So the simplest one was chosen here,
and of course costs are discounted.
So let me explain to you how this works.
So we start the simulation, so the first initial deployment.
This is our initial stage one--
right-- for the constellation.
And then we start operating for two years,
and demand in this period goes up.
You see the ops cost in this case goes slightly down,
this is due to the discounting.
This is a discounting effect.
We arrive at the end of our first three year period
and then the question is here is our capacity of the system.
What would you do in this situation?
Let me ask somebody at MIT, make sure you
guys are still with me.
So what would you do in this situation?
You're now at the end of year three.
Anybody?
AUDIENCE: We lost you for a second halfway
through your statement, could you repeat?
PROFESSOR: Yes, so you've done your initial three years,
you've deployed your initial constellation.
And you now have the situation shown on this chart.
What's the right decision, according to the decision rule?
What's the right decision?
AUDIENCE: OK, I'd keep it the same.
Because--
PROFESSOR: Yes, exactly.
AUDIENCE: --it has not exceeded demand yet.
But prepare to change--
PROFESSOR: Exactly, you wait, right?
AUDIENCE: Because you have to lower your capacity.
PROFESSOR: You keep it the same, you don't do anything.
You just keep operating.
Exactly, right.
So you have another three years, right?
During these three years, demand keeps growing.
And you now, at year six, arrive at this point here.
So what's the right decision now?
AUDIENCE: Can I ask a question about the decision
to stay the same?
PROFESSOR: Would you say the same?
What's happening to the demand line?
Veronica, what's happening to the demand line?
AUDIENCE: Can I ask a quick question first,
about the decision to stay the same?
PROFESSOR: Yes.
AUDIENCE: I feel like by waiting until we've exceeded demand
to choose to expand the constellation,
we're introducing a lag between demand and capability
that creates an inefficiency that may actually drive users
away from the system.
And I see this kind of oscillatory effect, where
you would expand, and then people would meet,
and then the system would be insufficient
and then people would move to a different system.
And you kind of have a yo-yo around the maximum carrying
capacity.
And that doesn't seem efficient to me,
so I'm wondering if you could speak to that.
PROFESSOR: Yeah.
AUDIENCE: So what you're essentially
looking for is what I would [INAUDIBLE] decision rule.
So you would actually--
so the decision here is to deploy, right?
You've got to deploy your second stage because you've
saturated the system.
What you're arguing for is before this occurs,
you know like at 80% saturation, that's
when you trigger the next stage, right?
In order to anticipate the saturation.
And so, absolutely, you could do this.
There are many different decision rules
that you can try when you design a flexible, deployable,
scalable system.
And that's part of the decision space.
So in this particular example, we just
implemented the simplest possible decision rule,
which was when saturation has occurred you do deploy
the next stage, but not before.
AUDIENCE: OK, thank you.
PROFESSOR: Is that clear?
AUDIENCE: Yes, thank you.
PROFESSOR: OK, so we deploy the second stage now,
and you can see there's another spike here-- right-- of capital
that's needed.
It's not as high as the first initial stage,
but it is substantial.
So now as we deploy the next stage,
our capacity went to the higher limit.
So we're now at capacity level two.
We're now operating the system.
Demand keeps growing, that's good.
Now we have year nine, you can see.
But we haven't yet saturated our new capacity.
So again, the optimal decision is--
or I shouldn't say the optimal decision,
but the decision according to the rule
is you just wait, right?
You keep operating.
Ah, now from year nine to year 12, demand starts to go down.
Right?
And this happens in some systems, right?
They are growing and they peak, and then things go down.
So in this case, we wait.
And then in this scenario it goes down again.
You see how that works?
So what's nice about this is you can now--
in this sense, all the 32 scenarios of possible futures,
you can run them against the 40 different families
of designs or evolution paths.
And out of that you can find the best path, right?
This is the path, the path that on average--
I should point out on average-- will satisfy your demand
at minimum lifecycle costs, given the uncertainty models
that you have composed.
Yes, [INAUDIBLE]
AUDIENCE: [INAUDIBLE]
PROFESSOR: Why did it go down?
AUDIENCE: Like, [INAUDIBLE]
PROFESSOR: This here?
AUDIENCE: [INAUDIBLE]
PROFESSOR: No, the capacity stays the same.
You don't go down in capacity.
The reason is-- this is a good question--
this particular system, a satellite constellation
is dominated by fixed costs, right?
So if you wouldn't retire half your satellite,
because then you would lose coverage also, potentially.
Because you've moved them through orbits
that give you the right coverage,
you just increased your capacity.
This is different from a system that
is dominated by variable costs.
Like for example, if you operate a fleet of taxis
and and for whatever reason, demand goes way down,
you can go and park half your taxis
and just not operate them.
You may still have to pay a lease on them,
but essentially you can downward that
the capacity of the system.
You can't do that here, it doesn't make sense.
Right?
So that's the big difference between systems
that are fundamentally fixed cost dominated
versus variable cost.
So in this case, we just don't use it as efficiently
in the last six years.
The answer here is that there's an optimal path, and that's
shown here, that will, for a given targeted capacity,
you can compare essentially this blue path
against the traditional fixed design.
And in this case, the traditional architecture--
fixed architecture-- would cost about $2 billion dollars
to build, both and on average the red point is
the average lifecycle cost of the evolvable system, is 1.36.
Right?
Lifecycle cost of the rigid design versus the expected
lifecycle cost of the best deployment
strategy or staged deployment strategy, which is--
essentially the way that's calculated
is the probability weighted lifecycle
cost of each of the scenarios, right?
Against this path.
And the difference between those two numbers is about a third,
$650 million.
And that is the value of the real option.
That's the value of designing the system with scalability,
with flexibility.
OK?
Yeah?
AUDIENCE: [INAUDIBLE]
PROFESSOR: Yes.
That's true.
So the lifetime-- the question was,
is the life expectancy similar?
Of course-- so the 15 year life of the whole system
is the same for both.
Of course, in the staged deployment strategy,
some of the satellites are going to be younger
at the end of the 15 years.
And so they may have longer residual life left,
which is actually not included.
That's not even included in this real option value.
AUDIENCE: [INAUDIBLE]
PROFESSOR: Right.
AUDIENCE: [INAUDIBLE]
PROFESSOR: That-- that's right.
So you could sort of refine this model to include a more--
a staged decommissions, right?
Or staged transition to a next generation system.
So in this case, in this model, after 15 years--
boom-- you know everything, you just finish.
No more revenues, you just decommission.
A hard end, a hard stop after 15 years.
But you could actually build transition and decommissioning
models as well.
Good point.
So that's essentially the case study
that I wanted to show you.
And, you know, you say that's kind of like in the US
we talk about Monday morning quarterbacking, you know?
You come in and all the football games that happened
and the mistakes that the coaches made,
and I would have done this or I would have done that.
So yes, you know, this is sort of like looking
at this problem in hindsight, but the reality
is that this really has had a big impact and a big dampening
effect and that the new generation of systems--
I think-- are built much more intelligently
with this kind of evolution in mind.
I will also mention to you that Iridium is actually the system
that went bankrupt first.
And the reason for the bankruptcy-- well,
one of the immediate reasons for the bankruptcy--
is because of the way that the project was financed.
So about one third of the funds-- the $5 billion--
one third of the funds for Iridium
came from equity from Motorola.
So that was their own money that they lost.
About one third was an IPO, initial public offering,
you know, shares sold to the public.
And about one third was bank loans.
And these bank loans were relatively expensive
and the banks expect that they get
paid back at a certain speed, depending on the market
evolution.
And it's essentially the inability
to pay for and service their loans, that
caused the Iridium bankruptcy.
And it turns out that the loans were about one third
of the total capitalization of the project.
So what I would argue--
I would argue that if they had done this more flexible,
staged approach, they could have saved one
third, which is about the value of this option
and capitalization, and just build the system only
with equity and with the money from the IPO.
And that would have given them a lot more time,
you know they wouldn't have had to service those loans
and it would have given them a lot more time
to wait for the market to develop,
which it eventually did.
So the whole financial architecture
was poorly done as well.
It's a whole other--
that's a whole other question.
AUDIENCE: Professor, quick question?
PROFESSOR: Yeah.
AUDIENCE: Are there situations where [INAUDIBLE]
PROFESSOR: Yes.
So the question, I'm just going to repeat it
for you guys at MIT, the question was
are there cases where the flexible approach is not
the best?
And the answer is yes.
So for example, if you're in--
I know that you're studying the energy market--
if you're in a situation where you have guarantees,
a guaranteed customer, so the government
or one of the big utilities is entering
into a long-term agreement with you,
that they will buy the power that you
produce at a certain price for the next 20 years.
And so you're not subject to that market volatility,
but you have a long term agreement, including clauses
that say well if the government doesn't do this then
they'll compensate you for any losses,
this is a financial contraction.
If you basically have eliminated demand uncertainty, because
of the particular contractual arrangements,
then there's no reason you shouldn't build the system
for a fixed capacity.
And then you can build something right on the pareto front,
because that particular uncertainty
has been eliminated for policy or contractual reasons.
So, good question.
OK, so we're almost there.
Let me just try to summarize some--
AUDIENCE: Can I ask you question on that last slide?
PROFESSOR: Please, go ahead.
AUDIENCE: On the slide before, 37.
It seemed like the probability weighting
was for a general capacity.
Like something that could be adapted over the life cycle
but here we're pinning down a specific capacity.
So why is it the sum of probabilities, then?
Haven't, kind of, the probabilities been
realized, don't you know exactly what your capacity is
that you're operating at?
PROFESSOR: Yes, so just to be clear on this.
So the probability, those p's of i's,
they come from the lattice model.
They are determined by the lattice model.
So what you do is for those 32 scenarios of the future,
this is the pi, right?
The i is the index, is the--
for this particular future scenario,
for each future scenario, you always
start with a1, which is your initial configuration
of the constellation.
You always start with a1.
And for each of those future scenarios,
you then simulate that future and for those futures,
where the demand doesn't ever really take off
and materializes, you never actually
trigger that next expansion stage.
And it's actually that asymmetry that gives you the advantage.
And it's essentially not deploying capacity
when you really don't need it.
And so you do this for all of this n
scenarios for the future, and the pi, the probability,
weighting of each future scenario
comes directly out of the lattice model.
That's not something that you have to manually determine.
AUDIENCE: Right, no, I understand that.
But here, since we've kind of pinned down a capacity already,
we know what endpoint we're at.
I'm just wondering how the probabilities come into that,
or is it kind of working backwards now, of all the paths
that go there on this specific plot?
PROFESSOR: I see what you're saying.
OK.
So the last point, the a1 point, so the a1 point
is driven by-- you need to make some assumptions
about initial capacity and then the endpoint, the a4,
is driven by how large you made the trade space.
So you could make the trade space,
you could make the design space even larger, right?
This is a discretized full factorial design space,
you could make it even larger.
And then a4 would not be the end form.
This is just sort of a finite size effect,
given to the size of the trade space.
AUDIENCE: All right, thanks.
PROFESSOR: All right, so the way I want to do the summary here
is just go back to the learning objectives.
You know, I always do this in every class, you know,
let's close the loop.
What did I promise you in lecture one
that you would learn in this class?
And, you know, each of you, you're
going to have to decide for yourself, you know,
did I actually learn this?
Did we actually do this?
So this is sort of due diligence on the learning objectives.
And I have one slide on each of them.
So the first objective was to--
for you to really understand the system
engineering standards and best practices,
as well as more approaches.
Number two is understand the key steps in the system engineering
process.
Number three was analyze and understand
the role of humans in the system as beneficiaries,
designers, operators, and so forth.
Number four was being honest and characterizing
the limitations of system engineering as we practice it
today.
And then objectified learning and objectifiable
was applying these methods and tools to a real--
even if not so complex-- cyber electromechanical system.
So I see one, essentially, hopefully--
no, we didn't check the readings but I'm
hoping that you did your readings, that you really
feel like you understand the NASA System Engineering
Handbook, which is our quasi-textbook for this class.
But there's other standards as well,
such as the [INAUDIBLE] handbook,
which is actually the basis for certification.
So several of you--
your [? EPS ?] fellow mentioned to me
that you're interested in certification,
so I encourage that.
Most of that is based on the number two.
I did mention the ISO standard 15288.
That's probably the best known standard; ISO is a very--
they're located right here in Geneva.
ISO is a very important organization, you know?
I know ISO standards are not the most exciting things to read,
but they have huge impact and so 15288
is something that worldwide-known and across all
industries really.
And then I want to mention also the European Systems
Engineering Standard.
And Foster Voelker and I had a discussion
about this earlier today.
This is issued by the European Space Agency.
And it is a little-- there are some subtle differences
between ISO approach and the NASA approach.
And so for those of you on this side of the Atlantic,
I do encourage you to take a look at that [? ESES ?]
standard as well.
And then we augmented this with different papers, and readings,
and so forth.
So I want to do a very quick--
this is our last concert question for the class.
So here's the link, [INAUDIBLE] and it's
essentially I want to get some feedback what
you think about the standard.
All outdated and surpassed by the digital revolution,
one of you thinks that's true.
90% of you think they're useful codification and best practice.
14% think they can be dangerous if you
adhere to them too closely.
About 60% of you think they're essential reading
for any serious system engineer.
And 10% said that you would never use them
as a daily reference book.
VOELKER: OK, so that's good.
I think that's-- what do you think, Voelker,
pretty reasonable outcomes?
OK.
But what is true is that they're going
to be referenced, in contracts.
You know if-- if you're doing--
you know, it depends, again, on the industry that you're in.
But you're going to adhere to some
of these things in contracts, and if things don't go well,
people will actually check whether, did you do this step,
did you do that step.
So it does have real consequences.
PROFESSOR: OK, great.
Thank you very much.
That was that was good.
Step two, you know the key steps, v model,
I think I'm not going to explain it again.
You know, hopefully this is something
that you will not forget.
And just one point about the v model
is it does not imply that system engineering is always
sequential.
You know, it's possible to iterate between steps
and across the whole v as well.
SE3, stakeholders and value of network.
So this is the role of humans.
We talked about this very early on, several of you
talked about it during the oral exam here today.
You know, the hub and spoke versus the stakeholder value
network.
The method underlying this is critical, but I do
want to mention, very quickly--
and this is something we didn't spend a lot of time on--
is human factors.
Right?
How do you design systems so that humans can effectively
and safely use them?
You know, interfaces, procedures, and so this
is a couple of slides from one of my colleagues, Missy
Cummings.
This is actually some--
in a nuclear plant--
Katya, you're going to like this--
lots of these dials, and this is actually
a Russian nuclear plant.
So it has it has a very specific layout.
And so the important questions in human factors
are, how do you best display status information?
What tasks do humans do?
What level of automation?
What are the training requirements?
And these are also very important questions.
And so you can apply the human systems engineering
process, very much analogous to what
we covered in class so far.
So you do mission and scenario analysis, function allocation.
And then in human factors, you talk more about task analysis.
But essentially, eventually, leads to system design.
Like what are the buttons that you
push, what does the layout look like, or the user
interface, and so forth.
So, you know, I'm not I'm not presenting human factors
as a separate topic, but the human factors requirements
should be built in right from the start.
And essentially the functional allocation
is sort of a key question here.
How much is done by automation, how much is done by humans,
and how do you split between the two?
And one of the most important things to consider here
is this human performance curve.
And we know this pretty well now,
that when humans are extremely highly loaded--
you know, when you have a huge workload--
your performance goes down.
But interestingly, if you're under challenge
your performance goes down as well.
And you know, so for example, people
who are in power stations or mission control
centers where nothing is happening for days and weeks,
you know their attention goes down,
and they don't perform at a very high level.
Humans perform best at a moderate workload,
and this is well-known.
And it should influence how you define
the human interface and the split among automation
and humans.
SE4, system complexity.
Last time I will mention the magic number
seven, plus or minus two.
The real limitations come in and when we operate at levels,
you know, three, four, five, and six.
And the main reason for this is because now a single human
cannot understand, cannot remember,
cannot deal with all the detailed components.
And you need to split the work among teams,
among organizations, and creates extra interfaces
and complexities.
OK?
And just to show you, Iridium, we talked about Iridium.
This is a very recent news story this is from October 29th.
The new Iridium Next has again been pushed back
by four months.
This gentleman here is the CEO of Iridium, chief executive
for Iridium Next, Mr. Desh.
And he's talking here about a particular [INAUDIBLE]
and then Viasat is one of the contractors.
There's a particular component that's been giving trouble,
and that's sort of in level three or four in the hierarchy,
and that's essentially delaying the whole system.
So there's an example of how the large complexity of the system
is causing issues.
AUDIENCE: [INAUDIBLE]
PROFESSOR: But they're actually a supplier
to [INAUDIBLE] through the whole chain, right?
Oh you're saying there's more going on than meets the eye.
Yeah, who knows?
Who knows?
OK, and then finally here I want to mention application
to a case study.
You know, we used the CanSat 2016 competition
as a quote, unquote safe case study.
And I have to say I'm really pleased with how
this worked out.
You had the 47 requirements as a starter,
you approved, them you group them,
and my comments about the PDR that we had a week ago
are all teams passed successfully, the PDR.
You know, if this was a real PDR,
we would have issued a couple of [? ridds, ?] I think.
There was some-- a couple of teams were over budget,
or needed to work out their aerodynamics in more detail.
But by and large I thought this was an excellent application
of system engineering concepts.
Went beyond my expectations.
Several of you mentioned the importance
of concept generation, you know hybrid use
of structured and unstructured creativity techniques.
I know at least one team applied to actually go
to the competition.
And this shows you a couple examples.
So we have one team here at the EPSL
using a bio-inspired design.
This is an actual seed airfoil that actually occurs in nature.
And then here's an example from MIT, the Rogallo Wing Team 7.
So, I'm sorry I didn't mention all the teams here,
but it was really great to see the application of this
in the CanSat competition case.
So the last thing I want to do-- and I only have one minute
left, actually I'm already slightly over time--
but I just want to give you some career and study
recommendations.
So first of all, you know, I want to make sure that you--
and I said this in the first lecture--
there's a lot more to the system engineering and systems
research than we were able to cover in this class.
So this class is really what I call a door opener to the world
of system engineering.
If you want to go deeper, there are deeper subjects.
You know, model based system engineering is the big trend.
System safety.
And then in the spring I'm teaching
a class called Multi-Disciplinary System
Optimization.
And there is actually a WebEx access to it as well.
So it's not going to be officially offered
as a [INAUDIBLE] class, but if individual students here are
interested, please contact me.
Self-study, you know the System Engineering Journal,
there's IEEE journals, there's also--
you know, for some of you this is maybe a little too soon--
but there's professional degrees in system engineering.
For example at MIT we have the SDN program, System Design
and Management.
The average age of the students in that program is 33,
but it is--
they're sort of coming back to get their masters in system
design and management.
And there's quite a bit of SLOAN content as well.
So finance, you know, understanding the financial--
how to build a business case around systems as well.
Professional experience.
You know, getting experience in actual projects.
Like at MIT, for example Rexus.
You know, you've got the Clean Space One project,
we heard about [? Optaneous ?] One, Solar Impulse,
there are a lot of opportunities.
Or-- we also had a couple of people
here mention that you're starting your own company,
your own venture.
And you know, when you're doing, that you
have to be the system engineer.
You have to understand all of these things, interfaces,
suppliers, requirements, markets, all
that has to be integrated.
Finally, you did hear about INCOSE.
We had a quick dial-in with at an earlier session.
So if you're interested, you can join either
as a student or a professional member.
And also certification.
This class was not [INAUDIBLE] for that,
but if you're interested in this site, [INAUDIBLE]
number of years of experience at the [? CCF ?] level.
And then finally, please keep in touch.
And last but not least, I want to thank
all of you, the students at MIT, at EPFL, our TAs, [INAUDIBLE]
here at EPFL, Johana at MIT, the technical staff
has been helping run the technology, Voelker, thank you.
And-- and that's it.
So I want to thank all of you.
Next week we do have a voluntary seminar
on sort of future trends in manufacturing,
but again, it's not mandatory.
It's going to be in the same place, but like I said,
it's not part of the official class.
So with that, sorry for running a little bit over time but
it's been a joy to teach this class
in this kind of new format.