All right, welcome to Avians Official Systems Engineering podcast. I have Jim, Rete and John with me. This is the first time that John is on. So if you don't mind, John, can you give us a little introduction of who you are, a little bit about your background?
Sure. Hey, John Sliger, senior systems engineer at Avión, came up through the avionics world electrical engineering system and then transitioned and assist engineering and most recently working on the Navy's H1 replacement, which is the attack utility replacement aircraft.
Awesome. That was short and to the point. Like it. All right. So today we I don't think I said it yet. We are talking about real world embassy applications. So NBC model based systems engineering, of course, that's what this podcast is about, or a lot of the time that's what it's about.
Let's start with just the question of where is NBC being used right now and what are some of those applications that you're seeing in the different industries? Well, certainly you're seeing a lot in the Defense Department in with lots of complex systems, and that kind of lends itself to aircraft development.
Aircraft systems are kind of, by their nature, very complex. But that doesn't mean that's the only place is being used within DOD. And there are other places that are being used as well. And missile systems, probably systems that are very networked.
Maybe if it's beyond just a typical in unit systems that are networked with other systems, it kind of lends itself because of the complexity factor, lends itself to a model based system. The engineering approach Adobe systems during transformation for Navaira is working to transform systems engineering, to use model systems engineering.
And then I think NASA, JPL is on a lot of work as well with model business model engineering for space. Yeah, and just to remind folks, if they haven't listened to you guys go over the benefits of that transformation, so switching from traditional system Visioneering to model based system, what are some of those benefits from the two
that we've talked about it before? But just to review, I think I talked about it last time. So, John, you want to crack up? Sure, yeah. To so from the perspective of defense acquisition, there's a lot of paper based specification, paper based documents between all the disciplines, not only engineering, but logistics, program management, all the supporting players
there in a program office. But with with everything being paper based, everything becomes very siloed. And the connectivity or the dependencies between all that work is sometimes lost or definitely difficult to keep track of. So it's one of image that a model based environment does is it enables all those individual things to be created and documented, but
then also leaked to one another, to one another to show those dependencies so that as you go through and mature that design all the way to production and fielding, you can see when an opportunity for a trade space decision becomes available, you're able to see what all those factors are and how they play together.
And so that way nothing's lost in those technical decisions are more accurate and are able to be done at a a rate that's typically faster than the traditional paper based method. Yes. So it's hitting those points that we talk about all the time where it brings clarity earlier in the process.
It improves the decision making process and makes that just better overall. And it brings the certainty to the whole system design, which I think John hit on all of those points. So a plus to that information and to be completely transparent, obviously I'm not the expert and Rete gives me a great list of topics to talk about
every episode. So I appreciate that very much. Let's talk about in outside the DOD, some of those companies that we know are using model based systems engineering. So you have like Ford and John Deere. Do you know what applications they're using them for or using model based engineering for?
I think it's a combination of managing the change over time of a design. You can use it to represent both those in internal and external interfaces in a way that's much more traceable than traditional document based approach. And you also have a highly improved configuration management for those things.
So I think that's things a lot of people are using it for. You can also use it for simulation execution. I'm not sure if that's something they're exploring on the industry side, but that's done a lot on the the more design side, less on the acquisition side.
So I'd expect some of that's occurring. I'll add to maybe specific to John Deere. I think everyone pick your favorite country music songwriter. You've got tractors. But now with technology, GPS software, everything's becoming more complex, right? So you're no longer sitting there moving levers, pedals, you know, the steering wheel.
You have these vehicles controlling themselves based on, you know, so much from assisted driving to all the way to Thomas driving. So when you start bringing those technologies together, the solution space becomes so much more complex and there's so many intricacies.
You have to track that model based system model based engineering as a whole and then specifically model based systems engineering helps to control and mitigate some of the complexity that those solutions require. Yeah, and as you were talking, I was thinking, is there a hypothetical situation, so one of the benefits that we know of basis and engineering
provides is that it allows us to expose vulnerabilities or risks earlier in the process as our hypothetical situation. And maybe there's not but a hypothetical situation in the company of John Deere or the company of Ford that you could see model based systems engineering exposing some sort of risk or vulnerability earlier than maybe traditional systems engineering.
I mean, I think I think I think what it allows is it allows when you when you have these complex systems and you start doing things like John mentioned, talking about farming, talk about farming system tractors and GPS systems, and perhaps a sensor suite that talks about how crops are developing and when the optimum time to harvest
and that kind of stuff. Certainly when you start bringing in a lot of those big systems, there's potentially a lot of unknowns when you try to implement something like that. And the risks can be quite costly if you do something wrong in a big system like that.
So this affords the opportunity to to bring that, you know, we talked about it before, bring the knowledge sooner so you can make good decisions. So you have the knowledge to understand what the risks are. So so, yes, I think it has a tremendous benefit to exposing risks when we start talking about, like I mentioned before, the
big complex systems. Right. And I'll add to mention the simulation side of the modeling, looking at things like failure rates, reliability, something you may, I guess, traditionally or before you may not have gotten until you've done hours and hours of testing of something that's already produced in the digital environment.
You have the ability to do that sooner, more rapidly, through different analysis. You're able to expedite that process to find or at least identify potentials of where you may want to take a harder look and do more prototype development.
So just add the digital environment allows things to again be moved to left to be done sooner. And once the model is created, you can run it as many times for somewhat minimal cost. So it's just the ability to do all those digital simulations saves time and testing and prototyping and production.
So I'm going to throw another hypothetical at you as I'm reading through this list that sent over, I see one of them, one of the domains that he has listed as cybersecurity. And I think right now we're recording this the week of May.
What's the 13th, 2013? So we're recording May 13th. Right now, the country is kind of in a frenzy because of the the hack of the gas pipeline or whatever was happening. How is there a way that model based systems engineering could have maybe raised some red flags in that situation?
And again, maybe there's not. But I'm curious myself. I'll take an initial stab at this. Prevent is a hard thing to prove. I think you got so so with modeling and something we're trying to do on some of our projects with an avian is to to enable cybersecurity.
So it's less of its less reactive and more proactive. Right. So a lot of times you guess somewhat maybe traditional methods of cyber security. You don't know what you need to do until you have a design. So like, I don't know what controls to apply to something until I know it's wireless or wired.
Right. So, like, so you get so far in the design process that by the time you know what you need to do to make it secure, it's almost like you've got to go back and rework it in. So how do you do?
The more proactive side of that is something we're taking a hard look at. And the other thing, too, is once you have that model done through through simulation, you can actually I would say you would probably have most of your current threats identified.
And when a new threat or threat vector is identified, created, born, whatever you can, then I take your model and see how your system reacts to it. So so maybe maybe not prevent, but maybe more of a risk assessment to those new new up and coming threats as that as they become known.
I think there's a there's another perspective as well as if you have a better understanding of all of your interfaces and how they interact together across a distributed system, or are multiple systems interacting within a system of systems, you have a better idea of how those external interfaces and therefore threat vectors can occur earlier on.
So when you're designing your system, you can take a harder look at that and with that improved understanding, so it's a little bit harder to directly quantify. But being able to visualize that earlier on the design process to give you some some more design advice.
So my next question kind of I'm glad you guys hit on the simulation part, because that's what I was hoping you would hit on. But what I'm thinking is so we say Colonial Pipeline has this model already set up.
They now know because it's happened, it's real. They know what the hackers did. Can they throw the scenario of what the hackers did into their model to figure out a way to counteract what they did? Or is that not potentially OK?
I guess that depends on how how good your model was to start with. Yeah, but yeah, I think that's what I was trying to allude to with my statement. It's now that, you know, if you want if you're able to detect it, I think that is something that may be missing at least previous cyber security techniques, knowing
that you've been attacked. Right. Knowing that the threat has tried to enter and knowing whether you've prevented it or you've been your security's been defeated, I think that's a big step that would need to be in place. But then the other thing is, if you do know what the threat was and how it was entered, you can
then model that threat and then assumingly they made some kind of patch or fix. Right, to prevent it. Right. You could then test against it and probably extrapolate some some of the variables on that threat vector to ensure that other other threats, other vectors like that are also can also be prevented or mitigated.
Engineers love to replicate when stuff breaks. You know, they love to replicate why you're broke. Right. So any tool, anything they can use to to figure out how it broke is is a plus to the engineering community. So I'll add one more thing from a slightly different perspective.
One of the powers of multisystem is that you have all this connected in a network or a graph and and representations behind each thing. So you can understand if one thing falls down, what other things as that connect to you, what other things that potentially impact.
And then at a document based, centric world, you can't do that. So you may not necessarily know how it will fail or that might require additional analysis, but you can certainly reach out and touch all the things that if you pull one block down, what else will be impacted?
Great point. So that's another another like another power of NBC. And like I said, knowing exactly how that will fail depends on the quality of your model and the way you implement it and a couple other things. But it gives you that starting point regardless.
So let's talk about that was we talked a lot about other industries and we touched on Dodie's a little bit at the beginning. I know Jim brought it up already, but what where do we know that the DOD is using Madobe systems engineering or are there places that we are certain model based systems engineering would be advantageous
to a government customer without obviously going into too much specifics? Well, probably the number probably the first place it's going to be implemented are going to be in any kind of a new system. So they start really with the ground up at the at the ground floor, so to speak, and entering everything, having to market rather than
having to perhaps do an upgrade to a system. If you're going to do an upgrade to a system and finding out that you have to invest a lot of time modeling your existing system, I mean, that's that that can be done.
It's certainly better. But there's a there is a cost and time investment in that. And the programs will have to understand what the return of that investment is going to be. So certainly programs that are going to be starting at the ground floor.
Yeah, absolutely. I could see that. Do you to do any of you know if the F-35 program started with NBC or that was a traditional system like. I believe since this without being anything specific about it, I suspect that it's probably a paper based traditional document based.
Yeah, it is a fairly long program. So, you know, in terms of its age. So model based system engineering is relatively new 10, 15 years. But, you know, we're talking that's about the time when JSF first started. So.
Right. Right. You're even longer than that. So, yeah. So that's I think now is a good time just to dove in on the avian side of MPAC. What are we doing? What type of applications are we applying embassy to again, without being too specific?
But how are we using it as a company and providing that support to our customers? So I could see, uh, well, I know embassy is being used in a couple different places, there's there's a standard four pillars system out when my colleagues put it slightly differently, whether you have requirements, interfaces, behavior and structure and how they're, uh
, interfaces or requirements, as is everything traditionally. But we're working to move a little bit more into the structure and behavior, uh, and the interfaces side. So traditionally, you have a shell statement for everything. Uh, when you if you like, you don't have enough shell statements, you got a couple more.
You feel like you have too many shell statements. You might also add a couple more. Uh, we're working to get away from that a little bit. We're working to to define the behavior of your system. And based on that behavior, what do you need to enable your user need or your customer need?
Uh, from that, you can derive your your structure, your performance requirements, your interfaces and so on. So I think rib's requirements, interfaces, behavior and structure particularly heavy on the behavior side to start with. Uh, I think that's the the main modeling of the core of a model.
There's a lot of interacting external pieces, the kind of cut across that model. So you have things like cybersecurity, which you spend a lot of time talking about earlier. You have safety, you have, um, cost, you have human factors.
It's a lot of those are crosscutting disciplines or domains will be interacting heavily with large portions of your model. They're not necessarily driving the core of your model, but maybe they're, uh, adding some additional constraints, especially on the safety in the cyber side, whereas cost is kind of tracking your your progress and, uh, the anticipated cost of
different parts of your your development process. So I think those are some of the major areas. You've got things like swap size, weight and power. Uh, and there's more with each engineering discipline and some of them we use more and less simulation really depends on how you're using it on the acquisition or development side.
I think we've mentioned something earlier and we talked about system and transformation, the and the navia, one of our primary customers has been implementing a model based system engineering through a system engineering and transformation initiative. It's more than just deploying modelers into programs to do that.
Avium has done that. We have modelers and we have systems engineers that are deployed within programs and now they're doing that. But there's also another piece that is the the implementation of the discipline of model based system engineering and model based engineering.
We've been involved with that system engineering transformation team in a number of areas coming up with training, culture changes, methods and processes. Because there is it's not just about sticking a model or, if you will, into a program and doing something.
There's a it requires it requires a disciplined approach to systems engineering, utilizing models. It's not it's it's more because modeling requires more information and more work than a traditional document based system. But you get so much more from it.
So that's the that's the the things that Avians been involved in is that is being involved also in that system, the enduring transformation initiative that Navia has has been working on for the past couple of years. Yeah, I think that's a really good point, actually, is that your program office, your company may decide to say, hey, let's
go down this road of NBC. It's not just a light switch where you flip it on and now all of a sudden you're doing ABC. There's a process that has to be done and you have to make sure that you're doing it the correct way, which I'm comfortable saying Avians is really good at doing that type of
work. So. Right. It looked like you were about to say something to go ahead. Yeah, I think Jim was touching on that. I spoke earlier about how you the different parts of the requirements, interfaces and so on. But Jim was talking a bit about how you how you get there.
And so I think I want to expound on that a little bit. Yeah, there's there's process processes are extremely important. And it's not part of the power system. When you use it to model the processes, you you go beyond just the what you start to understand the how and the who, the why and the the with what
essentially. So back to the of zero days, you have a control, you have an input and output and a mechanism for your function. It's a simple activity modeling or process modeling is much the same, even if you're between a system or a process.
So on the process side, you're looking at who's doing it. You're looking at what they need to begin their work, what they need to complete their work, and what that transform is from the input to the output. So process is very important.
That gives you understanding of where you're starting from, where you're ending. And with that you can begin to build out your schema. Schema is another extremely important piece. And this is probably one that a lot of people make mistakes with the schemas, the representation of your sister model.
It's the elements in a specific order with specific relationships, with specific connections that show you this a skeleton or the generic representation of your system. And a lot of people will just start modeling. They'll just start throwing stuff together and expect it to be useful.
We've talked a lot about the traceability verification, the ability to to draw conclusions from your data. In order to do that, you have to have a structure. You have to have a schema that is consistent. You have to be able to know that I have a use case that's connected to this activity and from this activity is
connected to this exchange or this this PIN type. And you have to be consistent with that to draw those conclusions. So it's not enough to just throw all the information in a model. It has to be well formed.
Then there's things like style guides, validation, Swede's metric sweets and so on. There's all that supporting information that helps someone do it consistently. Consistency is so, so important. But you take anyone new, they come on the program. They're helping you out building this.
They have to people do it the same way you are to be able to draw those conclusions. And then there's things like configuration management. I'll turn it over to John, talk about configuration management, because that's great fun. But distributed models, project usages, configuration management allows you to do so much reuse and so much more honestly.
And I can I can talk to configuration management, but that's probably enough content for. Episode, so definitely I think they can figure in education management is a huge I mean, talk about the integration with then you're sitting steering baselines and the content itself that it's that's at least one, if not maybe multiple episodes in itself.
So I'll leave it there for the sake of time. I can't remember, but I think it might be an episode in the future. OK, we'll definitely wrap around to that again. But to just sum it up again, it modeling, throwing stuff in a model, it's not enough.
You need the systems engineering behind it. You need to understand the process to understand those inputs, those outputs, who's doing it, what it is they're doing, how they're going to do it, your your schema, your implementation as you'll build supporting profiles or stereotypes to help enable that.
And then the last piece I haven't touched on earlier, I think I've mentioned before those training when the ability to bring in all of your other engineers, you don't want that that closet where you stuff in your model, there's stuff in your systems.
Engineers close the door, you slide some papers under the door every once in a while. You're not going to get anything useful out of that. You want to you want to bring in all the engineers and you want them working in your model, set up to set it up in such a way that they can do that
is extremely important. Yeah, I think now would be a great time to just do a general avium plug and talk about art, we have been talking about it. But more specifically, what are exact capabilities? Are the document that I'm going to read this from.
I will put it on the Internet somewhere, link it in all the podcast episodes so that if you're listening or watching and are interested in contacting us or reading exactly what this says, you can do so on your own time.
But our capabilities as a company, we provide skilled modelers like Rete, like John, and at all levels of expertize we provide initial Systèmes. So we talked about that transformation from maybe traditional systems engineering to model based system engineering.
I assume that as this team helps you make that transition and transformation, we provide a functional environment with floating cameo licenses. So cameos the software. I believe Jeff actually brought this up in the last episode where we have what we're calling floating licenses, which means it's not tied to a program office.
It's not an additional cost. We already have these licenses and then the ability to produce modulars, like from the last episode. Lindsay, who's going through the training program right now and on the other side of that program, she will be a modeler.
So again, I'll link that document that I read that from. There's a lot more text on there that has some really great value. But I just wanted to plug it in for a quick minute. Are there any last minute thoughts that you guys have on this subject anymore?
Let me go ahead, Jeff. OK, just just one thing, because you mentioned something about aliens capabilities, and I just kind of wanted to I just kind of wanted to highlight that, you know, two people on this podcast read and John or or I think more than just modelers, I think they have a very deep understanding of the
system, the engineering process. What makes them also very unique is they have a deep understanding of the model based system engineering and can bring that expertize to programs that need to implement model based system engineering so they're able to understand how we develop complex weapons systems and the Department of Defense, how we need new systems, engineering for
complex systems and those kinds of things, and then how to find and how to recognize what kind of needs that the program would need for for additional maybe true modelers or system engineers and things like that. So, yeah, that's a great point.
And I really need to delete the word modeler from my vocabulary. But I was reading it off of a page I have on the screen. So bottom based systems engineer is the right term and what I should use in the future.
Any other last thoughts? Yeah, two quick things. I think another area or even excels is the ability to bring in all those other disciplines into model. This is an engineering. It's more than just your requirements and your interfaces.
It's it's all of those other things, like I mentioned earlier, safety and cost and cyber and so on, bringing all of those in, establishing approaches for them and enabling it for the the non systems engineers to run on model solving.
Essentially, everything I wanna talk about is just a couple of places where I think model based system engineering would be especially useful in the future. We haven't seen it as much so far, so I'd say any complex system.
How do you define a complex system? Well, if it's cost Abhay much more money than you expected it would in way more time than it's probably a good start. I think medical industry is probably a good example. Some of the more complex I.T. systems, autonomous cars would be another good area, ships like cruise ships and things like
that. So I think any of those large, complex systems where you're seeing some of those cost and schedule overruns would be a good start. I'm glad you said autonomous cars, because as you were saying that, I was thinking, oh, should we, like, give Elon Musk a call and see him move out to Texas and support Starbase or
whatever? Yeah, sure. Anything from you, John? Maybe. Maybe a different twist on one of the questions you asked me for, but you asked who are who we're working with? Yeah, I think we're very, very heavily involved in the DOD secretary, but we're also mentoring several graduate programs specifically, you know, at the moment, NPS and Georgia Tech.
Working, working either with some of those students or some of those classes for me, think from a thesis or capstone project mentoring to, you know, speaking to the class, telling them, just like we're doing here, the the real life, you know, so they learn systems during or model based system in the classroom.
But what does that translate to in real life? Right. When when the easiest comes in, you can make in an example go away and you have a real life project that has real money and real schedule. You have to execute Youtube and go last night working with some of the vendors, tool vendors who are actually creating these
tools. You know, you mentioned Cameo. Also working with a slate, trying to bring our lessons learned to them to one either from anything from bugs and possible solutions to them, but actually or new features, new capabilities, trying to enable those tools to better complete the systems engineering picture.
Yeah, I think those are all great points. I, I knew that we were doing mentorship. Stuff was out of my mind. So I'm glad that you brought that up. And I think showing that, like you said, showing that we are doing those mentorship programs and providing support to help people that are interested in malaby systems engineering get
into this field is very important as well. So. Glad you hit that point, if that's it. I think we're good for this episode. So on the next episode, we're talking about digital engineering. I don't even know where to start with this one.
So I'll be very interested to hear what you guys have to say. I don't know exactly who's on that episode, but I'm very interested to get into that discussion and learn about digital engineering and kind of what falls under that category.
So that will be on the next episode. Until then, I'll see everybody next time. Jim, Brett, John, thank you for joining me. And that is it. Thanks for joining me. Thanks for having us here. 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.
