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.
OLIVER DE WECK: So let me start.
Session 3 is about system
modeling languages.
But before I start, I'd like
to remind you that A1 is due
today.
The first assignment
is due today.
And I think neither [? Yuanna ?]
or I or [INAUDIBLE],,
did you get a lot of
questions about A1?
GUEST SPEAKER: No.
I didn't get any questions.
OLIVER DE WECK: Yeah.
So we didn't get many questions.
So I interpret
that as a positive,
but I guess we'll find out.
Everybody submitted.
Well, so we're hoping to have
these graded in about a week,
give you feedback.
And we'll also post
a master solution.
And A2 is out right now.
And the other good news is
there is no new assignment
today that's being--
the next A3 is going
to go out next week.
Any questions about A1?
Was there something
that was particularly
difficult or confusing?
Or was it straightforward?
Anybody want to comment on A1?
Wow.
Sam.
Do you want me--
push the button.
GUEST SPEAKER: No,
our team thought
it was fairly clear
on what we had
to do based on the lectures.
OLIVER DE WECK: OK.
GUEST SPEAKER: We
didn't have any trouble.
OLIVER DE WECK: Good.
All right.
Well, let's keep going then.
So the V-Model is our
roadmap for the class.
We're starting to
fill in the V. We're
still in the upper left corner.
And today's lecture is
actually a little different.
It's sort of in the center
of the V, system modeling
languages, as a
precondition or precursor
to what we've been calling MBSE,
Model-Based System Engineering.
So what I'd like to cover
today is why do we need--
or why have these system
modeling languages emerged,
particularly, what do we
mean by ontology, semantics,
and syntax?
And then we're going
to give you a--
I would characterize
this as a sampler
of three different
system modeling
languages that
have emerged really
within the last 10, 15 years.
The first one is called OPM,
Object Process Methodology.
The second one is called SySML,
System Modeling Language.
And then the third one
is called Modelica.
And then we'll sort of quickly
wrap up with the question,
you know, what does this mean
now for system engineering
today, and tomorrow
in the future?
So I'd like to motivate
this with a little exercise.
So you remember Mr.
Sticky from last time?
You came up with
some requirements.
So it's kind of the simplest
system I could think of here.
So what we'd like to do is
have you work in pairs again.
And the assignment here
is to describe this system
as clearly as you can,
provide a description.
So last time the assignment
was right, a requirement,
come up with some requirements
that led to this design.
But today I would
like you to describe
what the system is,
how it functions,
and so forth, as
clearly as you can.
And I would like
you to do this--
so hopefully you're on the
Webex, logged into the Webex.
I would like you to do
this in teams of two.
And as you're
doing this, I don't
know if you've noticed but
on the Webex there's actually
a Notepad feature.
Where is it?
Tell me.
Left?
Right?
AUDIENCE: [INAUDIBLE]
OLIVER DE WECK: Oh, I see.
So I can't share and use the
Notepad at the same time.
AUDIENCE: [INAUDIBLE]
OLIVER DE WECK: Annotate.
AUDIENCE: [INAUDIBLE]
OLIVER DE WECK: Yeah, yeah.
AUDIENCE: [INAUDIBLE]
OLIVER DE WECK: Stop sharing.
But then they can't see it.
AUDIENCE: [INAUDIBLE]
OLIVER DE WECK:
Can they see this?
AUDIENCE: [INAUDIBLE]
OLIVER DE WECK: So
you can write text.
You can draw shapes.
So the reason I want you to
do this on the whiteboard
is such that we can
then go around and look
at some examples.
So the assignment is take five
minutes, turn to your partner
and try to describe this system.
And then we'll go around
and look at some--
we'll sample people's
descriptions.
Go for it.
All right.
So keep working
on the assignment
but do it locally
on your computer,
not on the whiteboard.
And then we'll sort of discuss
it and share it and maybe
not use the
whiteboard, because I
didn't realize there's only one
whiteboard that we all share.
I thought that you have
individually the whiteboard
and then you can sort of pass
it on to different people.
So if you do it locally
on your machine,
then we can share the
screen so it'll work.
So do it in do it in PowerPoint,
or Word, or sketchpad,
or anything you want.
Sorry about that.
All right.
So let's do this.
We're going to sort
of go back and forth
between here and EPFL.
Let's start maybe
over here with Narek.
Are you ready?
So I'm going to
give you the ball,
and then you can
sort of explain how
you guys describe the system.
NAREK SHOUGARIAN: So
what we decided to do
was identify the primary
function of Mr. Sticky.
So the primary function is
to trap the fly, we thought.
This is enabled by a
couple of other functions
that are sort of at a
lower layer of abstraction.
It's attracting the fly,
immobilizing the fly,
transporting the
objects to where
you need to immobilize the
fly, and deploying Mr. Sticky.
And we mapped this
to the physical forms
that enable the function.
So the canister, the
physical form of the canister
is helping with the
transporting function.
The sticky tape is helping
with the immobilizing function.
The scented
material, we thought,
would be helping for
the attracting function.
And the hook maybe on top
that you use to hang it
would help with the deploying.
OLIVER DE WECK: OK.
Good.
So nice function
form separation.
And you used primarily text,
human language to describe it.
So let's see, at EPFL,
who would like to share?
And we'll give you the ball.
AUDIENCE: OK.
We can try maybe.
OLIVER DE WECK: Who is speaking?
AUDIENCE: Maxim.
OLIVER DE WECK: Maxim, OK.
Can we give the ball to Maxim?
AUDIENCE: Yes.
Do you see something?
OLIVER DE WECK: Yeah, its good.
AUDIENCE: Oh, perfect.
So we draw like the same system
when deployed and undeployed.
So we begin with a container
containing basically
the sticky setup rolled.
Then when unrolled,
we have the container
that should be linked to the
sticky setup, the [INAUDIBLE]
whatever.
And then we have like an
external input from the insects
that were, that come to--
we it sticked onto the--
OLIVER DE WECK: Yeah, go ahead
AUDIENCE: OK.
So that's all.
OLIVER DE WECK:
So I'll note here
that you guys used graphics.
You used some kind of
graphical language.
And at the highest
level, you have--
it's like a state
diagram, rolled, unrolled.
So you showed the system
in two different states.
Very nice.
Somebody else here
on the MIT side,
and then we'll go
back one more time.
Who would like to share here?
Lucille?
OK.
So let's--
AUDIENCE: So we did a diagram
showing the use of Mr. Sticky.
So we have a user
because Mr. Sticky
has to be rolled and
unrolled-- well, unrolled.
The user installs or
disposes of Mr. Sticky.
The flies are attracted to-- or
Mr. Sticky attracts the flies,
and the flies stick
to Mr. Sticky.
And then we did
compose Mr. Sticky
into the different
components that
are below at a lower level.
And yeah, so it's basically at
a higher level of use diagram.
OLIVER DE WECK: OK.
So here we have, again,
a graphical description.
The states are sort of implied.
But you're focusing on
decomposition, the elements.
Very nice.
Anybody else at EPFL?
Did anybody just write a
paragraph of text, or more
of, like, sentences?
AUDIENCE: [INAUDIBLE]
OLIVER DE WECK: At EPFL,
who wants to share?
AUDIENCE: Chris here.
OLIVER DE WECK: Chris, OK.
AUDIENCE: So we
didn't write the text.
The text seems a bit heavy
to convey a description
in efficient terms.
What we prefer to do is
decompose in elements
and for each element
give some properties.
OLIVER DE WECK: OK.
And did you do this
in the form of a list,
or in the form of a table?
Or how did you
actually describe it?
AUDIENCE: So wait.
I'm trying to share the screen.
OLIVER DE WECK: OK.
AUDIENCE: All right.
So we just worked on
the first half here.
We have the band.
And we give here properties.
Those that have to be made
of paper or soft material
has to be 1 to 1.5 meters
long, 3 to 5 centimeters large.
It needs to have a coating which
itself is a sticky material,
and be centered in
order to attract flies.
It needs to have visible color.
And then, well, the other part
here, which I'm highlighting,
would be related to
the packaging, so
a self-sealing linear container
with a single-use opening,
including a hanger.
We'd possibly give
branding on the packaging
and, well, the
non-toxic material
would refer to the
sticky material.
OLIVER DE WECK: Good, good.
Thank you very much.
This is great.
So what you showed,
that's more like a list.
And I would
describe-- this looks
like what I would call
a bill of materials.
It's essentially a list
of the primary elements
of form of the system.
But there are some attributes
that are associated.
So this is a list format in
the form of a bill of materials
with attributes attached.
So thank you very much.
That's great.
So I'm going to
share here again.
And you're probably
wondering what the heck?
Why did we do this?
Why did we do this exercise?
And that's the point
I want to make next.
So here's a very simple system.
And we have four
examples of descriptions
that were quite different.
And of course, if
you had more time,
they'd become more complete.
But they would be
really different.
So this is
fundamentally the issue
that we've been
facing in systems
engineering for a long time.
The means for describing
our artifacts,
whether it's something
as simple as a Mr.
Sticky, or an airplane,
or a spacecraft,
or a medical device,
or even a service,
how would we describe it?
Well, first of all,
natural language,
the human natural language.
And as we know, the human
natural language is very rich.
There's very different
ways in which
we can express, essentially,
the same facts, the same things.
That's a wonderful thing if
you're a poet or a writer.
But it makes system
engineering challenging,
because it gets
confusing when we're
describing the same thing
in very different ways.
Or graphical, so
we saw some boxes,
and we saw some great
examples, sketches, drawings.
So fundamentally, the
way we describe systems--
and this gets to the left half
and right half of the brain--
is using language, words,
sentences, lists, or graphical.
Those are the two fundamental
ways of describing systems.
And then we put all these
descriptions together
in what we've been
calling documents.
We aggregate this in documents.
So examples of documents would
be a requirements document.
That's what, essentially,
you're doing in Assignment 2.
Or a drawing package,
even if it's in CAD,
it's still essentially
a document.
So typically in system
engineering all of this
gets assembled into what we call
a TDP, Technical Data Package.
And fundamentally, when
you're designing a new system,
you're producing
a technical data
package that has software
drawings, descriptions.
And that's the deliverable
from the design process,
is this TDP, Technical
Data Package.
And from that, you should then
be able to build and operate
the system with as few errors,
mistakes, misunderstandings
as possible.
And fundamentally,
as our systems
have been getting more
and more complex--
we're now talking
about the systems
that need the three, four,
five layers of decomposition--
it's very easy to have
errors, omissions,
different interpretations
of this information.
So that's fundamentally--
but there are advantages.
I don't want to say
it's categorically
bad to use natural
language and graphics.
They're definitely an advantage,
familiarity to the creator
of the description.
So it's easy.
It's comfortable.
It feels familiar.
And also it's not
confining, so you
can be quite creative
by creating descriptions
in this way.
But the list of
disadvantages is quite
long for allowing an
arbitrary description, room
for ambiguous
interpretations and errors.
It's quite difficult to update.
So if you make a change
in one description,
that change will
not automatically
propagate to the
other descriptions.
Handing off these descriptions
from one lifecycle phase
to another, there's
discontinuities
in these hand-offs.
Uneven level of abstraction,
so what I mean by that is you
may describe one part of the
system, and very detailed.
So the last example
we saw with the list,
with the bill of
materials, there
was quite a bit of
detail there on the scent
and the attributes of the tape.
But one of the other--
at least a couple
of the other descriptions
didn't have that level of detail
when it came to the tape.
So the level of
abstraction could
be quite different in the
different ways to describe it.
And then for a
complex system, you
can imagine that the amount
of volume of information
grows a lot.
And so you can walk into any
program manager and systems
engineers office
and see bookshelves
full of binders, dozens
and dozens of binders
with documents, thousands
and thousands of pages.
And many of them are never read.
That's the big issue.
So that's been the
kind of way in which
we've been doing system
engineering traditionally.
So the idea here
is that in order
to mitigate-- yes, Justice.
AUDIENCE: [INAUDIBLE]
OLIVER DE WECK: Phase
A, conceptual design.
Phase B, preliminary
and detail design.
Phase C is testing and launch.
Phase E is operation.
So usually not the same
people do conceptual design,
preliminary design testing.
So all the technical
data package,
these artifacts have to be
transferred and handed off
to new people who then
work on the next phase.
That's what I mean by hand-offs.
And, yeah, so the
idea is in order
to mitigate some of
these disadvantages
of natural language and
graphical description,
there has been, and
this has been recognized
for a long time, a need to
be more precise, perhaps more
confining, but to
create languages
that allow us to describe
systems much more precisely.
And so I'll mention a
couple of the past efforts.
And you can read about these.
Each of these has--
so I'll mention bond
graphs first, 1960.
This was actually
invented here at MIT
by a professor in
mechanical engineering.
His name was Henry Paynter.
Professor Paynter
created bond graphs.
You can think of bond
graphs as block diagrams
where different blocks have
ports or interfaces where
information, material,
energy flows in and out.
And you can compose a
system out of these blocks.
These bond graphs
are essentially--
and Narik will talk
about Modelica,
which is sort of a modern
version of bond graphs.
It has other features, too.
But this has been
sort of one attempt.
Another one that's very
well-known is IDEF, I-D-E-F,
about 20 years later.
This was created by the Air
Force, the US Air Force.
And this is essentially
a description
of systems that's very
functionally oriented.
So it shows you what
functions are involved.
And we saw one of
the descriptions
was very functionally
oriented, and how
the functions of the system
relate to each other.
But generally these
system languages
have not fully been deployed.
Some organizations use
them, others don't use them.
And the main reason
for that is twofold.
First of all, some of these
languages were incomplete.
They would focus only on
one aspect, like functions
or the block nature of the
system, the block diagrams.
And a lot of them
were not executable.
So they would be graphical,
but you couldn't actually
simulate and actually check
whether that description was
complete or accurate.
So since then-- and
the other thing,
of course, important
is domain agnostic.
So what I mean by this is that
the system modeling language
should be applicable for any
kind of cyber physical system.
Again, if you're designing
a spacecraft, an aircraft,
medical device, any
kind of product,
the language shouldn't
have to be adapted.
The language sort of covers
all these applications.
That's the idea.
So whatever language it is that
you're using or developing,
it has to have
these three things.
Any language has
these three things.
So the first is ontology.
And I reference here
the Wikipedia articles
on these things.
Some of my colleagues-- in
academia it's a big debate
is Wikipedia a legitimate source
of information or is it not?
My position on
this is that it is.
I think Wikipedia is
definitely not perfect,
depending on what topic
you're looking at,
but it's a sort of
self-correcting system.
So I actually go to Wikipedia,
and then there's references.
And you can dive deeper.
So I give you the
Wikipedia links
here for these three things.
First, ontology.
So ontology is a
very fancy word.
What ontology actually is--
Mark, why don't
you come up here?
You're an instructor today.
Ontology, fundamentally,
is describing the entities
that are allowed to exist in
the language, subjects, nouns,
adverbs, what are the objects,
the entities, that can exist.
So it's a kind of
very abstract thing.
But it's essentially the
library of words and objects
that are allowed to
exist in that language
and then how these entities
can be grouped perhaps
in a hierarchy and subdivided.
So it essentially
constrains the universe
of things you can
describe in that language.
The shorter, the smaller
your ontology is,
the more confined the language.
Semantics.
Semantics is basically a branch
of science of philosophy, which
is fundamentally assigning
meaning to those objects that
are described in the ontology.
And so the way
that we say this is
that it's the relationship
between the signifiers,
so the signifiers are
words, letters, symbols,
graphical symbols.
So how do we describe a
resistor, for example,
in electrical engineering?
A squiggly line.
It's the zigzag line.
Well, if you don't know
electrical engineering,
you just see a squiggly line.
It's meaningless to you.
But if you know that
semantically that
means that's a resistor,
that's the symbol for resistor,
that's what we
mean by semantics.
And then the third is syntax.
What is syntax?
It's the set of rules, the set
of principles and processes
by which the objects or the
entities in the ontology
can be combined to
build up higher level
information, like sentences,
paragraphs, and so forth.
And so that's essentially
the construction rules
for the language.
So every language has
these three things.
So any questions
about this before we
move into our first language?
So we're going to give three
examples of system modeling
languages, and you'll see the
similarities and differences.
But as you see these
languages, keep in mind they
all have ontology,
semantics, and syntax.
Any questions about that?
So OPM.
Let me describe to you OPM.
This is one of the
younger languages.
And so OPM stands for
Object Process Methodology.
And it was created by
Professor Dov Dori at Technion,
a colleague of mine.
Dov is essentially a computer
scientist by training.
And you'll see the
heritage here of OPM.
And the big news
here about OPM is
OPM is not that well-known yet.
If you ask around, not
too many people know OPM.
But I predict that
in the next decade
that will change very quickly.
And one of the reasons
is that OPM was just
now adopted as an ISO standard.
And if you know ISO, the
International Standards
Organization, they're
located in Geneva,
it's a big deal to
become an ISO standard.
It took like five years,
the whole process,
with committees and reviews.
And so the ISO
standard is actually--
OPM was adopted
as an ISO standard
as a means to describe and
develop other standards.
So it's kind of a metalanguage
because, as you can imagine,
when you read different
standards which, by the way,
have a lot of
influence, they're also
written in natural
language and graphics
and lots of inconsistencies.
So the idea is that future
ISO standards should
be written using OPM such that
they're clear and consistent,
and so forth.
So the history here is
that if we go back further,
UML, which is Unified Modeling
Language which I'm not
going to talk about
today, is a software--
this is a language that
was developed primarily
for software engineering
to consistently describe
use cases, to
consistently describe
activity and flows in software,
the structure of software.
But it's really
software centric.
So from UML 2.0, we then
sort of branched off
into SysML, which Mark
Chodas, who just joined us
will talk about, and then OPM.
So these are sort of
derivatives of UML.
And there's a book, it's not
one of the mandatory books
for this class, OPM 2002.
If you're really
interested in OPM,
I recommend you
invest in that book.
It's really very well written.
So let me give you an example
of how OPM can be used.
So like we said, typical
product representations
are sketches, engineering
drawings, or UML diagrams
and software, but the need
for a unified representation.
And fundamentally,
we have functions
and then we have objects,
form and function, in systems.
And so what we would like to
do, and the premise of OPM,
is that we can show everything
in one diagram type,
so the functions, the functional
attributes, the objects,
and there's different
types of objects, operands,
system components,
consumables, the attributes
of those objects,
and then the links.
And I'll show you
the different types
of links between these
that exist in OPM.
So it's a generic
modeling language.
And it has been
successfully applied
to system architecting
of complex products
in different organizations.
I'm going to try to give you
a pretty simple example here,
which is a refrigerator.
So we're going to
look at a small kind
of household-level refrigerator
through the eyes of OPM.
All right.
So here's the basic
ontology of OPM.
It's very, very simple.
And that's the idea, is to have
as few objects, as few entities
as possible in the
language to keep it simple.
So the first one is
the idea of an object.
What is an object?
Objects are drawn
as these rectangles.
Objects are defined
as entities that
have the potential for stable,
unconditional existence
for some positive
duration of time.
And objects have
states within them.
So what would be an
example of an object
that we've talked about today?
Go ahead.
AUDIENCE: Maybe the sticky tape.
OLIVIER DE WECK: Yeah, so
the sticky tape itself.
That's an object.
It exists unconditionally.
It's there.
And what's important is it
could be a physical object.
So it has a physical existence.
But it could also be a sort
of informational object.
So for example, if you
have an idea or a vision,
that's an object, too.
It's not physical in that
sense, but it does exist
as an informational object.
What are states?
Let's see at EPFL.
What would be an example
of a state that's
associated with an object?
Yeah, that's OK.
Can somebody give an
example of a state?
AUDIENCE: Yeah.
Rolled and unrolled
for the sticky tape.
OLIVIER DE WECK:
Rolled and unrolled.
Exactly.
Or furled and unfurled.
So that's kind of a binary state
that could be halfway unrolled,
or the sticky tape is full of
flies, or it's kind of empty.
Those would be describing the
object in terms of what state
it is in.
Exactly.
So the form is then the
sum of all these objects.
So that's one building block.
And then processes
are the other.
So what are processes?
Oh, is there another example?
Yeah, go ahead.
AUDIENCE: May I ask a question?
OLIVIER DE WECK: Is
this [INAUDIBLE]??
AUDIENCE: Yeah,
it's [INAUDIBLE]..
OLIVIER DE WECK: Go ahead.
AUDIENCE: What do you mean
by positive duration of time?
OLIVIER DE WECK: Well,
meaning that the object
could be created.
It didn't exist before.
It's created, and it exists.
And then it could
be destroyed again.
It could disappear, or
it could be consumed.
But it means that
the object needs
to exist for a non-zero
period of time in order
for it to be called
an object, so objects
in the world that can
be described with OPM,
fundamentally, objects
can be created.
Objects can be modified,
particularly their states
can be modified.
And they can be
destroyed or consumed.
That's basically it.
That's a complete set.
Does that make sense?
So processes are--
what are processes?
Processes are
really fundamentally
different from objects.
Processes are shown
as these ellipses.
And they're the patterns
of transformation
applied to one or more objects.
And processes change states.
So processes, unlike objects,
cannot exist on their own.
Processes only make sense
if they're associated
with at least one object.
So processes are essentially--
the functions that
we develop in systems
are processes that transform
or create, destroy,
or transform objects.
So function emerges from
one or more processes.
And then we have different links
between objects and processes.
I'll show you two examples here.
One is the arrow
with a pointy head.
That could be a consumption
or production type link,
or a link with this
little lollipop symbol.
This is known as
an instrument link.
And so the difference there
is that if an object is linked
to a process using an arrow,
it means that something's
happening to that object.
It's being created, or
destroyed, or modified.
If an object is linked to a
process using the lollipop
symbol, the instrument
link, it means
that in order for that process
to happen this object is
needed, it's an instrument.
But the object itself,
the instrument,
does not get modified in
any way by the process.
But the process couldn't happen
if that object didn't exist.
Do you see the difference?
And so one of the really,
I think, important things
about OPM, but any
of the languages,
is that every box,
every arrow, every link
has precise semantics.
And usually when
we kind of doodle,
when we just think about--
we put arrows and
links between boxes,
we often don't
really deeply think
when I put a link in here, what
does that link actually mean?
What does that link imply?
So when you do system modeling
using these languages,
you become much,
much more precise.
Yes, please.
And would you push
the mic button?
Yeah.
Mark, go ahead.
AUDIENCE: Can an object
be a process or a process
be an object?
OLIVIER DE WECK: No.
AUDIENCE: So what
about if you have--
I guess I'm thinking
in terms of if there's
some process for
doing some procedure
and like you're assembling
a satellite or whatnot.
You need to modify that process.
So how is that sort of
thing represented in OPM?
OLIVIER DE WECK: The
process modifies objects,
but processes cannot
modify other processes
because processes are
fundamentally, in OPM,
acting upon the objects.
Now, processes can
invoke each other.
So if there's a
sequence of processes--
you have to do this assembly
step before this other assembly
step--
you can have what's
called an invocation link.
But that's a logical
dependency between processes.
But fundamentally, the processes
act through the objects in OPM.
AUDIENCE: OK.
OLIVIER DE WECK: So let's
go into some more detail.
So at a high level when you
look at the economy, products--
yes, go ahead.
AUDIENCE: I have a question.
Why create another language
and not just stick with UML?
OLIVIER DE WECK:
So good question.
So we'll talk about SysML,
which is very similar to UML.
It's sort of generalized for
cyber-physical systems, not
just software.
So the reason that OPM
was created, because UML
was found to be
somewhat too confining.
This is more general
and also the idea
of a unified representation, one
type of diagram and description
for any application.
So it's basically a kind of a
more general version of UML.
But the other really
important thing about OPM
is that objects and
processes are sort of--
the processes are often in
object-oriented thinking.
Processes are embedded
inside objects.
And in OPM, the
processes have been
emancipated to stand at
the same level as objects.
Those are the main differences.
So let me go in a
little bit more detail.
So if you think about the
economy in general, goods
and services, goods are objects,
and services are processes.
So if you buy a new iPad, or a
new pencil, or whatever it is,
you're actually
buying an object.
You're purchasing an object.
That's obvious.
But why are you
purchasing that object?
So let's say you're
buying a new tablet.
You're buying the tablet.
But why are you
buying the tablet?
Sam, go ahead.
AUDIENCE: You're
buying the tablet
to perform an action for a
process on something else,
to do something.
OLIVIER DE WECK: Right.
So what do tablets do?
I mean, not stone tablets,
but modern tablets.
AUDIENCE: They allow you to
work with software, communicate.
OLIVIER DE WECK: Yeah, so
they're information processing.
They're information-processing
devices.
And there's an
argument with tablets
are great for
consuming information.
They're maybe not as good for
generating new information.
So fundamentally, you're
purchasing the tablet,
which is an object,
in order to be
able to do information
processing and information
consumption.
So the process is then implicit.
What's an example-- if you
purchase a service, what would
be an example of a service?
What would be an
example of a service?
Let's see at EPFL.
What would be an
example of a service
that you could purchase?
AUDIENCE: Going to the dentist.
OLIVIER DE WECK:
Going to the dentist.
Yeah, one of our
favorite things to do.
Have you been there recently?
AUDIENCE: Yeah, one month ago.
OLIVIER DE WECK: So
I don't want to be--
I don't want to
violate your privacy,
but can you share with us
what happened at the dentist?
AUDIENCE: It's the
yearly checkup.
You have to check that
there's no hidden--
I don't know how you call
that in English, carries?
OLIVIER DE WECK: Yeah, cavities.
Yeah.
AUDIENCE: Yeah, cavities.
Check that wisdom
tooth don't mess up
what you've been working
on tirelessly when
you were younger with braces.
And [INAUDIBLE] get checked.
OLIVIER DE WECK: Very good.
So going to the dentist.
The dentist provides
a service which
is either checking
your teeth or filling
cavities, which is a process.
And all the objects, the
chair on which you sit,
the instruments--
I guess we still use gold
sometimes in some places--
those are objects that are
used in the performance
of the service.
You see the relationship?
So objects and processes
always come in pairs.
Thank you for that example.
So let me talk about the
links in OPM briefly.
So there are two types.
There's the structural links,
which link objects to objects.
And we typically use arrows,
you know, is related to
or we can tag these as well.
So for example, something
powers something else.
This is known as a tagged link.
It suppresses the processes.
And then there's these
triangles that are--
essentially, there's a
kind of hierarchy implied
there and slightly
different meanings.
So the solid triangle
means decomposition.
So the higher level
object is composed
of lower-level objects.
So that's, Mark, you
mentioned assembly, you know,
are you creating the bus of
the spacecraft and it has
a whole bunch of stuff in it?
Well, you would use
this filled in triangle
to show that decomposition.
The second example is the
characterization link.
So this is essentially
relating an attribute
to its kind of master object.
Specialization
and generalization
is the empty triangle.
And then this funny symbol
here is instantiation.
So essentially, you
have a general object.
And then you can
instantiate that.
So I have two children.
I have two children,
which is general.
And there's two
instantiations of them.
One of them is called Gabrielle.
And one of them is
called Christian.
And they're actual people.
So that's the idea
of instantiation.
Processes.
Processes are these
patterns of transformation.
They're tricky.
Processes are trickier to
understand than the objects
because we cannot hold
or touch a process.
It's fleeting.
And the creating change
or destruction of objects
is what processes do.
They rely on at least
one object in what
we call the preprocess set.
A process transforms
at least one object.
And the time is implied.
So processes take
along a timeline.
And in terms of the
description, in English
we use the so-called
Gerund form.
So all the processes,
there's some examples
on the right side, use
the "ing" form of a verb.
So we can then put
these together, objects
and processes.
So here's an example
of a machine.
This happens to be like a
printer or copy machine.
It has a main switch.
The main switch has an
attribute called Main Switch
State, which can be on or off.
The process of
switching transforms,
in this case, the Main
Switch State from on to off.
Or we could go the other way.
And in order for this to
happen, we have here--
this is actually slightly
different than the instrument
link.
This is a filled
in lollipop, which
is known as an agent link.
So the operator
is an active agent
to carry out the
switching process which
changes the main switch state
from on to off or off to on,
and the Main Switch State is an
attribute of the main switch.
So transporting.
This is another example.
Transporting changes the state
of a person from being here,
Location A, to being
there, Location B.
So there are seven-- huh,
coincidence, seven, seven--
object process links in OPM.
So P changes-- the process
changes the object,
say from State A to B. That's
the example we just looked at.
You can actually hide that.
If you're really not interested
in all the states and details,
you hide the states.
You don't want to see them.
And then you can
replace that with what's
called the affectee link,
which is this two-sided arrow.
And all you know is
that this process
is affecting that object.
And it's a two-sided arrow.
But you don't know exactly how
but you know it's affected.
A resultee link-- so this is an
arrow pointing from the process
to the object--
means that the process
of transporting
produces emissions that
weren't there before.
So that's a resultee link.
But the process of transporting
requires or consumes energy.
So the arrow is
pointing from energy
into the transporting process
because it's being consumed.
I did mention the agent link.
So there's an
operator of a vehicle.
And when we talk about
autonomously driving vehicles,
a big topic right now,
actually, it was cool.
At EPA this summer, there's
the autonomous shuttle
on the campus, the
electric shuttle.
Did anybody take that?
Did you guys try that
shuttle this summer?
AUDIENCE: [INAUDIBLE]
OLIVIER DE WECK: Yeah?
Did you like it?
AUDIENCE: No, I didn't.
But a friend is working
in this kind of shuttle,
like sitting for hours waiting
for people [INAUDIBLE]..
OLIVIER DE WECK:
So fundamentally, I
mean, if you want to think
of this in OPM language,
a driverless vehicle is
basically eliminating this,
no longer needing an
operator with an agent link
and replacing this with
a piece of software,
which would be an
instrument link.
So the instrument, the
transporting process
requires a vehicle.
And then we have what's
known as a conditional link.
So this process can only
occur if this object
is in that particular state.
So this example here,
obviously, ignores the existence
of credit cards.
So you can do the purchasing.
The process of purchasing is
conditional upon the state
of the object money being
in a state of enough
for doing the purchase.
So here's an example of a
little bit more complicated.
This is a Level 0 OPM diagram
of a car, of a vehicle.
So you can see in
the upper right is
sort of a sketch of a vehicle.
And it has these
different attributes.
ED is engine displacement,
height, ground clearance,
overall length, wheelbase.
There's a trailer here
with a towing capacity.
So the way the way you
would interpret this
is that we have a
transporting process.
That's our master, sort of
the highest level process.
And it changes the attribute
location for driver passengers
and cargo from A to B.
And that's, fundamentally,
where the value is for
the owner of the vehicle.
And then we can zoom in to
the transporting process
and look at subprocesses,
towing, propelling,
and housing.
And if you think about what
a vehicle does at the highest
level, it protects you, it
houses you, and it propels you.
And then you can break
those into more detail.
And then on the left side
here we have, essentially,
the elements of form.
So the automobile,
which is an instrument
of the transporting
process, can be
decomposed into its major
subsystems, powertrain,
chassis, body, wheels.
And each of those
are characterized--
you see those attribute links--
characterized by things
like fuel capacity,
engine displacement.
This is the design domain
we talked about last time.
Ground clearance.
And so those are the
design variables.
Those are the parts
and assemblies.
And then on the right
side, the processes,
the internal processes can also
be characterized by performance
or functional attributes
like towing capacity,
fuel economy, acceleration.
PV stands for Passenger
Volume and cargo volume.
And those are things when you're
comparing different vehicles
to purchase, those
are the things
you would compare
vehicles against.
So they're the internal
functions and then
the functional attributes.
And then up here there
is the fuel and emissions
and safety-related
issues, which that's often
where the governments
intervene and then regulate.
And this is sort of a highest
level OPM of a vehicle.
And then if you want
to see more detail,
you would start drilling
down into these.
And you'd have multiple
levels of these,
like a hierarchy
of these diagrams.
Yeah.
AUDIENCE: So here,
what is the use
of the-- or the meaning
of the open arrows?
And it looks like there's a
couple of different arrows
here than what we had
in the other diagram.
OLIVIER DE WECK: Are you
talking about these guys?
AUDIENCE: No.
OLIVIER DE WECK: Oh, these here.
Yeah.
AUDIENCE: Yeah.
OLIVIER DE WECK: So
it's just a visual
represent-- there's no
distinction on the arrows
whether they're
filled in or empty.
That's just a kind
of graphical thing.
Yeah.
So one of the--
yes.
Veronica, do you
want to push the--
AUDIENCE: How
would you represent
a process that creates
kind of a temporary state?
So if you're saying this
is acted on an object,
and this changes the
form of the object
but the object will ultimately
return to its original state
kind of absent of a
reversing process,
if it's a natural tendency
for the object to return,
how would you
represent that change?
Would you need to
break it down as kind
of a subprocess
within the object?
OLIVIER DE WECK: Right.
So I mean, and sometimes
there's multiple,
there's non-uniqueness in sort
of representing the same thing.
But there's one
process that brings you
to the temporary state.
AUDIENCE: OK.
OLIVIER DE WECK:
And then there would
be a restoring process
that restores you back
to the original state.
AUDIENCE: Does the process
have to be a separate plan
within the system?
Because there are certain
objects that have a tendency--
I'm thinking primarily of
kind of chemical states
where reactions would
happen naturally.
It's kind of a
specific thing, but I
was thinking about how you
might model different systems.
And I was thinking
about the engine
of the car, just kind of how
things might naturally return.
So do you have to describe
the process explicitly
if it's not something that's
inherently designed in,
if it's kind of a--
if it will happen anyway.
OLIVIER DE WECK: I
think, I want to say you
have to explicitly define that.
AUDIENCE: OK.
OLIVIER DE WECK: So if it's a
man-made process, so to speak,
then that's a process
you want to happen.
And then if the restoring
it back to some other state
is a natural process,
well, it exists.
So it will restore the
system to a prior state.
That process would also
have to be modeled.
AUDIENCE: Is there a
distinction between how
you would indicate a man-made
process or a natural process?
OLIVIER DE WECK:
Not fundamentally.
AUDIENCE: OK.
OLIVIER DE WECK:
And in fact, OPM
has been applied to modeling
how a cell functions.
So there's been some
pretty recent work on--
cells are incredibly-- the
biological engineering is just
really complex.
So there's some
really recent work
on describing even the
RNA and cell division,
using very much this language.
AUDIENCE: OK.
OLIVIER DE WECK: So
it doesn't matter
whether it's an artificial
process or a natural process.
AUDIENCE: Thank you.
OLIVIER DE WECK: Let me
go a couple more minutes,
and then we'll
take a short break.
And then we'll talk
about SysML and Modelica.
So the key thing
in OPM is there's
only one type of diagram.
And there's also
natural language
that gets auto-generated.
And I'll show you this
very quickly in the tool.
So as you can imagine,
as you're working
on real systems, these
diagrams, if you'd showed them
on one sort of level, you'd have
thousands of objects and links.
It would be a mess.
So how does OPM
handle complexity?
There's three
fundamental mechanisms.
One is known as
folding and unfolding.
What does that mean?
It's basically related
to the structure.
So folding/unfolding means
that higher level objects, you
can show the decomposition of
the objects or you can hide it.
That's known as
folding and unfolding.
Then the second one is
in-zooming or out-zooming.
And so here's an example of
a process and an instrument
and an affectee that's
affected by the process.
And I want to know, what are the
subprocesses in that process?
So you can zoom
into this process,
and it will expose
the subprocesses
that are happening inside.
That's known as in-zooming.
And then going back the other
way is called out-zooming.
And then the third one
I've already mentioned,
which is that states
can be expressed
or suppressed or hidden
depending on your interest
and what states of the
system you want to look at.
So here's the sort of Level
0 OPM of our refrigerator.
I said that was kind
of our case study.
So how does the refrigerator
work at the sort of--
Level 0, that's what the
stakeholder, what the customer
sees.
Don't care about the
details of what's
happening in the refrigerator.
So we have food--
and we'll get back to
this I think next week
in the kind of creativity
concept generation.
Why do we have
refrigerators fundamentally?
If you've heard this
before, you keep quiet.
Maybe EPFL.
Why do we have refrigerators?
Any ideas?
Go ahead.
AUDIENCE: Keep food cold.
OLIVIER DE WECK: Yeah, well,
if you're a beer drinker,
you want cold beer.
But if you really
think about it deeply,
that's not really
the primary reason.
The primary reason is this
state change, their shelf life.
So the primary reason why
you have refrigerators
is to extend the shelf
life of the food.
So speaking as a systems
architect, system engineer,
a refrigerator is a food
spoilage rate reduction device.
You see that?
So the attribute of the
food is the shelf life,
and we're going to extend
the shelf life of the food.
If you think about it
sort of architecturally,
that's why we have
refrigerators.
But I agree with you
on the cold beer.
We all agree we want
cold beer, not warm beer.
So you're right.
You're right, too.
So the refrigerator
essentially is an instrument
of extending the
food shelf life.
So the food is the operand.
The food is the operand.
The extending of
shelf life is what
we call the primary
value delivering process.
That's where the value is.
The refrigerator itself
is the product system.
And then the operator sets
the thermostat setting
at which temperature the
refrigerator should be.
And then here we have the
primary operating process,
which is what allows us to keep
the temperature of the food
at that level.
And in order to do this, we
consume electrical power.
We produce waste heat.
And we also require, or
we convect that waste heat
to the exterior air at
a certain temperature.
How well do refrigerators
work in a vacuum chamber?
They don't.
They don't.
There's no way
to-- well, I guess
you could radiate the
heat a little bit.
But they're not going
to work very well.
You're not going
to have conduction
because you're sort of in the
middle of the vacuum chamber.
You're not going
to have convection.
So you only have radiation.
And that's not going
to work very well.
So the exterior air is important
for the refrigerator to work.
So then you say, well, OK.
That's fine.
I buy that.
But now I want to really
know, how does it really work?
So you say operating.
The refrigerator is operating.
But I want to do
in-zooming and understand,
how is it operating?
So what's the key
to refrigeration?
What's the magic word
there, or two magic words?
AUDIENCE: [INAUDIBLE]
OLIVIER DE WECK: Yeah,
that's part of it.
That's just a sliver of it.
Heat exchange is part of it.
So the magic word
is Carnot cycle.
So here's a little graphic
that sort of gets into it.
So the Carnot cycle is actually
a thermodynamic concept
where you're compressing
essentially a refrigerant.
A coolant is being
compressed, absorbs the heat
from the inside and then expands
and condenses and radiates that
or convects that
heat to the outside.
So here's a--
I don't know if you remember
your thermodynamics.
This is a classic PV diagram.
You've got the four legs
of the Carnot cycle.
And actually, what's
really nice here--
so we're going through
this counter-clockwise.
What's really nice about it is
that every leg of the Carnot
cycle is one of our processes.
So compressing is this leg
here from D to B. Condensing
is from B to A.
Expanding from A to E.
And then evaporation
happens from E to D.
So the Carnot cycle
can be decomposed
into four subprocesses.
These are the internal
processes in the system
that are governed by physics.
So if we take that
operating process
that we looked at
before, we can actually
zoom in and see the
subprocesses emerging.
And so in cooling we have
those four expanding,
evaporating,
compressing, condensing.
But I'm adding the
absorbing process,
which is that the
heat then needs to be
absorbed by the exterior air.
We have to power the device.
You can decompose
that into grounding,
protecting, supplying.
Regulation, keeping
it at the set point,
you can decompose that process
into sensing, switching,
and setting the set point.
And then we have
supporting, which
is we need to be opening and
closing the refrigerator,
retaining it, and then
connecting all the pieces.
So at Level -1, we had
one process at Level 0,
which was operating.
The refrigerator was operating.
And then as we
zoom into Level -1,
four processes appear,
powering, regulating, cooling,
and supporting.
And then at Level -2,
we have 15 subprocesses.
So this is sort of
a view at Level -1,
our four subprocesses,
cooling, powering, regulating,
supporting.
And then we can zoom in more.
So here's the general idea, and
we've looked at many systems
over the years, that most
cyber-physical systems--
or it says optomechanical
here, but I really
mean it more generally-- have
this kind of OPM structure.
On the right side,
we have the output
that the customer,
the stakeholder cares
about, the operand.
We have a set of
specialized processes,
and these can be often
organized in a cascade.
And then we have
supporting processes,
like powering,
connecting, controlling,
that provide support for
the specialized processes.
Most systems that we've seen
have this generic architecture.
How do you generate an OPM?
Fundamentally, you
can do a top-down.
So you start with
your stakeholders.
That's what we did
in the first lecture.
Where's the value?
You start thinking
about requirements,
what functions, how well the
functions should be performed.
And you sort of go down.
Or if you already
have a system, you
can actually reverse
engineer that system
and from bottom
up, like we started
doing for the Mr. Sticky,
and that's fundamentally
reverse engineering.
So just for time, I'm
going to skip this demo.
But what I will do is
I will post a video.
I'm going to make a little
video with the OPCAT demo
and post that to Stellar so
you can sort of watch that.
So this is one of the--
it's still not super mature,
but it's a Java-based
program called
OPCAT that allows you to
generate object process
diagrams in a
computer-supported environment
and store them in an XML
format, and so forth.
It allows you to
create a hierarchy.
And the other thing that's very
cool, it autogenerates text.
So the text is called OPL,
Object Process Language.
And right now you can go from
the graphics to the text,
but you can't go the other way.
So they're complete sentences.
It's not like an exciting
novel when you read it.
But it is semantically precise.
So we're going to
switch to SysML.
We're going to take
a very short break.
Are there any
questions about OPM?
In the system
architecture class,
we spend like five,
six lectures on OPM
and you get to do
detailed exercises.
We kind of don't have time
for this in this class.
But hopefully you've
seen what it is.
And if I've whetted
your appetite for OPM,
then the goal has been met.
Any questions about OPM?
Is it pretty clear?
All right.
So let's take-- yes.
AUDIENCE: Compared to
Modelica, because I've
seen one of the
links that OPM is
just for describing
the system, though.
It's not for making
calculations or simulations.
OLIVIER DE WECK: That's correct.
The latest versions
of OPM you can
do like a logical simulation.
So you can say, OK, this process
enables and does this state,
so it's kind of a
discrete logical.
But usually it's not used for
any mathematical calculations.
The purpose of OPM is really
to support conceptual design,
early conceptual design.
That's correct.
Mark.
So just a couple of
words about Mark.
He's a doctoral student right
now in the Space Systems Lab.
He's been working a lot on
an instrument called REXIS.
I guess you're the chief
system engineer for REXIS.
MARK CHODAS: Yeah, yeah.
OLIVIER DE WECK: And
that was also the topic
of his master's thesis.
So Mark really knows
what he's talking about.
He knows SysML quite well.
And thanks for doing this.
MARK CHODAS: So let
me start by giving
kind of a high-level
overview of what SysML is
and what it aims to do.
So it's similar to OPM,
but there are a couple
important differences.
SysML, as Olly said, it
kind of is an extension
or inherits a lot from UML.
And its aim is to really
provide a language that
enables you to capture
all the different aspects
of information about
a system in one place.
And this concept
of Single Source
Of Truth is something that
I'll kind of try and emphasize
during my presentation.
The idea is if all
your information
is in this one model, then
communication is easy.
There's no ambiguity
between versions.
Everyone knows
where to go to get
the most up-to-date and
correct piece of information.
So that's one of the
emphases of SysML.
SysML is a graphical
language, similar to OPM.
It's defined in terms
of diagram types
that I'll go into in a second.
It has more than just
one diagram type,
as compared to OPM.
But basically it
aims to do things
like capture functional
behavioral models,
capture performance models,
capture the structural topology
of your system, the
parts of your system
and how they're
all interconnected,
and any other engineering
analysis model
is one of the big
emphases with SysML,
is integration with
external analysis tools.
So if you have a thermal tool, a
structural tool, an electronics
tool, or something
like that, integrating
this informational,
descriptional model
with that analysis
model and enabling,
making it easy to
transfer information
from your description model
to your analysis model,
do an analysis, and then
incorporate those results back
into your descriptive
model is one of the things
that SysML really is all about.
Then another thing,
another difference
compared to SysML from
OPM is it incorporates
requirements pretty explicitly.
And that's one of the other
areas that people are really
interested in is if you have
good modeling of requirements,
what sort of information can
you glean about your system
that you couldn't otherwise?
How do I advance the slide?
Oh, there we go.
So as I said, SysML is
composed of diagrams.
I'll go into in a
second kind of what
each diagram, what all
the diagram types are
and what kind of
their intent is.
But here's kind of a
high-level overview.
It might be a little
bit difficult to read.
So at the top you
have a system model.
You have requirements,
diagrams, behavior, structure
and parametrics.
Within requirements,
there's actually
a specific requirements
diagram that's
supposed to represent
the relationship
between requirements
in your system.
And I'll show an
example of that.
In behavior, there are
diagrams to describe
kind of the activity of your
system, the sequence of events
that may happen.
There's a state
machine diagram if you
want to model your
system as a state
and transition between those
states, things like that.
In the structure,
there's diagrams
that go over the
decomposition of your system.
What is your system?
And what parts make
up your system?
Both the logical decomposition
and the physical decomposition.
And then there's topology.
How are they all connected?
What are the characteristics
of the interfaces?
Things like that.
And then parametrics,
which is kind
of adding constraints and
numbers to all these things,
whether they be
logical constraints,
mathematical constraints,
things like that.
Similar to OPM, SysML has no
built-in analysis capabilities,
so you can't like run a model or
calculate an equation in SysML.
You can't really do that.
But very frequently the
tools that implement system
that I'll show
you have that kind
of analysis capability
built into the tools,
as opposed to the language.
So you can do things like use a
parametric diagram with a bunch
of equations to create
a system of equations
that you then can solve,
whether it be in the tool,
or you can move it
to an external tool,
like Mathematica or something
and solve it, and then
bring that information
back into your system.
You also can do kind of
sequence-based computation.
If you have an activity
diagram that says first you
have to build this
part of your system
and then this part
of your system,
there's things in sequence,
things in parallel.
You can run simulations like
that where it's all about,
have you done
everything you need
to do to get to the next step?
Things in a more logical
flow, as opposed to actually
mathematical equations, you can
do those sorts of computations
as well.
One note is that these diagrams,
although they are the main way
to define your system and
interface with the model,
are not the model themselves.
So you can create
links between diagrams.
If an element shows up in
one diagram and that element
shows up in another diagram,
that's the same element.
If you make changes
in one diagram,
that's going to propagate
to all your diagrams.
So there's kind of
a database backend
to this whole model
that encompasses
all the information.
So instead of having a bunch
of isolated block diagrams,
they're really just views
into this model that's
hidden in a backend database.
So we'll talk a little bit
about the applications of SysML.
First is requirements
engineering.
As I said, when you can
explicitly model requirements
in the relationship between
requirements and your system,
you can do a lot more.
The way that it's
typically done nowadays
is with tons of documents--
I'm not sure if you've ever
actually developed a system,
but there's an ungodly
amount of documents.
I've experienced that firsthand.
It's a real pain.
There are tools like
DOORS that will enable
you to link requirements
to other requirements,
and things like that that help
you manage your requirements.
But what if you had
a really explicit tie
between your requirements
and your system?
You can actually
represent in SysML.
And I'll show you a
little bit about this.
You can represent in SysML a
textural requirement, you know,
the mass of your system must
be less than 5 kilograms,
or something like that.
You can tie that
requirement directly
to the mass property
of your system.
You can [INAUDIBLE].
You can start
building constraints.
Your requirements aren't
just textual statements,
they're actually constraints
upon properties of your system.
Those are the types of things
you can start to do with SysML.
Do you have a question?
AUDIENCE: [INAUDIBLE]
MARK CHODAS: Yeah.
Yeah, so that isn't something
that's built into the language.
But that is something
you can do with--
basically there's a whole API.
And you can interface
with the model.
I'll show you this,
actually, in my demo.
But you can build in rules and
constraints that say, check,
for example, that all my
requirements, at least how
they've been defined,
are satisfied.
You can run that
check, and it will
tell you have they
been satisfied or not.
And that's something
that's really powerful
that you can't really do with
existing kind of techniques.
Yeah.
AUDIENCE: Thank you.
And can you also, for
example, requirement changes,
like the master system
has to be this much,
as opposed to this much, then
would it go through and check
until you have to now look
at this, this, and this,
and then that affect like-
MARK CHODAS: So you're
getting down in the weeds.
That's something that would
be awesome if you could do.
That really-- again,
that's not something
that SysML enables
you to do natively.
But it gives you the
language and the syntax
to be able to write
queries that give you
that type of information.
That's kind of where the
cutting edge is right now is,
can we do that?
Can we get that type of
information from a SysML model?
That's something I'm really
interested in for my PhD
thesis.
So yeah, that's
something that I think
is possible and would
be really great to have
in the development
process of a system.
So the next bullet here is
on a system description.
So actually one of the
fundamental questions
is, how do you describe
a domain-specific system
within SysML?
I'll show you that SysML
has a pretty strong notion
of inheritance, and
classes, and things like.
It's object-oriented.
And so one of the questions is--
I'm in the space system.
So how do you describe
a spacecraft in SysML?
SysML is very general.
But how do you
actually represent,
for example, a CNDH
system in SysML?
What are the types of attributes
that are typically found?
How do you represent that?
How does it interface with
other parts of your system?
Those type of questions.
That's another active
area of research,
domain-specific modeling.
And then finally, as
I said, integration
with external analysis tools.
So there's quite a lot of
papers in the literature
about going from a
SysML model to MATLAB
to SDK to Thermal Desktop,
external modeling tools,
taking that information out of
the model, doing an analysis,
putting it back in the model.
And actually, I
think there I was
going to talk about Simscape,
which is a kind of analysis
tool, external analysis tool.
And there's actually
been papers written on,
how do you take SysML
information from a SysML model,
pull it into
Simscape process it,
and put it back in the model?
So let's talk
about the diagrams.
There are nine types
of diagrams in SysML.
And I'll try and just give
you a brief explanation
of what they do.
I won't go into the
syntax for all of them
because there's quite a bit
of detail in the syntax.
But I'll show you some
examples of a couple of them.
So we'll go from left to right.
So there's two main classes,
behavior and structure,
similar to OPM.
In the behavior diagram, in
the behavior diagram category
you have activity
diagrams, which basically
represent flows of activities.
So you do this, then you
do this, then you do this.
Those can be tied
to system elements.
If this system element has this
sort of function or property
or performs this operation on
another part of the system,
you can represent
that link as well.
There's a sequence diagram,
which is more about logical
ordering.
So if you have, for example, a
multi-threaded software system,
and you have
different threads that
may need different other
threads to communicate with them
or finish their computation
before that, that way you
can execute things
like that, you
can do that sort of interfacing
between different threads
of activities in a
sequence diagram.
This is one of the diagram
types that was kind of inherited
directly from UML.
So there is a very
kind of strong software
element to that diagram.
There's a state machine diagram.
So obviously, state
machines are very powerful.
If your system has
various states,
if things in your system
have various states,
you can represent that in
a state machine diagram
and then talk about, what are
the criteria for transitioning
between states?
What would trigger or cause
a transition between states?
What are guards that
must be met before you
can transition states?
Things like that.
That's where you represent
the state machine diagram.
These type of diagrams are very
powerful for describing things
like concept of operations.
So there has been some work--
I did an internship at JPL
a couple of summers ago.
And they were trying to
build up this capability
to model a concept of
operations for a spacecraft.
So what are all the power
modes of everything?
What are the time--
you know, it spends
this amount of time
in this power mode,
then it transitions here.
For example, I can give
an orbit of a spacecraft.
That's sort of
the thing that you
can do with this set
of behavior diagrams.
And then use case analysis.
Again, it's mostly focused
on early concept development,
stakeholders.
How do they interface
with the system?
Where do they derive value?
How does the user
interact with the system?
Things like that.
That's where you put
a use case diagram.
Going over to structure,
the block definition diagram
is where you define the
structure of your system.
So the logical or
physical decomposition,
I'll show you an
example of this.
So if your system
is a spacecraft,
it has various
subsystems, if you
want to decompose it logically
as a thermal subsystem,
a structure subsystem,
ADCS subsystem,
things like that, you can
also decompose it physically
so your spacecraft has solar
arrays, it has instruments,
it has thrusters,
things like that.
You can represent those types
of things in a block definition
diagram.
And then internal
block diagram is
where you describe the ties
with the interfaces between all
the components of your system.
And this can be at
varying different levels
of abstraction,
as I'll show you.
Parametric diagram is
kind of a subdiagram type
of the internal block diagram.
So you can, again,
put constraints,
mathematical, logical, things
like that, on your interfaces
and begin to build up the
infrastructure for doing
computation in the model.
And then a packaging diagram
is not terribly important.
It's really focused on the
organization of your model.
How do you scope things?
It's kind of a modeling
diagram as opposed
to a representation
of your system.
Then last of all is the
requirements diagram up top.
So again, I'll show you
a good example of this.
But that's where you represent,
how are your requirements
related to your system?
And then you can see
here what's been modified
and what's been taken from
UML and the new diagram types
of requirement and parametric.
There were a couple
of diagram types
that were eliminated
from UML that
were pretty software-specific.
I think there is one called the
deployment diagram, like how
has your software been
deployed across various servers
or users?
Things like that.
That's not really-- that's a
pretty software-specific thing,
so in a general
system you might not
care about that all that much.
So that diagram was removed.
So let me quickly go
over some of the syntax.
So this is an Interface
Block Diagram, an IBD.
And this is the type
of diagram that I
find is really interesting
representing these interfaces.
So here's the system
engineering ontology
we typically talk about.
So this is basically a
model of an avionics board.
So you have things like
voltage converters.
You have memory,
volatile, nonvolatile.
We have an FPGA, which is
our main computational unit.
We talk about these as being
parts of a system in terms
of system engineering ontology.
Then these are these interfaces
or these lines right here.
So in SysML, the way we
talk about it is these
are part properties
of the system.
It's kind of like an
instantiation type of thing.
What we're saying is all of
these parts can represent
independent of each other.
And then you define a
property of that part
as being part of
a different part,
if that makes any sense at all.
So for example, this is a board.
This main electronics
board is this whole block.
And then that has some
blocks within this block,
which represent the subparts
that make up the board.
And these are called
part properties
of this overall block.
We have these green little
boxes, which are called ports.
And again, that's
to support this kind
of system-independent modeling.
So you can model like a
voltage converter independent
of any type of system
as maybe an input
voltage and output voltage.
You can define what ranges
those are, things like that.
And you can model those
interfaces using ports.
And then these connectors, which
are called connectors in SysML
which represent the
interfaces, represent
how each part is tied into
the kind of larger system.
And you could, for
example, check that you
don't have any empty ports.
If a part needs
an input voltage,
you could run a
script that checks
that all the parts have all
their ports kind of satisfied.
That's something you
can do with SysML.
So before I get
into the case study,
I want to talk a little bit
about what you're going to see.
As Olly said, I work on
something called REXIS,
which is the REgolith
X-Ray Imaging Spectrometer.
It's an x-ray
spectrometer that's
flying on NASA's OSIRIS-REx
asteroid sample return mission.
I've been working
on it since 2011,
when I was a senior here
all throughout my master's,
and then now for my PhD.
Basically we're going
to measure x-rays
that are fluoresced from the
asteroid surface in order
to tell what the elemental
composition of the asteroid is.
So that's our main science goal.
And that will
basically enable us
to categorize where
the asteroid is
within the different
meteorite types that
have been defined on the ground
based upon existing meteorite
samples.
So what I did for
my master's thesis
was modeled the design
history of REXIS.
So how has our design evolved
from the very beginning
where it was very open
ended, very abstract,
and you'll see this,
to the current design,
which current in this case
was CDR which was over a year
ago now.
Right now the current
state of REXIS
is we're almost ready to
mount to the spacecraft.
So it's very exciting.
Just to give you an
idea of a timeline,
this is something I'm sure Olly
will talk about in this course,
is the flow through the
system development lifecycles.
So we have a system
requirements review back
in January of 2012, system--
I think it's definition
review, April 2012,
preliminary design
review January of 2013,
and then critical design
review February of 2014.
So I created models at each of
these design points in SysML
and looked at, what are the
lessons we could have learned?
We didn't use the
SysML in REXIS.
I was kind of looking
back historically,
what if we had used it?
Could we have designed
our system better
in any sort of way?
So here is kind of
a CAD representation
of how a design evolved.
And I think you can
kind of get the idea.
Back at SRR, a lot of
things we didn't really
know what they would look like.
We didn't know what the
interfaces would be.
We didn't know what
all the parts would be.
We had a little more
development for SDR.
You can see there's more arrows.
The CAD is a little
bit more detailed.
PDR, we had even more detail.
This was actually like
a buildable design.
This turned out to
not even be buildable.
And then we had more
evolution between PDR and CDR
to get to pretty much
where the design is.
There's actually
been some evolution
after this as well, as sometimes
happens with a new system.
But you can see just
graphically kind
of the increase in level
of detail and level
of fidelity of the
state of our system
throughout its
development cycle.
And I'll show you that and how
that looks in the SysML model
as well.
So one of the things you can
do if you have a SysML model,
is as I talked about,
you can run queries on it
and pull out information that's
very difficult or impossible
to get with our current
deployment practices.
So this is just looking at
the different subassemblies
within REXIS.
What are the number of parts
in each of the subassemblies?
So you can see the general
trend is up for all of them,
as you would expect.
Some jump up very high.
Some kind of stay
basically where they were.
But in general,
they all increase.
And this is something
you might be
able to do with looking
at like a parts list
or something like that
with current methodologies.
But it would be very hard to
get this information, which
is the number of
ports per assembly.
So each interface has two ports.
So these numbers divided
by 2 basically equal
the number of interfaces that
we have in each subassembly.
And you can see, again,
there's a general trend
of increasing number of ports
as you go through the lifecycle.
So this is a piece
of information
you might want to use
if you want to manage
the complexity of your system.
And you say, this
subassembly is getting--
it's way too many interfaces,
way too many parts.
It's way too complex.
We need to think about
how we've logically
arranged our system
and maybe how can we
rearrange it to make it more
understandable and easier
to work with.
And then you can divide the two.
And you end up looking
at how many-- this
is ports per part in
each subassembly at each
of the design reviews.
And you can see trends here,
too, which are interesting.
So you can see in the
beginning we didn't really
know what we were doing.
Some of these had a lot
of parts, ports per part.
Some of these had very few.
They all ended up
stabilizing kind
of in between the three and
five ports per part range.
And then you can look
at the literature
and say, well,
typically systems tend
to be between five and
six ports per part.
So what does that mean?
Does that mean that our system
didn't model it correctly?
That's one possibility.
It didn't model it to the lowest
level of fidelity possible.
Does it mean that our
system is too simple?
Does it mean that
we're missing something
that we haven't thought about?
Does it mean that
our system, which
was intended to be simple
and cheap and implementable
by students is actually
achieving that goal
because it's beneath what
you typically expect?
Those are the types of questions
you can ask with this data.
But this data is not easy to get
with the current methodologies.
So this kind of very
simple queries you can do
gives you power on managing
complexity in your system.
So let me now transition
quickly to the demo.
Let's see.
There's no sound.
AUDIENCE: I know, but
I need to sync it up
to make it [INAUDIBLE].
OLIVIER DE WECK: So while Mark
is setting up for the demo,
are there any questions
about SysML so far,
any observations you guys have?
Maybe at EPFL.
Do you see the similarities
and differences
between OPM and SysML?
What's the biggest
difference between the two?
There's two really
important differences.
GUEST SPEAKER: No questions?
Yes.
AUDIENCE: I was going to ask--
OLIVIER DE WECK: Hang on.
Hang on.
Is there anybody at EPFL who
wants to comment on this?
AUDIENCE: No, there is
no comment from EPFL.
OLIVIER DE WECK: OK.
Good.
That's fine.
That's fine.
Mark, are you set up?
GUEST SPEAKER: Almost.
OLIVIER DE WECK:
What I would say is--
so first of all, OPM has
only one type of diagram,
and then you go really deep,
sort of a deep hierarchy.
SysML has nine different
types of diagrams
split between behavioral
and structural.
So that's one difference.
And then the other is that
the SysML is fundamentally
object-oriented because it comes
from object-oriented thinking
and software, whereas OPM
has objects and processes
sort of at the same level.
Those are two of the most
important differences.
MARK CHODAS: All right.
So what I'm showing you--
can everyone see the screen?
Just let me know if you
can't see the screen.
What I'm showing you right now
is a tool called MagicDraw.
There are basically a
variety of tools provided
by commercial vendors that
enable you to build and work
with a SysML model.
So SysML is a language, and
then it's implemented in tools.
And this just happens to be
one that's fairly well, fairly
widely utilized.
Unfortunately, it's
quite expensive.
But anyway, so what I'm
showing you right now,
and this is going to be a little
bit difficult because, as you
can see, you need a big screen.
What I'm showing you right
now is a requirements diagram.
So you can see that right here.
It's a requirements diagram.
And each of these blocks, as
you can see by the tag here,
is a requirement.
So this is one of our
operating criterias.
Well operating temperature
of all our components
shall be maintained
within operability limits.
Straightforward requirement.
And you can create these
satisfy relationships
between that requirement
and the components
in the system that must
satisfy that requirement.
So right now, this is being done
at SRR, as you can see up here.
So this is very
early in the design.
So we don't have it broken down
fully to all the components.
But we have-- here is our
main electronics board.
It has to satisfy
that requirement.
Here's our radiation cover.
It has to satisfy
that requirement.
So you can tie these two
things, the requirement
and the part of the system that
must satisfy the requirement.
And here I've tied it to parts.
So these are called
blocks, which
are the fundamental unit
in SysML, is a block.
So these represent
parts of our system.
But you could tie it to
a property of that part
if you wanted to.
So then you get
into the situation
I talked about
earlier where you have
the requirement is on the mass
of it must be less than this.
You can tie it to the
mass of the system itself,
as opposed to the system.
You can tie it to the actual
property, which is very useful.
So let me quickly show you
one of the cool things.
If I delete these requirements,
I'm not actually--
you can see there's
no requirements.
I'm not actually deleting
them from the system itself,
but I'm just doing it as I'm
removing it from the diagram.
But if you wanted
to, you should be
able to look at related elements
of the different blocks.
So I just clicked
on a block, and I
can choose to show all the
requirements, all the things
that are satisfied, the
requirements of that component
of the system satisfies.
And these requirements pop up.
So this is showing how
the diagrams themselves
aren't the model.
There's actually
backend to the model.
And you can kind of
work in the diagram
and show or hide things
however you want.
But the information is actually
kept behind the diagram,
so to speak.
So my research looked
into typologies.
So let me just kind of show you
a little bit about what I did.
So this is a block definition
diagram, again, defining
all the parts of your system.
And I just want to give
you kind of a high level
idea of the type of
things that we saw.
So it's big, first
of all, very big.
These are all the
parts of the system.
So we start high like
the mission context,
and the mission
context contains things
like the environment and the
spacecraft and then REXIS.
And then you can
break down REXIS.
We have these various
subassemblies broken down
to parts.
And that's how you get
this tree structure.
And then this tree structure
can be tied together.
I can zoom in, but
it's big again.
So these are all the
parts of our system.
Let me give you an example.
So we have a couple
of boards that we
call our detector electronics.
And those detector electronics
have various ports.
One thing they had to
do, they had this port
in here and this interface here,
which connects to our CCDs.
So this is showing how you can
build interfaces and SysML.
So here are the green
boxes, again, or the ports.
The lines are the
connectors, and they're
defining all the interfaces.
And you can see at a high
level how complicated things
get very quickly.
This is the earliest, most
abstract version of our design.
And it already has a
lot of complication.
One thing you can do--
I talked about running scripts.
I'll show you how that works.
It's quite easy.
So I just ran a script
on the model that
told me to find the number
of parts in the scope
that I defined and
the number of ports.
And here's the output of
that model right here.
So the script itself is
not even very complicated.
It's like 50, 60 lines of code.
And immediately I can pull out
how many ports, how many parts,
things like that,
information down my system.
So let me kind of take you
briefly through the development
process.
So that was, again, the
highest, the most abstract,
the earliest version
of our system, SRR.
This is SDR.
You can see it's starting
to get a bit more complex.
And then you can go
over to PDR, and it
starts to get really scary.
And you can go to CDR,
and it's just a nightmare.
So I created all these systems,
all these models by hand.
You can actually build
the model with the script,
if you would like.
You can basically do things
like define a pattern
and then apply that pattern
to all the parts of that type.
That's all possible
through the API.
And just to show you how much
of a nightmare it was at CDR,
let me run the same
script on the CDR model.
You have 230 parts
and 900 interfaces.
And this was not even
modeling to the lowest
level of fidelity possible.
I didn't, for example,
model all the components,
all the capacitors,
resistors, op amps, and stuff
on the board.
And now you can already
see it's quite large.
Kind of the idea
behind these models
would be to extend this to the
lowest level in a real system
and use this, basically use
all the capabilities that you
had with the model
to really manage
your complexity in a way that
is just not possible currently.
And there's no
way you can really
mentally keep track of
all these interfaces
and understanding how
your system is working.
So having this
modeling capability
and querying capability is
really, really powerful.
Yeah?
AUDIENCE: What was used
during REXIS for the systems
engineering?
You had applied
this after the fact.
So what was used to create these
block diagram or [INAUDIBLE]..
MARK CHODAS: Do you mean during
when we were developing REXIS?
AUDIENCE: Yeah.
MARK CHODAS: We basically
didn't have this.
So we were relying--
as you would typically do upon
the capabilities of the system
engineer or the team--
you'd to have documents.
We have a ton of documents.
But I was talking about how
things weren't buildable.
I found a situation
where because of the way
we had done our
thermal system, we
were dumping spacecraft
heat to space,
which you don't want to do.
I can explain why, but
you don't want to do that.
And that's something we
didn't realize at the time.
If we had tried to
build it, we would
have had this
property of the system
that we didn't know
actually existed
until I went back and
looked at the model.
So we definitely miss things.
And this should have
improved the design process,
if we had been using it.
OLIVIER DE WECK: Great, so
Mark, sort of to wrap up,
because we've got to switch
over to [INAUDIBLE],, what's
your recommendation for, let's
say, students in the class
got sort of intrigued by SysML.
What's the next step?
MARK CHODAS: There's a
couple different ways.
Certainly if you're
interested, let
me know, and I can
give you resources
to further your understanding.
As I said, working
with these tools
can be expensive
to get these tools.
So I can help you understand
what that would take.
There are beginning to
be some companies that
will do like SysML training
courses that will sit down
for a day or a week
and teach you SysML,
basically, how to work with the
model, how to build the model.
I took one of those courses.
It was really great.
Yeah, talk to me if
you're interested,
and I can steer you
down the right path.
OLIVIER DE WECK:
Great, thanks, Mark.
MARK CHODAS: Sure.
OLIVIER DE WECK: Very good.
So we did in 20 minutes what
usually takes about a week,
right?
MARK CHODAS: There's
a lot more depth.
There's a lot more depth.
OLIVIER DE WECK: Great, so
we're going to switch over now
to Modelica, which I think is--
we're going to maybe run a
couple of minutes over today,
but I think it's important
we cover all three languages.
So let's get the slides back up.
And I'm going to
switch here to Narek.
He's another doctoral
student in the group.
And so introduce yourself and
then tell us about Modelica.
NAREK SHOUGARIAN: Thank you.
OLIVIER DE WECK: Are
you using this computer
for slides or this computer?
NAREK SHOUGARIAN: For the demo,
I'm going to use this one.
OLIVIER DE WECK: This one?
NAREK SHOUGARIAN: This one.
OLIVIER DE WECK: This one.
NAREK SHOUGARIAN: Thank you.
So hello, everyone.
My name is Narek.
I'm a doctoral student
at AeroAstro here.
My background is in
gas turbine engines,
and specifically
I've been looking
at concept generation of gas
turbine engines, automated
concept generation.
And the way I got
acquainted with Modelica
was that I needed to be
able to rapidly reconfigure
different concepts and
simulate them mathematically,
do physics-based simulations.
So in contrast to the
first two languages,
Modelica is a lot
more about rapidly
being able to build
physical models of systems
and reconfiguring them and
reusing them for later on.
So like I mentioned,
Modelica is primarily
about modeling physics-based
modeling of systems
and rapidly being able to reuse
models and reconfigure them.
It's a language, again.
It's not a tool like the first
two that you heard about.
There are many different tools
which implement this language.
But I'm going to start
off with just describing
how the language works
and then go on to describe
which tools that you can use.
In contrast to SysML,
there are a couple
of really good free tools
that you can use and rapidly
get into.
And there are a lot
of libraries that you
can use with hundreds,
even thousands,
of actually basic components
that you can use for modeling.
So it's a declarative language.
And what I mean
by declarative is
that in sequential
sort of programming,
you write commands.
And you make assignments
to various parameters.
Here, you just describe
the governing equations
of the components
you want to simulate.
And there's no particular
order in which you do this.
The models are acausal.
There's no direction to flows.
All you really need to do is
describe what ports, like Mark
mentioned.
It's similar in this
situation-- what kind of ports
you have, what
kind of interfaces
the components can have
with other components,
and the governing equations and
the parameters and variables.
It's a multi-domain
modeling language,
so it's like agnostic
to what kind of domain
you're working in.
It's not particular to
electrical engineering.
For example, I'm
going to be showing
an electrical
engineering example
and also show a gas
turbine engine example
with aeroelastic vibrations.
So you don't necessarily--
you're not attached
to any specific domain.
It's also
object-orientated, and it
enables you to decompose
systems into subsystems
or recombine them and look
at them at various levels
of abstraction.
It's designed to be efficient.
So this is a quote from
Professor Peter Fritzen
at the Linkopings University.
So these are just about
the scale of problems
that you can solve with
the Modelica language.
Obviously, it depends on
what kind of equations
you're talking about,
but it's designed
to be a very efficient
way of simulating systems.
So I really want to
talk a little bit more
about this idea of
acausal modeling
that I mentioned before.
So on the left hand
side is an assignment.
And that's typically what you
do when you program in MATLAB,
just the MATLAB normal scripts.
f is assigned to ma or p is
assigned the value of rho rt
for the equation
of state of a gas.
And what that means
is that you know
what the mass and
acceleration are,
and you figure out the force.
You assign that
value to the force.
In Modelica, there's
almost none of this.
It's equations not assignments.
And what I mean by
that is this equation
can be written in any which
way, as long as your system
has the same number of
equations as unknowns.
The tool that you're using
will interpret the language
and will solve your problem.
So you can write this
in any which way you
want in any order.
As long as your problem
is properly constrained,
the tool that you're
using will interpret it
and solve the problem for you.
So just to go into a little bit
more detail, all of Modelica's
and also other acausal
modeling language that I'll
mention in a little bit--
which one of them is Simscape--
have essentially three parts.
They're designed to
be extremely simple.
The first, like Mark
mentioned, are ports.
It's essentially identical
to SysML in a way.
Ports are the ways
with which components
can share information, material,
or energy, for example.
You can define any
kind of port you want.
All you need to really do is
define what kind of parameters
it carries-- like for gas, for
example, temperature, pressure,
and mass flow; or for electrical
ports, voltage and current.
The second part of
any kind of model
that you're building in
Modelica or Simscape,
which I'll mention
a little later,
are variables and parameters.
So you just declare those.
And the third part are
governing equations.
The point is that
there's nothing else.
It's just that.
And I'll just brief briefly
go through a very, very
simple example.
So for example, a capacitor.
This is the entire
code for a capacitor,
and this is what will generate
a visual image of a capacitor
with the correct ports for you.
First you have pins that
carry voltage and current.
So the key thing to notice here
is that there are fundamentally
two types of variables-- flow
variables and normal variables
here.
Flow variables are ones
for which the Kirchoff's
current law applies.
So mass flow, for
example, every time
you connect 15
components together
in a network, mass
flow into that network
needs to be conserved.
So the sum of mass flows
into any node has to be zero.
That doesn't apply to
the standard variables.
So then you essentially define
the parameters, the variables.
And you need to define
the governing equations.
And that's the
capacitor for you.
There are slightly more
complicated components
that you can use, for example
a pressure drop component.
Did I lose my sharing?
No.
In this case, the main thing
to take away from this one
is that if you have
complicated mathematics
describing the fluid
mechanics in a component,
you can actually
initialized with one model
and then go to a full
turbulent simulation.
That's what this is doing here.
So just to get to the tool side
of the equation, the language I
just showed you, it's the
same across all the tools.
But there are many
different tools
which you can use free and
commercial to actually run
these models.
The main one that you'll be
using if you want to get deeper
into this is OpenModelica.
It's free.
It's actually become
quite user-friendly.
And there's a link in the slides
from which you can download it.
There's one from Wolfram.
It's integrated
with Mathematica,
which is quite useful.
And there's a free
trial of it as well.
There's Dymola.
There are other ones.
But mainly, I think
OpenModelica is the one
that you guys will be using.
OLIVIER DE WECK: OK,
so in other words,
I think we're going to
wrap up and then have you
back next week.
NAREK SHOUGARIAN: OK.
OLIVIER DE WECK: Are
you around next week?
NAREK SHOUGARIAN:
Yeah, yeah. sure.
OLIVIER DE WECK:
Just to stay around.
So basically we're going to
finish this lecture next week.
I think it's important enough
that you really see the demo
and see sort of the--
and it actually ties in kind of
nicely with next week's topic
is concept generation.
This is the next step in the V.
And since Narek, your research
is also on concept generation,
it'll tie in nicely.
So I think we're going
to stop here for today.
So you heard about the general
idea of system modeling
languages that are rigorous,
that have ontology, syntax
and, semantics.
There's different of these that
have been proposed, developed.
Some are used more than others.
There's really important
differences between them.
So OPM is very conceptual.
SysML is based on UML and
has these different type
of diagrams and can
really help you flesh out
your design in more detail.
And then Modelica allows
you to build these blocks.
It's acausal or declarative.
And you can actually simulate
the physics of the system
pretty readily.
So the big picture here,
just to wrap up here,
the big picture
is the following.
And we'll come back
to this next week.
The big picture is basically
that system engineering
is in a transition phase.
The classic way of doing
system engineering really
for the last 50 years is on
the left, document-centric.
Write your requirements.
Do your drawings.
Even CAD, you know,
computer-aided design,
is great, but it
only essentially does
the mechanical
part of the design.
And so the result of that
is as you get-- even REXIS,
REXIS is a box, like
shoe-box size, basically.
And it's going to fit on
a much bigger spacecraft.
And you saw how much
complexity is there.
And it gets very, very difficult
to manage all this information,
to prevent errors, oversights,
any change that you make.
It doesn't propagate
automatically
in these documents.
So the transition is
happening to the right side,
a model-centric way to
do system engineering.
And think of
paperless engineering.
Everything you're
doing is in a model.
The models are linked.
The models are executable.
The models automatically
propagate any changes
that you make in
requirements or design.
We're not quite there yet.
But that is where
things are moving.
And so keep that in mind.
So there's no new
assignment this week.
So next week, we have A-2,
which is do, the requirements.
Please let us know if you
have any-- we're here for you.
So I'm going to have office
hours now on the WebEx.
You have the link.
If you have any
questions about A-2,
don't be shy to email me or
[? Yuanna ?] or [? Leislu ?]
at EPFL.
We're really here to
answer your questions.
So next week topic, we're
going to finish on Modelica,
and concept generation is going
to be sort of our-- creativity
concept generation is
our main topic next week.
