Welcome to the Model Vision podcast. AVIAN's official Systems engineering podcast. Today we are jumping in with episode one of this new podcast and talking about Systems Engineering 101. In this episode we talk about what systems engineering is, how is defined, how we're using it in the workplace, and how we're using it to support our customers. Throughout the Department of Defense, I don't want to go into too much more detail because we do that at the beginning of the episode. So without further ado, I hope you enjoy this.
New podcast now. See you on the other side.
Welcome to Avian's official systems engineering podcasts. Today I have rich, Keith and Casey with me. Let's kick off with some just backgrounds. In general introductions of who you guys are rich. Do you want to give a quick overview of who you are, what you do for?
The company sure, so my name is rich gilt and I retired from working for the Navy after 39 years.
The bulk of my time with the Navy was working in systems engineering for major programs such as the F18 ENF development. I was the lead engineer and a little one team lead for that. I worked a systems engineering for the 8:12 an for the E2D as well. From there I went to direct air vehicle engineering at Navair and then finally my last job was is that?
Guys in Deputy Assistant Secretary Navy for aviation up in the Pentagon. After retirement I went to work at Sikorsky where I was definitely program manager for the C53K and came to avian looking for the opportunity to support Navair in its further development of systems engineering, especially with its future focus towards model based systems engineering.
Awesome, Keith.
I too have retired from the.
Naviair after 39 years. Twenty of those years was in the assistant engineering discipline.
I'm mostly doing new start programs and concept development programs for the Navy, including working at a three year stint up at DARPA.
Uh, we're going to mission level systems engineering or capacity level engineering and then retired came to avian primarily to do training to teach the a lot of the new engineers on what systems engineering is and how they're going to navigate the process or systems engineering for Navara, the Navy, and DoD.
Awesome and then finally Casey.
Yeah, so my I guess you could say my journey started pretty much in the Marine core so I spent some time there as a UAV operator as I transitioned out I got into simulation and training and actually contributed towards building simulation devices.
Along with that also fulfill the role of project manager and I would say that.
Actually led me to systems engineering is actually being more involved with the engineering aspect of it and project management, or at least being more interested in it. And with that I decided to get my degree finish up my masters degree from Cornell University and that's actually what land me save you get serious about something to do.
Cool, so welcome. This is the first episode so any rough spots that we may have will just blame it on that.
The conversation today is going to focus around systems engineering specifically, not specifically generally and kind of give an overview of what that even means. So let's just start with that question in a very basic form. Can you guys explain what systems engineering is?
Well, the function of system engineering is a guide. The engineering of complex systems. That's where it was born from, right? So it became something more documented back in World War Two when we started building complex systems to support.
The war effort.
But there's been some documentation that talks about system engineering going all the way back to building the pyramids in Egypt.
Wow, that's that's interesting. One thing that I read is that Bell Telephone was actually one of the first companies to use systems engineering.
Any other descriptions or anything you want to add to Keith description Casey are rich.
Yeah, just in general I think in plain terms, systems engineering is the realization of a concept to an actual system and no different than Keith is saying the origin of system engineering was really just to manage complexity. And as time evolves, system engineering is is also involved with it.
I think that the the only thing I would add to that when someone asked me with systems engineering really is I think of it as the translation of ideas or requirements to a specific design concept and finally a product at the end of the day that will meet the original idea and design requirements so it's transition of requirements into product development and into a product that needed.
Gotcha, alright, so let's let's talk about now. Since we have this basic definition of what systems engineering is, how are we using systems engineering now? And we generally not just Asian, but generally, how are we using it for work with the DoD? And then if you guys have any examples outside the DoD, that would be awesome too.
Well, I guess that you know one of one quote that I heard a Harvard professor described the DoD acquisition and system engineering is the most complex process in the world.
Mainly because there there's a dichotomy between full lifecycle systems engineering, an acquisition engineering as DoD looks at.
So we use this supplier acquire relationship as it relates to.
In Kosior international standards as it relates to systems engineering, so we look at defining the requirements, tracking the requirements, and making sure that those requirements are met and the design and implementation on the back end.
Right?
Any other examples of how we're using?
Systems engineering.
Or how anybody is using system engineering? Is there any industry leaders? Maybe that are using it that you know?
I think from past experience, just in general talking about systems engineering.
Just to kind of winding back and to build off of what Rich and Keith were saying. The process itself is multi tiered innocence. It is complex, but one example that I always kind of fault back to to provide proof that system engineering is valuable is really a customer Infinity process and essentially what this is is something like an RP comes out. We're able to analyze that document, analyze requirements and get down to a point where we can understand what the customer is truly requesting for what they're truly asking for.
From that point forward, essentially almost have a CHEAT SHEET. We know in our own terms what they are asking for. We've defined those. We can then take that validated it with our customer, and then in return. Once we're building our system, we know that it has to do these specific things and has to perform at this specific level. So this another example of what system engineering is and what it can actually offer.
But at the same time, talking with the customer and making sure that we understand his needs, we also have to provide some.
Quantitative input back to the customer as far as technical maturity capability and that type of thing. So we actually totally understand what his needs are and then with the end of processes. Henry Ford once stated that if I just listen to the customer, I would have given them a faster horse.
Right, so so it's a back and a fourth type of relationship between these systems engineer and the customer or stakeholder to make sure that we totally understand the context associated with the requirement and then build a requirement that only meets the minimum criteria to get that requirement to the warfighter.
Gotcha so.
I think it's interesting what you said. Casey basics. The process of systems engineering start even before we maybe are awarded the work that we're going after. We want to prove to the customer that we have a full understanding of what they are asking of. Asking of us and then basically move through that process. And you guys can correct me if I'm wrong, but is that what that means? So we're applying systems engineering techniques or tactics too.
In RFP and then we have a clear understanding when we get into the work that this is the process we're going to go through is that kind of what you said.
I would say what we're going back and forth with. It's just a different life cycles of A of a project and I think what Keith and what the team is extremely familiar with. This defense acquisition systems. But there's also generic lifecycle models as well, and so within a generic lifecycle model you have what's called the conceptual phase. Typically, in RP comes out with that type of constructor is usually limited communication flowing between yourself and the customer.
But utilizing systems engineering tools or able to get down to the root of the problem, and like I was saying earlier, provides somewhat of a CHEAT SHEET for the engineering team to.
Build a product. Yeah, cool.
To our original discussion, you know this is all about defining needs.
Defining the performance requirements to meet those needs and then translating those into a physical weapon system or or end product as we're trying to develop this is a process that's done frankly across commercial and in DoD industry alight. The application is a little bit different within the government just cause, but in general systems engineering is applied in just about everything we do. It could be as simple as when you're just like when most people go to buy a house.
First thing to figure out is well, how many people are going to live in the house? How many bedrooms do we need that you want? We want shelter. We want to stay warm. It won't stay cool.
What entertain ourselves want to have enough places to go to the bathroom so everything is covered as a set of needs and requirements? And then you translate that into an end product. And oh, by the way, can I afford it, which may get you to go into an iteration of understanding of your needs and requirements to get to something that meets everything that you want to come.
Yeah, that actually.
Helped meal understand a lot and leads into my next question, so I'm going to ask two very different questions. Let's let's think before World War Two before. Maybe we even categorize it as systems engineering rich. You just gave a great example of the house buying process, but are there any other examples that could?
Help people understand what systems engineering is.
At the very basic level, so maybe it has to do with forward like you were talking about Keith. Wear something with their assembly lines or something like that.
Well, I mean you see you know understanding the concept of the requirement, but as it relates to DoD systems engineering, you know at the government level but not only we helping define the requirements you know for. Like Rich mentioned, the House, you know the size of the house, how many bedrooms the functional flow of the house, you know how it would be used.
Also, the building inspectors all along the way to make sure that we have a foundation that works. We understand you know how the framing was done and the electrical in the high vac and so on, so that not only we get the end product that meets the customers needs, but we also understand where we can. Those interfaces that we can actually grow the House from.
In future future needs. So yeah, you know what? That said, system engineering is not this building the House, but it's also engineering change proposals. You know it could be upgrades to existing system, pre programmed improvements.
Yeah, so we understand that and we use new tools like now which was talking about earlier about model based systems. Engineering is a tool that gives us more insight on what those, the context and those interfaces are.
But I can just to build on what he said in terms of ensuring that that you know being the building inspector full for the House. But we're really talking about here is verification validation testing to ensure that the system meets requirements. So we talk about verification. Want to know? Does it work as it's intended to work and we talk about validation? Were asking the question, is it doing the thing we intended it to do? Did we build the right thing in the first place?
So.
The whole evolution of defining needs and requirements through the design process through validation verification and to release of an article that works and then ultimately to the sustainment of that article in the fleet with maintenance and supply.
Gotcha, so this is actually super helpful for me, 'cause now I'm understanding it more.
Now I'm going to lay it out in my terms and see if it aligns with what you guys are saying. So basically we're creating this plan from start to finish. Laying this plan out to our customers and making sure that we're sticking to this plan. Improving this plan along the way, and that it's it's consistent improvement consistent.
Reaching of those milestones that we set an and making sure we get to that endpoint in a.
Fast and maybe eficient manner.
Along the way we lay out the what are the risks associated with the current design or the current implementation funding stream technology, so will lay out those risks and will build mitigation plans associated with those risks that you know. So risk management is a management tool. Risk analysis is a technical term or hard hard skill associated with systems engineering. So along the way will provide those insights and how well we're doing.
To look at risk and also opportunity.
As it relates to the ongoing program, 'cause you know, there's always unknown unknowns, right? So we you know, we talk about, they think out of the box. Well, we haven't even defined the box yet, so that's kind of a hard process for us to go through.
Yeah, definitely alright. So let's let's shift gears a little bit and talk about the future of systems engineering. What does that look like to you guys?
So right now, systems Engineering is a process that a methodology is has been working for a long time and it's and it's worked fairly well. We've gotten in trouble because this system, as Keith has alluded to, have gotten extremely complex not only in terms of of the technology that goes into building air. Modern naval aircraft today, which is extensive and but also the desire to build.
An aircraft that will work within an overarching system of systems that the baby operates so the Navy doesn't operate just aircraft. They have ships, they have weapons, they have missiles, they have sensor programs across the board, and then we have to work within the confines of the other services. So the future for systems engineering is not just revise system work, but will it work within a construct of system systems?
Anne.
Looking forward to means of achieving that is this thing called model based systems engineering, which is a an approach to modeling all of the requirements rather than doing it in a paper based system and an that is going to really make the tool much more powerful, but it doesn't change the discipline of systems engineering as it set, so that's where I see the future going and it's pretty exciting to me to be working within a company.
That has such a deep bench related to systems engineering, not just because we've all done it before, but we have, but we have a deep understanding with systems engineering is supposed to be doing and the application of these new tools we can make sure that we don't lose the pedigree of what good systems engineering is all about.
Any other inputs about the future of systems engineering we are. I do want to say we are going to talk about model based systems engineering in the future and will dive deeper into what that is on another episode.
Yeah, I, I think the future of systems engineering. I think the you know, just like physics, physics doesn't change, we just use new tools to better understand physics, right?
So you know systems becoming more and more complex. In the past we used to build individual systems that only worked independently to themselves.
And then as we started looking at how these independent systems started working with other systems.
Now we started looking at systems a systems approach.
And how those work together. So every time we get a requirement from, let's say that through the jasons process, Jay Rock.
Those requirements not only are there for our implementation of that system they desire, but it's also linked to multiple other systems out there that meat campaign or mission level requirements that the rest of the Navy requires or DoD requires. So our level of complexity is going up exponentially, so our tools and some of our processes need to keep pace with that exponential growth.
Yeah, so basically what I just heard was improving the tools.
No, is there a? Is there a company that?
Produces a specific tool and then.
I guess what would that improvement look like?
Well, you know, so I think they're ahead.
No, sorry no. I think I think there are a number of tools out there. The one I'm most comfortable with is no magic cameo system architecture, in which it does exactly what Keith and what richer are talking about. So I can decompose a system which is significantly faster than reading a text based document, and I can now share that system amongst rich and Keith. And now we all have a shared mental representation of of assistant.
But it allows us to look at that same system with different viewpoints.
Right, so that we you know if you're looking at it for performance, I may look at it for structure.
Or rich may be looking at for supportability.
But it's the same model and I think that is where the value is. And because we have such complexity and be able tradeoff very narrow design margin of a lot of our complex systems, we need that interaction to model based systems engineering. So it allows us to to understand what those margins are and be able to trade off capability.
You know, between different subsystems in order to get an end state without wasting a lot of what we call swap size, weight, how and so on, yeah.
Cool, so let's wrap this up with one final question. Say I'm in college or I'm already in Mycareer as an engineer, how do I get into systems engineering? What courses in college and maybe Casey? You have some pretty good insight 'cause you just graduated? Like you said, your masters program courses in college. Do you need to take if you're already an engineer? What train is?
What trainings could you take to transfer into systems engineering? Any inputs on these?
Yeah, so I.
When I first started.
The technical background or engineering background significantly helps, and so getting into Cornell going through the system is a new program there. I think what will really help guys out is this a solid background in technical related industries or engineering? Specifically when it comes down to systems engineering, you're especially putting yourself in someone manager role who can help out specific engineering fields, but who also manage the project from a.
A higher level, if you will.
Yeah, and Richard Keith. Are you familiar with anyone that said?
Will an ex engineer I want to transfer into systems engineering and was successful to do that?
Yeah, and I think many of the systems engineer said that are on board at Navair today and we're looking at from our perspective are people who did basic engineering in a specific field. Whether it's I spent most of much of my engineering time in air vehicle airframe and structure development but later on transition to the broader development of aircraft across the board and then.
The systems engineering field is extremely exciting if you're into looking at how do airplanes? How do? How do you build a airplane? And you build the whole thing and bring it all together and have it work. How do you define the needs and translate those into an actual product that?
People will use.
And get real capability into the hands of the war fighter out there so it is in many ways a mix of program management and engineering. But the real focus is on the technical.
Are development and technical planning associated with a major project?
And I've seen people do this work, whether it's in major ground projects like building a bridge or my son in law is working on developing a data system for Google.
Those kinds of things all require program management and engineering management at the top end, Keith alluded to one of the key.
Disciplines here is risk management. To understand the you know we need to always know in any program.
What are my technologies that I'm chasing?
How am I doing in terms of achieving that and what are my risks associated with doing it and where can I get in trouble? If you have all those things in mind and you understand where you are on cost, you've got the whole thing covered. So systems engineering is that opportunity to do that, but state technically grounded enough, the MBA kind of.
Yeah.
Yeah, try to expand on what Casey and also Rich mentioned the.
You know having a technical degree gives you that depth that you need to show that. Hey, I understand how to learn and so on. System engineering processes gives you depth, breadth of information needed across all the disciplines.
But you know, if I was talking to a someone in college, this how do I get into a system engineering one? You have hard skills.
Need to look at is math, mechanical skills, physics, computer skills troubleshooting, prototyping those types of things right. Those are hard skills, but assistant engineer also needs those soft skills which are the communications, teamwork, time management, problem solving, critical thinking, leadership, type of functions too as well to be a very efficient systems engineer.
Gotcha, that's some good points, because I think all three of you mentioned really great stuff. And as far as like you just said, you need the hard skills and soft skills you need to know the technical pieces you need to know how to also work with people. So I think some really good points there. I think we can wrap it up here. So Keith Rich Casey. Thank you for joining me on the 1st episode of Avians Systems Engineering Podcast on the next episode we're talking about Model based systems engineering specifically.
Ann will give a little bit of overview and kind of do a deep dive into what NBC is. So again thank you guys for joining me and I will see everybody next time 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 SIS 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 visitavn.com/capabilities.
