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.
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.
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.