Get rid of all those pesky words and use images instead.
Which I'm on board with actually.
Yeah. And over to Frank. Thank you very much.
Thank you. So, maybe hold off with the applause till I'm finished and then make up your mind.
So I'm Frank van Bever and I'm here to talk.
Well, I have this talk.
Drop the docs and embrace the model with G4, which might be an incendiary statement in this room.
Louder.
Louder? OK. I'll try.
Can we also put a mic down?
I think people are deciding.
So, yeah, and so it's going to be a quick introduction to what model based systems engineering is using free and open source tools.
That's what we're here for on Fosdham.
So first real quick, because this is not the interesting part.
I'm Frank, father of two.
If I look tired, that explains it.
I'm a bass player.
I've been successfully daylighting as a software developer for the last 10 years.
I trained as an electrical engineer.
I actually had my digital systems like my DSP courses, so digital signal processing on this floor in this building.
And so, yeah, I'm specialized in embedded systems, but I like to think I'd know just enough of the rest of the stack to be dangerous.
I work for a company called Mind.
We do embedded software for well, free and open source software for embedded systems.
If you enjoy the referencing pointers as a job, then come talk to me later if you're looking for a job.
And so currently I am a software architect in a robotics company, a company that makes autonomous guided vehicles.
So with that out of the way, quick outline of what I will be talking about.
So first, if we talk about model based systems engineering, I, well, I can't talk about what modeling is without explaining what model based systems engineering is.
There's three pillars to MBC, modeling language, modeling method and modeling tool.
And then I'm going to be talking about G4, free and open source application.
There's a modeling tool and then how you can also use it for documentation and additional tooling that you can build around your model.
So first of all, what is a model?
And it's a bit abstract.
It's an abstraction of a system aimed at understanding, communicating, explaining or designing aspects of that system.
And so a model really is a central repository for design decisions you make about a system.
And these are captured as model elements and the relationships between these elements.
Typically, you have, you use these graphical languages and you have a set of views that describe this, the described model.
However, and that's an easy trap to fall into these views of the model don't represent the model itself.
Really, the model is like the entire containment tree and the view is just like the single thing.
And yeah, well, I'm from Belgium.
This painter, René Magritte, he painted this thing called the Trison des images, which translates to the treason of images.
That's exactly the same thing that you have with these views.
The view is not the model.
Then expanding on that, what is model-based systems engineering?
And so model-based systems engineering is like a formalized application of modeling to support really capturing system requirements,
doing system design analysis, and then also the verification and validation of a system.
And this is throughout the entire lifecycle of a system from the initial concept through the development, then commissioning of a system and decommissioning of a system.
And actually, this is as an alternative to what is called a document-based approach, and that's where the drop the docs comes from.
So I'm most definitely not against documentation.
The more documentation, the better.
But so typically these, well, it's a different approach from writing large amounts of prose to describe what a system should do and instead use these more formal graphical languages.
And I'm thinking that most of you will be involved in documentation in some way or another, otherwise you wouldn't be here.
And my idea is doesn't describe all your documentation efforts.
So these three pillars.
First, there's a modeling language that you need to describe your system.
There's multiple options that exist, typically graphical.
I will be talking about a system specifically today.
Modeling methods is then the way you organize your model.
And once again, there's also plenty of options out there, and this is really dependent on the processes of your organization.
And so because of this really, if I have to talk about modeling methods, then I would probably need the rest of the day and tomorrow as well.
So it's beyond the scope of this presentation.
Really what I want to do is just give a quick introduction.
And then finally, you need a modeling tool to bring together your modeling language and your modeling method and really build this model.
And so mostly these very large, very commercial, close source tools with like a six month.
Well, if you want to buy it, you need to first make, well, these very large tools from IBM, from the SOH system seem to be very popular.
But I'm here talking about G4 as like a free and open source alternative for these tools.
So, and then Napoleon, he had this quote that a good sketch is better than a long speech.
And I think that might actually make him the first model based systems engineering practitioner besides he did some other stuff too.
But OK.
And so the good sketch, SysML is the systems modeling language.
It's a graphical language and it's actually a profile, which is like the extension mechanism of UML, which you may or may not have heard of.
There are some differences though between UML and SysML.
First of all, UML really is software focused.
It has this concept of a class and everything is built around that.
SysML on the other hand, moves it an abstraction layer higher and talks about blocks.
Another thing that we, well, that the organization that I work for that we really like about SysML is that it has this built in concept of a requirement of requirements.
And that requirements can be, well, basically you have these requirements, they can be refined, they can, you can have derived requirements.
And then these requirements can be assigned to different parts of a system.
And generally, this is like a good way to make sure that the necessary information gets to the people doing the actual development work.
So yeah, point is it really, the SysML has like a systems focus, whereas UML is more of a, really more of a software focused thing.
And so there's nine types of diagrams.
These activity sequence, state machine and use case diagrams, those are all just lifted from UML, put into SysML, these are the same thing.
The requirements diagram is where you describe your, well, where you describe the requirements of a system.
You do derivation, basically build up a tree of requirements.
And then these structure diagrams, these have analogs in UML.
But so you have a block definition diagram where you decompose the system into the blocks that make up the system.
And you have the internal block diagram where you then take these blocks and makes show how these are interconnected, how these are interconnected.
And what the interfaces between these blocks are, you have the package diagram, which is really about, well, which is the tool that you would use for your modeling methodology.
It allows you to split off different parts of your model into packages to keep the overview.
And then finally there's also a parametric diagram, which is a special case of the internal block diagram.
And this is usually used for when you want to do systems simulation.
G4 doesn't do this, so I'm not going to go into this too much, but from, well, I've read some things on the developer chat.
And so it's something that is being worked on, so that's exciting.
Well, I think some of you might be thinking, haven't we tried this before?
And, well, sometimes I feel old, sometimes I feel young.
It depends really, but so I was a kid back in the 90s, but UML really, we tried, I think you might have like a reaction of, haven't we tried this before?
UML, alderage.com boom and whatnot.
If we can believe Vogue magazine, Y2K is entirely back, so yeah, that's, and so, yes, actually, this is UML.
It's an extension of UML, but there's some observations that I've made in the field.
Well, there's some observations that I've made.
First of all, we have this Myro board proliferation.
So Myro is this application that is like a digital whiteboard and, yeah, well, it's natural for people if they want to explain something.
The most natural thing if you want to explain something is you go stand next to a whiteboard, you draw some boxes on it, you draw arrows between those boxes,
and you try and explain what is going on in a system.
And so Myro is being used a lot, but these things, well, if you don't have the context of the human sitting next to it,
doing the explanation, then you start getting these problems of like, okay, what did they exactly mean here?
What is the grammar? What are the semantics?
I don't really understand, well, it's hard to understand what this means without having a lot of pros next to it or the actual human being doing the explanation.
And so actually the block diagrams that SysML has, they already map to what people are doing informally as well.
So, and a bad model is still good documentation.
Bad not in the sense that it is describing a system different from the actual system,
but bad in the sense that it's not a perfect application of the SysML specification,
because that's what people are already doing.
Another thing, of course, is that software architecture is basically systems engineering,
and that mostly every developer is also kind of a bit of an architect.
I don't know of a lot of people that don't have, well, that really lack that level of agency in their job,
that they can't make some architectural decisions from themselves.
And that is where a free and open source tool like the four also comes in nicely,
because it is widely available, it's easy to trojan horse it into your organization.
Which brings me to G4.
It's a multi-platform graphical modeling application.
It's written in Python, uses a GTK UI, and it supports multiple modeling languages,
UML and then SysML, RA, ML and C4 as extensions of, implemented as extensions of UML.
It's Apache 2 licensed, free and open source software, otherwise I wouldn't be standing here.
And it's extensible in multiple ways.
It has a plugin, well, it supports plugins, but you can also extend it in other ways.
And a quick thing, I'm not affiliated in any way with the project, I'm just a fan.
I really like what they're doing.
I have some ideas for development work that I can do, but I need to find the time.
And so one of the nice features that I really like is that it integrates very nicely with Sphinx.
So if you've ever seen like a read the docs website, it's Sphinx on the back end.
And so it, if you basically can have your model sitting in a repository,
sitting in a repository, you push your changes, it rebuilds it, your CI system then can just rebuild the website
and take these diagrams that you've drawn inside of your model and plug them into this page,
well into this Sphinx static website automatically.
So, yeah, we found that that is like a good way to communicate architecture to downstream engineering.
So you have, you basically can have all your diagrams specifying a specific part of a system.
And so you draw these diagrams, you maybe add a bit of words in between, even though I said like drop the docs,
but there's still some sense in writing a bit of prose to introduce it.
But you have these formally defined things that show that, okay, this is the idea that we have, this is what we're going to build.
And so it's a good way to communicate these decisions and the IDs to downstream engineering.
Also, we, so we intend to use this for like these architectural decision records.
So if like an architecture decision is made, you, we put it into the Sphinx site and you do, well, basically,
if everybody reviews it in the CI before, before it gets merged, then you've basically, well,
the necessary people can sign off on it before the decision actually becomes like a written law.
Let's say, yeah, another thing that's really nice is that so because before it's a graphical, it's Python,
it's a graphical application, but you can also just use it as a Python module.
So it integrates very nicely with Jupyter notebooks, which is like this interactive programming environment model.
Your model has an API, so it's perfectly possible to just query your model and ask questions of, well,
basically ask the model questions and get answers from it in this, in this interactive environment.
The Jupyter itself also is like a little programming tool, so you can also add some, well,
you can display diagrams inside of your notebook, add text and really create like a narrative structure inside of your Jupyter notebook,
and also serve as documentation.
So, yeah, you can explore your model and collaborate with other people.
Very nice, very nice feature.
And then finally, because the thing, well, because your model has an API,
it's perfectly possible to have it be, well, to, if it has an API, you can test it.
And so if you, we've combined before with PyTest in our CI system,
and basically what we do is we run a bunch of tests against our model,
or this is like a screenshot that I took from the single test that runs against it.
So, and it's test, if all the requirements, if all these requirements are satisfied,
so you can have a block which can have, well, you can have a requirement,
and then there's a satisfies relationship that define in SysML that you can say,
okay, we have this block satisfies this requirement.
And ideally, if you have a set of requirements, all of these should be satisfied.
This is something that you can test, and the plan of your system is, well,
the plan for your system basically should satisfy all these requirements.
If that's not the case, then you have a problem.
Another thing that you can test for is, does every block have a reason to be there?
So, one of the things that Gaford does for you already is that if a block is no longer represented on any view,
then it's automatically deleted.
But if a block does not have any requirements associated with it,
they might also raise some questions like, okay, does this thing really need,
does this need to be there?
Other examples of things that you can test against is like interfaces.
Two blocks are connected, and they have ports.
These ports expect certain things.
Are both parts of the system expecting the same thing?
If not, then you have a conflict of the contract between those two blocks.
And, yeah, well, basically, it allows you to detect those types of problems before the development starts,
and then, yeah, potentially, you can reduce some wasted effort there.
And so, yeah, you know that it's a real CI system because, well, it's in red.
But, anyway, that is basically all I wanted to say today.
I hope I gave you an okay introduction, at least, to this concept of model-based systems engineering
and then how Gaford can help you with that.
I don't know how much time I have left, but...
Two minutes.
Sorry.
Whoa, three in a row.
Oh, four.
Okay, left there.
I think the key question is, are you going to stay in this room after this talk, or are you leaving?
So I would like to ask you several questions.
We can go in the hallway.
You can ask me.
That was a very good question.
Right.
Do you use it for modeling software systems, or mechanical systems, or electrical systems, or everything?
So it supports modeling all of those.
For us, mainly, we've been using it.
So one model I have built includes electrical components, like off-the-shelf components that we buy,
software components that interact with those things.
So the system in itself has support as well, except multiple voltages for powering it.
So it can be like 24 volts DC, but also 230 volts AC wall power.
It's all stuff that you can put inside of your model.
Very, very quick one.
I guess you use the model to generate those.