Welcome to Avian's official Systems engineering podcast. Today I have Rhett, Rich, Jim and Keith with me to talk about model based systems engineering. So on the first one on the 1st podcast episode we talked about systems engineering. Now we're going a little bit deeper talking about model based systems engineering which will get into a little bit, but in my mind I imagine that's a little bit more.
Of a specific topic than what we talked about on that first episode. So before we jump too much further into it, Rhett and Jim. If you want to go ahead and just introduce yourselves really quickly, that would be great.
Whoever would like to go, I'm Jim Carroll.
I'm Jim Carroll. I am senior systems engineer here at AVN. I support program at Navara, a new Marine core helicopter program that's just kind of getting started and their program is fully immersed in model based systems engineering. Fully implementing model based systems engineering. Prior to this, I've have 35 years with Navair in various roles, systems engineering and testing evaluation so.
My name is Rod Cimarron, First Analysis, model basis in general, working at avian and supporting the Navy. Graduated about four years ago with a bachelors degree in systems engineering and Operations Research and just got to get my Masters degree in Systems engineering. Since that time I've been working into sports set at Navair, so systems engineering transformation doing model based sneering tool studies, acquisition system reference model development and I've also been.
In support of PMA 276 in the H1 upgrade and as lead architect of Aura Attack Utility replacement aircraft.
Awesome, where are you getting your masters from? Rep George Mason University. Awesome cool alright? So let's jump into this topic and let's start with that broad question. What is MBS? See I guess the other part of that is how is it different and actually will say that for the second let's start with just what is NBC?
Yes, so I'll take a first shot at it for you in a more general sense, and I'm hoping that the rest of the team here can fill in behind me because I'm sure I'll just keep details. But I came to came to this because I see model based systems engineering as a dramatic change. The practice of systems engineering as a as an engineering discipline. Traditionally, systems engineering has been accomplished.
With the development of paper documents and these documents would typically define requirements for the system that you're trying to develop, and we would build the evolution of the requirements and monitor the progress through that with paper and everything would happen in the documentation we would get working with our.
Original equipment manufacturer. The prime contractor developed the requirements that.
And as requirements evolve, those requirements would be translated into a an actual weapons system, but our progress through that process is tracked on documents.
Model based systems engineering endeavors to replace the paper documents with a system model that describes what you're doing.
The trouble with all the paper documents is that on a complex weapon system gets very complicated for fans and it's very difficult to keep up.
As a systems engineer, I spend as much time running around trying to keep track of the paper and do I have the right versions and is everybody working from the correct song sheet if you will.
We're where we are today.
So the idea of model based systems engineering is to develop a model.
Based on the requirements set that you had an A model of the of the system that you're trying to develop, and by doing that you have a centralized model that everybody can work on collaboratively. So everybody on the team has a single place of reference. If you will to go and get information about what you're doing, and it's always the up-to-date set of information so it becomes a collaborative tool for everybody to work from at the same time and you.
Make great progress and it automatically does things like connect, what your requirements are to the verification validation requirements that you have and so on. So to me it's it's. It's the advancement of specific.
Engineering tools for systems engineers that we haven't had in the past, physics based engineers and another competency engineers have had tools for long time Arrow. Guys have had tools to predict aero performance.
Structures guys have had finite element analysis that's done with computers to model structure, but we never had a way to.
Model the system.
Performance in the system requirements for and NBSP brings that to the table.
Anyone else wanna jump in?
Just just to kind of add on to what Rick said when we talk about documents. Documents are really a representation of information and there are only as good as when they are produced. But the information is constantly changing as as assistant injuring processes going.
So what a model does is allow people to work with the information and not the representation of the information through a set of documents.
So that's one of the powerful aspects of model based system engineering.
So one question that pops in my mind. It sounds like this, and maybe it's abundantly clear, but I just want to be clear.
Is all this information now being digitized? So before it sounds like it was a physical representation, now it's a digital representation? Is that accurate or no?
Will it rain in reference to that in the past, all of our documents that we've had in the past world digitized? I mean, we took it off of a integrated server, right? But there was no linkage of all those documents as related to time or abstraction of the level of maturity of the design, right? So what we've done is we've taken the this all these documents and distill them down into.
You know four areas of you know structure, behavior, requirements and parametrics that allows us to have used principles of of concordance that allows us to look at that information at different views based upon whether or not that view happens to be from a structures end of it or an operational end of it of that design. So you know the level of abstraction is an important piece of the model based approach, which I'm sure red is going to kind of give us a little bit more technical detail on how that actually works.
I would I would. I would add that that.
It's it's more than just digitising a paper document. We have performance specifications today that describe our requirements set. It's not just a matter of making that an electronic document that I can read on computer. What it does is it takes US requirements, puts it into a relational database and you get the interaction of the other requirements with each other and along those four pillars that Keith refer to and and get a better understanding of how not only do they.
Uh.
Work together, but how they relate to each other and how they can change and what the performance of your system will be as you manipulate the requirements.
Yeah, that definitely makes sense.
Any last answers for that question before we move on?
I think I'd like to expand a little bit on Aldrich. Just suggest now about the relational database is a very important piece. This instead of sort of paper document where you're trying to describe the system in some way. You are making abstraction or representation of that system and model assist engineering. You say this block is my system and then you can apply functions to requirements to the behaviors, state machines, etc. So different views of that system.
So instead of an overarching description that it's in a document, in refers to parts of you representing that system and all the things interact with it. And just like Rich said, as it's in it.
Relational databases are not limited to referencing other things of you like words and so on. You draw a relation to that, and because of that relation you can draw conclusions or or analysis upon that relationship or sets of relationships, right? So it really expands on the power and.
And available not only in the the configuration management piece which has been mentioned before, but in the ability to draw conclusions analysis on the data.
So it sounds like this, again, correct me if I'm wrong, but it sounds like this might make.
Some of the testing a little bit easier is was there. Was there a?
Testing capability so it sounds like you can set up like a scenario and figure and then analyze it and figure out if something works or what work is that.
What I'm understanding an was there that capability if I'm right, was there that capability before model based systems engineering?
Whether it was, but it was, it was kind of hard to abstract it from the information when we work on our requirements documents. Not only do we provide a requirement, but how would you test or validate that required. And as you go along through your design that design.
Starts to decompose ways of I'm going to. I'm going to validate that design and then verify that that design met the operational requirement of the of the user. I think what we want to make sure that everybody understands is that model based system engineering isn't new systems engineering. It's the same system engineering that we've been doing for decades. Is that we're using a new tool that allows us to do that. In the past we use tools like Dodaf, which came up with viewpoints associated with operational or systems or.
Or technical views that describe the requirements and the design right? So those same views you know whether or not it's an Obi Wan or a use case diagram flows right into model based systems engineering as well. So we teach systems engineering, boot camp through avian for the part of the Navy.
We add the structure of Embassy isn't as a tool that encompasses all the systems engineering processes, technical and management processes, that's it makes it more efficient.
Gotcha.
And I would add, just as you know the you you wanted to know about the relationship of testing in the document based approach we did have now OK. And what you would the attempt was always to identify the requirement, develop a thread of the requirement development to get to and how you're going to verify that you're meeting the requirements through test and we used to keep track of it in a ver. Those of you been doing traditional systems engineering. You're familiar with the tool called Doors.
Which is nothing more than a big spreadsheet that just related a set of requirements to set of verification testing and what MBS he brings to the table now is that you're able to develop that test planning and the test relationships much sooner, and there's a another concept called capability based testing which is intended to identify what is it that I want my weapon system to do later and develop tests.
Based on the system model, now that will demonstrate that I'm either achieving those requirements or not from a capability base, rather than just verifying something meet suspect.
So yeah, it's a lot different now. It's a lot more involved.
Yeah, so go ahead.
And I'd like to expand on that a little bit with Rich said with like a capability. For example, you can tie tie side capability to all the functions your systems perform for that capability. Then you can pull in the requirements and their associated verification methods. And you can do all this semi semi autonomously. Then you can assign those to say, testing vignettes, which isn't like that and then auto generate like test run matrices and other things like that. All of it based on the same data.
That's an important piece. Here is instead of it being tide in different artifacts. So you have one in your CD and one in your system's back, and so on and so forth. It's all that same data in the same place you're creating queries against that data and using that to generate your test on matrices and so on, so on. And these are in the context of those things that are important to that task is not just to look at one singular requirement or set of requirements together, it's a look at those requirements together with their interface. Is the scenario in which they used the conditions in which they are used.
The functions that are attached to Aurora signed with an in the context that capability that they are in development with. It also lets you do some interesting things like begin to identify the testing equipment you're going to need the testing process earlier on and where you'll use that equipment in those test pieces, so.
It sounds like we're getting more information earlier. We're getting better information and like you just said it, be it clarifies that the type of resources that you'll need once you figure out what that solution is.
Awesome, so let's I think you answered my second question, which is how is NBC different from traditional systems engineering? So let's move onto. In the first episode, Rich, You gave a great example of how system engine engineering could be applied to like building a house. Is there another example that can?
Kind of give a picture of what NBC is in that sense.
Sure you can.
We
one of the examples that we use when we're teaching what NBC is going to do for you. We use the example of an automobile and we talk about establishing a set of requirements and we could walk through the four pillars that Keith mentioned earlier, and you could look at if I want a Car Talk about a simple requirement. I want a car to stop from 60 to 0 without skidding.
And say 20 seconds or at 10 seconds or whatever it is and that would go into the requirements pillar of the model.
You talk about the physical description of the order, the structure of the model by looking at all the physical components that are involved in making the car. Do that, wheels, tires, brakes, anti skid control. All of those elements that even down to the operator's foot on a pedal somewhere to make the car stop and that would be the.
Behavioral elements this structural elements. Then you would talk about the behavior and how those things interact. When you put your foot on the pedal to stop the car and how the anti skid system will come into play to keep it from going into it. And then you would go into the parametric discussion, which is where the model will do the analysis to say how fast it will the car stop given the structural design that you've come up with so far and it's performance. So yeah you can do it, do the car or you do with an airplane or whatever.
Kind of system you want. You can. I don't know how you could do it on a house as well, but the point is that you generally describe whatever it is that you're trying to do in terms of its requirements and structured behavior and how it's going to play together.
I would also add Ian, I love what you said about how this brings a lot of information into play earlier because what what the real primary benefit of then PSC is is learning and understanding your weapons system earlier and identifying risks earlier and all the big savings that come from MBS E are the result of bringing risk understanding to the program earlier.
So the big that the one of the.
One of the things that people say is we move knowledge to the left as we develop a system were moving the knowledge of that system further left when it is better utilized in decision making for the future of the weapons system to make sure it meets the user's requirements.
It has all of the logistics and product support aspects built into it as well, so you're moving that knowledge more left.
So, so one of the the other values associated with model based systems engineering is one, is is reuse right? So you gotta area of polymorphism as we used to talk about it in the software development world. Is that when you build an object you can reuse it right? So using the analogy that rich used on the car. So if the brake system was common on several different cars you could reuse that part of that model.
Alright, and you just change the requirements going into that model may change some of the behavior associated with that model, so that's the area of concordance and polymorphism. Also, the value associated with model based system engineering is you can work collaboratively on design with different parts of the system at a moment's notice, so we go to an allocated baseline where I'm allocated size, weight, power.
In an aircraft.
It's it's section goes off and does her little thing, and then they come back says, you know I didn't have enough space that was allocated to me, so I'm going to go and actually start pushing the design envelope down to a more highly technical or technical risk area to get the design down. Where if I would have been able to collaborate with a propulsion or for aircraft structures, I may have gotten that value back. A size, weight, and power so I wouldn't have to go down that road of of technical in maturity.
That way it allows me to get the design through a lot quicker so that speeds up the process, because now we're actually understanding our trade space on a moments notice instead of every six months to a year. We all get together and talk.
About it
I'd like to add some of the power of the NBC tools. They allow you to to do a lot of execution or parametric execution directly in the model, or tying it to an external tool suite. So if you have it in the swap example, you can compare.
Your allocation to how much you're using and then surrender that that remainder back in near real time, either directly in that model or tying in a different tool and using that tool too.
To link that data, and in addition to that, you can compare those to your requirements and semi real time as well.
Yeah, so you know talking about what Brett just brought up is. It allows you to use the model as a decision-making tool instead of using biases that come out of who gets your desk first, right?
Yeah, so it sounds like there's a lot of automation that happens. That probably takes a lot of time out of. I think you have all said this. That takes a lot of time out of what was the process before so.
You also hit on the fact that it brings a certainty to the designs that are happening and better decision making.
How?
Where do I want to go next? How? Let's let's look into the future. Now I guess. How do you CNBC evolving growing? Where is it going in the future?
That area where I see where its value would be is if I was to, you know, let's say the helicopter replacement program. If we wish to model the functions and behavior of the current age 1 Y&Z right. Then when you replace that aircraft because you have more capability than the current aircraft has available to it, you can use those behaviors or that operational functional functionality and roll that into the baseline requirements for the.
Next aircraft.
Instead of redoing it all from scratch, right right, so I think there's value in that also feeding back into the test once you get into test and you actually validate the system and the issues associated with that. Feed that back into the requirements set once again.
To now provide information on how to better design later on and then thirdly I see we're now we actually have models of the entire system and as the system gets upgraded either be an EPS or pre programmed improvements. Those capabilities are actually rolled into the model which feeds into the jasons process which right now the jasons process stops at the CPD.
Where they only have a small subset of the total functionality of this is.
Great at the Jay Rock.
There's a. There's another thing that I know Keith is very familiar with. This is the system of systems aspects of of. Once you get models, a digital representation if you will, of the behaviors and functions and requirements of a system, you can start linking.
A system with another system as represented by that model, and you can start doing system of systems analysis systems, systems, work decision-making, and all that kind of stuff.
Absolutely. So you wanted to know where it's going and where it where it's been. I think a lot of things have converged to makes model based systems engineering.
Feasable in the 1st place and that the power of computing has has grown the development of a language to do model based systems engineering in that the common one is a thing called sysem L which is a common language that people can define requirements and all these elements of the model that we've been talking about in a way that's commonly understood and brought together. You're also starting to see many companies starting to use it and.
And try to implement it so a lot of the OEM's are doing it.
The Navy is is taking the lead, especially in aviation, to develop model based systems engineering as a as a path to the future. I've got to tell you that I came to avian because avian is directly involved in and supporting the Navy, developing the processes and means of implementing MB SE.
Anne Anne, so where it's going from here is that everybody's trying to figure out how to put it together.
And and we have the opportunity at 80 and to help the Navy do this. All of us are involved in supporting specific programs to do it one at a time or also involved in supporting the system engineering team at Navair. Their sole purpose is the transition from document based systems engineering. 2 model based systems engineering.
Navair is trying to develop an entire digital environment to not only address the system model and systems engineering. That's the focus of our conversation today, but to bring in other elements, like sustainment through PLM, and could add attaching the PLM.
Inputs coming out of the system model instead of just doing it later, which is typically how sustainment is developed in programs as an afterthought, we're looking at the integration of the system model outputs into what the capability based test.
Tools are are doing to predict the performance of aircraft based on the model output, so there's a lot of exciting things coming together now and we're at the apex of bringing that stuff together, and it's one of the areas where avian is is developing his strengths in terms of having a a model. Excuse me at lab that's been put together to do some work in to start looking at integration of these tools we are training.
Modelers which I am not my model modeling systems engineer rat is a modeler. He knows how.
But but the the development of an integrated team of systems engineers, with modelers 'cause the systems engineer stop the vision of the architecture of the weapon system they're trying to develop, and the modelers bring all that together. You need an integrated team of folks to do that, along with all the competency engineers and other specialty engineers and testers and and logisticians to bring a program together. So the future is coming like a freight train. It's moving very fast.
Now there is really working hard to try to get everybody on a similar path so that it's not just all hasn't and we. We have the opportunity here to help help them do that and the future I think is bright. The systems engineering is is going undergoing a renaissance as far as I'm concerned with all this, and we're going to be able to do much more in the future.
I get excited up, sorry.
I think to add onto it, Rich said it's pulling some of those things together like test like.
Similar disciplines, but that integration together is the important part. It's not enough to just model, you also have to architect. Architecting is pulling together all these disparate disciplines and making them work together in one system specification, one centralized location where the OEM, the government, and all those specialty your brother competences can work together. So not only are we working to pull those in and enable that for everyone.
But we're working too.
To get the people trained and knowledgeable in that beyond their typical day to day methodology. So whereas you normally do in Excel and architecture, Modeler will enable that for you in the model and help you get there so we don't. It's not enough to just take a model and then have the modelers working in that model.
You need to bring everyone together and have that single source of truth. If you're bringing in Excel sheets and you're bringing in Word docs and using those to generate your model, you don't have a single source of truth you have. You have layers of confusion is the right word, but layers of interpretation issues between the primary source and the model over the representation of your system. So it's the job of architects and modelers to to work with those knees. Work with those systems, engineers.
Model basis engineers to to bring in that data to bring in that user community to bring in those specially domains. I think that's where we're going next is.
Is pulling all those together an enabling each individual in their from their own competence, hear their own capability to work directly within that model?
Yeah, and I'm going to say something. Hope I don't offend anybody 'cause I really expect all the work that you guys do, but it's it's. It seems like it's this merriment of old school and new school, where systems engineering is that old school and overarching category and model based systems nearing is that new on what I'm calling old school systems engineering, so really cool to see. Really cool to see that Adrian is has this team in his building. This team of both folks who have been like Jim mentioned when he introduced himself, been in the business for 35 years and then RET who is a?
Modeler and learning all these new techniques.
Let's let's wrap it up. We're almost to 30 minutes. Any last minute kind of alien plug. So we talked about.
We talked about the SC Boot camp a little bit that we that we up stand up. We talked a little bit about some other capabilities, what what other capabilities do you guys want to hit on that we offer from Adrian?
I'd like to focus on consistency. A lot of people can create a model. How useful is that model is a very, very separate question. If you put a bunch of stuff together and you throw it in a containment tree, you now have a bunch of stuff at a containment tree, and less it is aligned to a schema unless it is set up in a very methodical and consistent way it is unusable, so that's that's a lot of models apart from each other's is. Is that data organized in a way that you can query it that you can chain it that you can integrate it with other things?
And those things are usable for the people that that.
Needs to bring in that data. Those external sneeze, so I think that's like avian does very differently from a lot of companies, and it's hard work. You have to create that format to work with those individuals and bring it in, and the format will look different.
Sometimes the process bit different. That's another point where we excel. It's not just creating that specific format, and that specific consistency in that schema. It's creating the process and the validation rules and guidance and style guides and so on to enable that for everyone. So it's you have people who are modelers, you have an architect who designs this, but they they by themselves are not enough. You need to bring in all of the sneeze, the subject matter experts from all of their areas.
To enable to fill this in a usable and complete comprehensive way. That's where I think the power of modeling is enabled, and I think even does that well.
I think more.
Than anything we get out of, you know, from avian is you know, like like myself and Jim have been around and also rich been around systems engineering for 30 plus years, right? So we have all this stage of knowledge, but we have very, you know we have a breadth of knowledge but not a depth and model based systems engineering. So we rely on folks like Rep within the company to help balance all that out between our Breath of knowledge associated with systems engineering.
Pulling in that depth by using Rhett and some of the other folks at Avian that actually understand at the detail level with NBC is and how to invoke it so we can provide that value to our customers at this age level and also at the depth level associated with model based systems.
I think one of the things that kind of ties a little bit about what she said.
Rich has been saying is, I think we're helping out Avians helping out a lot in the defining the art of the possible.
He mentioned the. You know we have a lot of experience with systems engineering, so we know what kind of information is required, what kind of decisions are being made, what kind of issues that are being faced with systems engineers and we have people like Rep that bring the power of model based systems engineering and some other people within avian and to sort of bring those two together. How can we model something to help potential issues or help potential decision making that needs to be done?
When a program as a program develops.
So we were spending some time, I believe helping out that in defining that art of the possible.
Yeah, and and and Brett mentioned the importance of integration of capabilities and one of the things that we're really paying close attention to is the customer has long struggled with integrating a team of engineering and testers together and it Jim's background is frankly, in a lot more intestine and systems engineering and.
What we're trying to do here is help Navair Bridge that gap when they talk about capability based tests. They're talking about bringing the test discussion.
Way forward into the development design process and ensure that we demonstrate capabilities earlier an reduce risk in program. So again, it's all about bringing knowledge to the left and and better understanding we're going and we get that and we're trying to build those bridges where they didn't traditionally exist. Similarly, with the sustainment sighed. Anne, what PLM programs have tried to do in the past?
Awesome alright, so I think we are good to wrap it up here. Thank you guys for joining me today on the next episode. We're talking about what it takes to be a modeler. So we gave this overview of what NBC is in. The next episode. Will dive deep into the probably. I'm imagining the education. It takes an probably some of the languages need to learn and things like that, so thank you guys again for joining me and I will see everybody next time. Thank you. The Model Vision podcast is brought to you by avian at avian.
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 NBC approach for program success. Adians model based systems engineers work with this mill 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 visitavien.com/capabilities.
