Welcome to the third episode of Avians Official Systems Engineering podcast, this episode we're talking about what it takes to be a modeler. And I understand, as Rhett has informed me, modeler is a little bit of a controversial term.
So let's before I'm ready to jump into questions, let's introduce everybody today. I have Casey, Rete, Jeff and Lindsay on the line with me. We're here to talk about exactly what the Meyler is and what it takes to get to being a modeler.
So the first question for you, what what's the right term for modeler? And we we talked about this a little bit already, but for the recording, can you explain maybe why modeler is not a great term for it and what the correct term would be?
There's a lot of back and forth, a lot. It's a modular small systems engineer, systems engineer, architects, and a lot of people use a lot of different terms. There's a bit of a negative connotation, I think, with modular kind of being equivalent to Kajaki.
Most of the people in a system engineering or model basis in general have either bachelor's or advanced degrees in systems engineering or related field. So being a carjacking is a bit of a downgrade, I would say. So same concept.
It's one thing to know how to use the tool. It's another thing to be able to architect that tool or go above and beyond, just doing the mouse clicks. So I think that's probably the distinction there. Yeah, and basically what you said is that the correct term is the mouthful of model based systems engineer and a lot
of people to say mouther because it's easier, but it might not be correct all the time. Yeah, so. Can and we talked about this in the last episode a little bit, where we gave an overview of what model based systems and engineering is, but can you give a detailed description?
Anybody on the line, a detailed description of what a model of a systems engineer is and maybe some of the day to day or duties that person might have? So model based systems engineer all the way System Engineering is the formalize application of modeling to support system requirements, analysis, verification, validation, duties, beginning the conceptual design phase, continued
development of later life cycles, according to Cossy. Very long mouthful to say, uh, model basis. And engineers do two things they take. They take the user need and they translate that into something for the vendor or the OEM or whoever it is who is developing that system to to do so, you prescribe what it is you want
and then you verify it or you trace to you say, how can I show? How can I prove that that was actually done correctly and completely? And does that verify my state or validate my stakeholder need? So really, it's two things.
It's the ability to prescribe what you need and the ability to. Prove that you have gotten there and I think I think that maybe be a little bit of an acquisition specific definition on the OEM or the vendor side are probably look a bit different, depending on exactly how they're they're using model systems, engineering and acquisitions.
I don't think that's pretty accurate. Yeah, I think it's really important to to note that all of what Brett mentioned and said has to do with systems engineering, that the modeling aspects of it are the tool to help you do it better.
Yep. Anything else to add on that description, Casey or Lindsay? Yeah, I think that really hit home with the give me the professional coaches definition and then summing it up as well in his own terms, but in combination of.
Right. And they pretty much hit it right on the spot. In summary for myself, just straight out plain language, I like to kind of get back to the point that a model is just simply a shared representation of a system.
Right. So now all of us with model based systems engineering can now see the same system represented in the same location. And collectively, like Brett said, we're passing it off the binder's as a holistic picture, so. Yeah, right, not in the in the the difficult aspect of it is that we're the model piece of it is learning
a new language, being unable to apply that language as the tool with a specific software. And that's that's what you guys have been trained to learn. Yeah. And Lindsay is going through right now. So I think it's probably important right now to kind of maybe chat a little bit about what's the smell was and what about Cameo
and some of the software applications that are out there. So, yeah, that's exactly where I was going. So that's a great Segway. Can you tell me about this bill and a follow up question to that. Is there any language that's similar that could prepare somebody that wanted to transition to be a model basis in mutineer?
Is is is Python similar? Is any art, any of those other languages similar to systems that could help someone learn it faster? Go ahead, Lindsay. Yes, I can take this one. So actually, when Jeff approached me about model based systems engineering, he was trying to describe to me what it actually was.
He said, you're modeling something which what we talked about the beginning was I thought it was like a 3D thing. And they said it was like programing. I thought I was like typing in the command prompt. But it's actually not like that at all.
It's more like it's a language, but it's a graphic language. It's like a two dimensional graphic language. It's almost like when you're building these models, they're like they look like flowcharts, but they're specific rules on how you read them.
And so that's what that's where the language part comes in. I don't know if that helps because I've never heard about this before, but I had a lot of misconceptions about what it was before I started taking the class and.
Yeah, yeah, yeah, yeah. I agree with you, Lindsey, as well. I think there is generally a misconception of, you know, what is the model or an engineer or what model based systems engineering. I think in the big grand scheme of things, we have UML and systems to provide a standard among the system, the engineering community.
That way we all understand what someone is trying to convey within the model itself. I'm not that answers your question. Yeah, it definitely does. So I guess I was under the misconception also that it was a language similar to Python or C++ or something like that.
It sounds like it's a little bit different, but I assume that having that type of mindset, having a maybe a coding background or a coding mindset is not necessarily OK. There are a few things, too, I think I want to mention here is, you know, when I first met, right, we're getting into, you know, what each other
knows about certain engineering and model based systems engineering. You know, we talked about resources and the differences in our training. But one of the things that he mentioned up front or one of the questions that I asked was how did he get to the point where he knew all of the syntax and all of the five?
My new details within the system generating a model based system engineering. And the reality is you have to refer back to the documentation and I think coding Python, for example, you know, it's the same way you have to refer back to the original documentation and actually, you know, get your hands on what these things are actually actually
meaning. So, yeah. I think that's a very accurate statement. I think diving deep into spek is a good way to really get your hands dirty and figure out exactly what you need to be. How to how to notates are the best notation for a given concept or something like that, how you should do different diagrams and so
on. Yeah. Are there any musicians here? Um, so I don't know if there are, but I kind of equate it to like when you read a piece of music, like sheet music, like there's like all these specific rules that you have to follow to be able to interpret what you're seeing.
But it's like a visual. So it's almost like a visual code. Yeah. Except, you know, with this, you've also got like the parametric links between all your different models, right? Yeah, I think that's actually a pretty good equivalency representation of sheet music.
I would that's actually going on. I haven't thought of that before. Uh, cement was built off of, you know, your models developed in the 90s as a kind of a combination of a bunch of different modeling notations and modeling design.
So DFT out of zero and so on, those types of notations. And then some of the different fields use slightly different like sequence diagrams, activity diagrams and so on. Uh, there were a lot of different things are pulled together into the Unified Modeling Language or UML.
And then, um, I was later adopted, uh. In the early, I think want to say the early 2000s, but I might be off here as a superset of, um, also it includes all the UML concepts, then adds a couple of things like parametric requirements specific to.
Uh, specific to systems engineering. And then a couple other minor changes, which are not as important. So I think as far as similar invitations go, UML people with software and UML experience will have a lot easier time coming up to speed.
Uh, a lot of systems engineers will also have enough or, um. Don't have you, while Dawidoff can also be represented in as well some of the similar modeling or originating equivalent modeling notations that were. Using the creation of UML and so on, the system will also be not to get too nasty here, but will eventually split off
from UML in the next next version, version 2.0. Got me on your future. Yeah, cool. So we talked a lot about this, Amelle. What about. So I've heard Cameo a lot. Is that the software that you use or is that not OK?
I'm going to explain what that is. Maybe just a brief overview. So there's several different modeling tools. Cameo or Magic Draws On My Mind Made by no magic, recently acquired by the. So, uh, Navaira primarily uses that to cameo since it's a software package on top of Metatron, a couple of extensions and so on plugins.
There's also a couple of other ones like Rational Rapsody. Uh, and then there really there's a lot of them. I think there's like 30 something tools, but some of the primary ones are sparks. Yeah. Uh, rational Rapsody and.
Uh, this is one fondler by no magic, then there's a couple of other ones like Innosight that uses LML, which is similar to system life cycle modeling language. But like I said, there's quite a few different options here and primarily never uses assistance while the.
Got do magic. So how would somebody learn how to use that software is our training outside of so obviously if you get a job at Avión, you're going to be trained to use that software. But is there training that someone could take before getting hired as a model system engineer?
I think what helped me out really was the schooling in the very beginning. And I should also say that it wasn't wasn't very hands on in terms of the introduction. It's a cameo. We were actually given the option in the school, provided the academic version, our license for Cameo, but we had pretty much an instructor walk us
through the diagrams I wrote the part about for the activity diagrams, you know, internal block diagram and the list goes on and on. But from what I've seen, generally it helps out with just simply playing with the tool of getting familiarization.
But I think I would struggle to say that there are some general classes out there that would kind of help you out. For me, I've had a couple of books and resources to kind of dove into to help me out.
But the main thing I think is gaining practical experience, working with it. It's a lot like coding in the sense that you need to actually do it to get better at it. Yeah, I think this is actually a great time for Lindsay to step in and talk about the experience that she's having right now.
You're going through a boot camp of sorts, is that correct? Yeah, yeah. I'm doing, of course, that Geoff recommended to me through Avión. It's done through the it's taught by Leonie Delgado is who does the online lectures. And then Pat Mahad has been teaching us like in in classes like outside of that lecture.
And it's been pretty good so far, so good. Like if anyone is interested in learning, it's conceptually it's not it's not necessarily difficult to grasp. But as you go through the course, it's I kind of think of it as like when you're learning algebra, like all the concepts kind of like start piling on top of each other
and you need to know the previous concepts to understand the later ones. So you do need to thoroughly understand everything. But it's not too bad. Like, I don't have, like, a super strong programing background. I don't even have a strong systems education background.
I'm a mechanical engineer and I've been able to pick it up. All right. It's maybe you do like three hours of lecture during the week and then you've got like an hour of, like interactive in class with Pat and then reading your book and whatever other practice you're doing with the with the modeling software.
Yeah, cool, so it sounds like you're getting that practical experience that Casey was just talking about. So, yes, very cool. And like you said, and I think somebody said at some point, you're always going to have to refer back to that documentation.
I code in JavaScript, in HTML and all that doing front end stuff. And I'm on the JavaScript website more than I want to admit. But yeah. And I do want to jump back to and I guess we didn't really talk about how like the path to becoming a model based systems engineer, like what's the undergrad courses or
major that that a lot of systems engineer would take, followed by postgrad. What's the master courses? And I think you could probably talk about that and then also experience. So you may have experience already in the DOD. What what are some things and we did talk about this a little bit in the last episode, but what are
some of those areas where it would be easy to shift over to Barnabei Systems Engineering? That's a good question. And so it really depends on your avenue. And I think Tuni is a good reason. I think pure systems engineering is a good way.
And I think there's a lot of pure systems engineers in the undergraduate level, at any rate, aerospace, mechanical, sometimes on the hardware side, and they have to some sort of struggle to shift over to a more of a logical area or software mindset.
Software engineers also are pretty good at that on occasion. So I think I'd say those are some of the the primary paths. And I think some people might be a little bit curious as to why I a teeny test and evaluation, because you're on you're on the inside.
You're you're looking through how these things are tested. You're understanding that, hey, maybe those requirements weren't written very well when you're on the interpretation. Sorry. So you really get to understand the the troubles and the struggles that you're going to go through if you don't do a good job on the prescriptive side.
So I'd say those are some of the the couple paths in as far as both modeling it on a. Academic setting, there's a couple different universities that are teaching, like Georgia Tech is the major one, I think most I know most, but a lot of engineers come through Georgia Tech, Stevens Institute of Technology.
George Mason has a couple of classes, if there's a couple more as well, that'll do that in the master's courses. As far as undergraduate, I'm not sure if there are any there are some UML or other notation languages, graphical notation in play that's mostly master level.
Right. And I think what I understood from the last podcast is that if you're an undergrad and you're pursuing some sort of technical degree, probably engineering is the best the best route. And then, like you said at that master's level, deciding to maybe focus more on system that is nearing a model of a systems engineering.
Yeah. So I wanted to say, I think it's even if you don't necessarily have a background doing that, if you have, like, transferable skills, I think I find it to be very useful. So, like, you know, one of my previous you know, I've always been a mechanical engineer and a lot of my previous jobs, I had to
create all these complex CAD models of all these systems that I had to build up. And one of the problems you have with that is when you change one part, you've got to go back and change like a million other things.
And the great thing about models based system engineering is that you can actually keep track of all these interrelated things without without having to have that mental checklist that makes the process go. I think it would make the process go a lot faster, easier.
So even if you're not technically like a systems engineer person, you're studying that if you are doing a job that would require where it would actually make your job easier. I think that's also a good Segway into learning this sort of thing, because it would have helped me at my previous jobs even as just a mechanical right
. Or I think that's a great point. There's a lot of transferable skills. I think there's a lot of what some people consider soft skills that are important in a lot for engineering. If you're that interface between the user need and the model, you have to be able to understand you to have those interpersonal skills and the ability
to to really tease out that user need and prescribe that. So I think that's another transferable skill. And to your point, Lindsey, I think that's an excellent example where there's a lot of different things coming together. And if one thing changes, it's going to break a lot of other things.
And having an awareness of that will make you a lot better as a model of a systems engineer. Yes, so, Jeff, I think this is a great time to wrap it all back into Avión and talk about what we're doing to help people get into Adobe systems in America.
So go ahead and and take it from there. Yeah, well, I think it's a pretty exciting time for the company. About a year and a half ago, I started to get a demand signal from Navia here in Pax River as they were instituting and trying to institute the policies and the procedures and for model based systems engineering
into the into the systems engineering discipline here on base. And there just weren't any. Model based system juniors are very small cadre of them in the area, so two, to help that demand, two to go after that demand, the company decided to make an investment in a lab with a partner company here in the area called Precise
to acquire some Camiel licenses their floating licenses in a virtual environment. This all happened kind of during covid two. So we had to make it virtual and then develop a course to to kind of develop these the skill set.
So we latched on to the delegated classes. But that alone really doesn't give you the the full practical application enough to go into a program office to be able to do anything. So what we've done is we have hired out a company called Shantanu out of Huntsville, Alabama, and through it through an individual who's got an enormous
amount of experience and who teaches this to Proctor students through the delegates, as well as provide them with extra instruction and then to be able to also stick around after the course, after the certification to support them as they proceed into a specific program office or to do the actual work.
So Avon is really invested in this, and we want to help support not only our customers, but certainly the skill set in the area. And then there's applications outside of Navaira into other systems, commands within the Navy. Other services are starting to build it up.
And so we see see a real growth in this area. So this is the first class and Lindsays, one of the first students to go through. We have three others and we're looking to start again in the summertime with another group to go through.
So, so exciting times and looking looking forward to to growing in this particular area. Yeah. So it sounds like we as a company are on the forefront of something that is going to be big in the future, which is always nice to hear.
And we are taking the right steps to make sure that we are supporting our customers and we're doing it better, smarter and more efficiently. So with that, is there any last minute oh, by the way, any other points that you guys wanted to make on this episode?
I just said there's a couple of certifications you can get. There's the O.C. S and P certification, uh, are a couple of them. And then also, uh, support system you professional certifications. So I think those are a good, good way to prove your knowledge.
Yeah, cool, so, yeah, definitely, and is there an online resource I know Inkosi has a lot of information, but is there any other online resources that might list like some of those certifications or some of the courses around the country or anything like that in the object management group are probably your best starting points.
Gotcha. Cool. All right. Well, with that, I want to say thank you guys for joining me today. And on the next episode, we're actually talking about real world NBC applications. So we've defined what NBC is. We've looked at what it takes to get educated, start a path towards becoming an expert.
And then on the next episode, we're looking at the applications of NBC in the real world. So with that, I want to say again, thank you guys for joining me. And I'll see everybody next time. The Model Vision podcast is brought to you by Abian at 18.
We provide extraordinary support in the areas of model based systems engineering. We help our customers detect problems early using modeling with a purpose with Avians NBC network, we provide a collaborative ecosystem to access, define and implement a tailored NBFC approach for program success.
Avians model based systems engineers work with Tisdall using cameo software to replace the document centric nature of typical systems engineering. Our engineers expose vulnerabilities within your system before implementation, ensure speed to the fleet with a solution that brings clarity early, enhances the chief engineers capabilities, creates a holistic view allowing for better decision making and simplifies complexity.
Everything works together to bring certainty to your design. If you're interested in learning more about Avians capabilities within NBC, you can visit Avión dotcom capabilities.
