 Subunit 1.3, NASA's approach to systems engineering. The NASA systems engineering engine has 17 activities for system design, realization, and management. We're going to walk through them so you get an idea of how that works. The concept here is that we have a process and you see it on the chart that takes you from initial idea, needs, goals, and objectives all the way through to a final system. So you kind of come up with some idea. I want to study planets around other suns or whatever. And now I can go all the way through and decide do I need to build a telescope to do that? Do I need to fly a satellite? Put it together and get it to operate. So this flow is going to show you how we walk through that whole process. And so the goal here is that if you look at the left hand side, the system design process, that leg of this engine is going to go through and really describe how we go about taking that high level thing that you'd like to accomplish with the system and breaking it down into lower and lower level requirements to make sure that you really understand how each small piece of the satellite that you're going to put together has to operate. What it needs to do, how it needs to perform. So when you look at the first few processes, you see requirements definition process. And so here is where you're getting together at the beginning and you're starting to think through how does the system need to operate? What are the requirements? So if you're talking about a power system, how much power do I need to be able to provide the satellite to operate? How much propulsion? How does the propulsion system need to work? So you're trying to define at lower and lower levels of detail what the requirements are for that system. So again, you started out with a broad concept of what you want to do. Now you've got to really start to give more and more details to be able to get to a point where you're going to actually be able to build this craft and make sure it can do what it's supposed to do. So as you walk through the left hand side of the process, you're decomposing, and this is kind of the critical part of system engineering, right, is that you've got this really hard problem to solve, this hard spacecraft to build. You want to break it down into really manageable parts and you can then assign it to a specific engineer that's really an expert in electrical power systems or propulsion and say, hey, could you please go off and find me the right way to design something that can meet these requirements? So those first few steps are where you're working and looking at an integrated system and trying to go down into the lower and lower levels of detail to really understand what each part of the system is going to need to do to make it operate and meet its needs and goals and objectives, those kind of high-level things you've set out. After you've defined your requirements to see the next part of this, three and four, look at dividing a technical solution. So it's great to have a set of requirements, but that by itself isn't going to give you a spacecraft, right? You need to start to go off and start to do drawings and concept analysis of how do I take those requirements and turn them into a system. I don't yet know what kind of battery I'm going to buy to provide power, but I've got to figure out, oh, I need a battery for the spacecraft, so I've got to do a design where I've included a battery. Gee, I'm going to need thrusters for the spacecraft to keep it in orbit, so I've got to define a propulsion system and look at how that might be designed. And so I'm starting to do some concept of how it's going to look and what it's going to do in operations, and that's what's this next step of defining a technical solution. So steps three and four, take those requirements, and again, they're starting to go into lower and lower levels of detail about the functions that need to be performed, the systems and subsystems and components that are going to be needed to perform those functions, and starting to lay all that out in some hierarchy so that, again, you can really understand at the lowest level what are all the things you're going to need to do to make the system come to fruition, because as you finish up this one side of the system design process leg of the engine, if you scoot all the way over to the bottom of the other side where it says product realization processes, that leg, you're going to kind of walk up that leg, that's where you're going to actually take that lowest level of detail of design and you're going to take that lowest level set of requirements, and now you're going to go off into the marketplace and say, are there thrusters? Is there a battery that can meet my requirements at that lowest level? It has to provide a certain amount of power. It has to be a certain size, a certain mass. I can only afford to have it be so big. So I'm going to go look at a bunch of products that are available. Maybe I have to build my own, because maybe there's none available in the marketplace. And so this right-hand side of the tree or the engine, as you're coming up that side of the engine, you're looking at, okay, I've got to buy the lowest level components. I've got to make sure that I can verify, and verification is going to be a big part of system engineering, is that when you get those lower level components, you have to make sure that if you looked at the requirement for that component, that the one you bought can actually perform the way it's supposed to perform. Does it put out the right amount of power? Does it not get too hot? Does it operate the mass that I needed? You know, wherever those requirements were, you've got to make sure that you can verify that that was met. So as you come up the right-hand side of the engine, what you'll notice here is that you're going to start off with small components, and by the end of that side, as you get up towards the top to the product transition processes, you're going to actually be building up your entire system. And along the way, at each point, you're going to verify that the requirements that you levied on the system can all be met. So again, if it's a battery at the lowest level that I purchased, does the battery do what it's supposed to be able to do? Then when I put it into the power system, does the power system for the spacecraft do what it's supposed to do? Then when I put the power system into the spacecraft, does it do all the things it's supposed to do? And so I'll be verifying all the way along as I build the system up to higher and higher levels of maturity that it's still able to meet all the requirements that I levied on it. And remember, as you walk down that other leg of the engine, you were levying those requirements at lower and lower and lower levels. So now you're just going to verify as you move up in maturity that those requirements are being met. So there's a connection between the left-hand side and the right-hand side, the definition of a system and what it needs to do, and the actual production of a system and getting it to operational state. So what's the glue between that? And that's where system engineering is right in the middle, technical management processes, right? What are all the things you knew to make sure that as you design the system and as you produce it, that you're making sure that this is going to be a realized product that's going to be operational, meet all of its requirements, come in on budget and schedule. And so in the middle there, steps 10 through 17, you can see that the engine really goes through and says that, okay, we've got these management or oversight processes that have to happen to make the system successful. And that's where system engineers typically play their major role. So the technical planning process, step 10, where you're starting to work on making sure that all the schedules are laid out and that all the things that need to happen to really lay out this technical work that needs to be done and how the team's going to work together and all the functions that have to be performed to make the system come to fruition, that's where all those things are happening. You see in the middle, technical control processes, steps 11 through 15, requirements management, interface management. So requirements management meaning that you want to make sure that the glue is there to check that everyone's using the same set of requirements and that the requirements are controlled. Because let's say I'm the power engineer and I say, gee, I can't find a battery that meets the requirements. I'm going to go ahead and change the requirements and make it so that the battery can produce less energy. That works for me because I could find a better battery. Well, on the flip side, you might be impacting a lot of other people who are off designing assuming they're going to get a certain amount of power from that battery. So that's where this middle part of the process comes in handy and that's where system engineers are really in charge, just saying, well, wait a minute, I can't allow you to change requirements for the battery because I have to first look and make sure that there's no system-wide impacts that need to be considered. And so that's part of the processes you see in the middle. The next one is interface management, just as critical. As you decompose any problem into smaller and smaller pieces to be assigned out to everyone to work, you have to worry about all the interfaces now. Will that battery connect up to all the other parts of the power system? Is it going to have the right types of connections? Will the battery connect up to the computer system? It's going to operate the battery and charge and discharge it. There's a lot of interfaces there between different people and different workgroups. So interface management becomes key, again, to the system engineering team, is that you have to be the ones who maintain those interfaces, clearly document them and make sure that everyone's working to that common interface so that when you do bring the system together on the right-hand side and the battery gets put in and you put the solar rays onto it and you hook up all the computers, everything's going to operate properly. So interface management is key. Technical risk management is the next one. So along the way as you're developing the system, whether it's in defining requirements and doing design or whether it's in the maturing of the final product, you're going to have risks involved. It's the things that keep you up at night, it's the things that the team is worried about and they're worried that if this was to happen, something was to happen, it might prohibit us from being successful. And so the goal of the system engineering team sitting in the middle of this chart is to say that all along the way, all during this process of maturing the system, the team is there to say, wait a minute, what's keeping us up at night? What are we worried about? And let's go through and make sure that we're managing that set of worries in a good way. So if I can at least describe to you what I'm worried about. Maybe I'm worried that the battery team is going to come in behind schedule because they're having a hard time picking a battery, there's none available on the market. So I'm really worried about that. Let's define that and how worried am I? And if I'm really worried about it, shouldn't I be doing something? Maybe I should be proactively bringing in some new talent to assess the situation, going off and looking at other options that don't use batteries. They use a different technology for storing energy. What are the alternatives? And so risk management is where you have system engineers in the middle of this process all throughout trying to figure out what can we do to make sure that any ideas of people that anything that people are worried about, you know, any risks that they perceive can be mitigated or addressed in a way that it's not going to prohibit us from getting done on schedule and on time and getting the product to perform as we want it to. So other areas here are steps 14, configuration management. So configuration management where the system engineering group is really trying to make sure that there is a baseline along the way. A baseline being one controlled set of requirements, one controlled design that everyone is working to, whether you're the power engineer or the computer engineer. When you go to the drawings or when you go to the spacecraft requirements documents, you get the same set of information. So configuration management and making sure that everyone works from the same baseline at all times is really key so that people don't start to move in different directions, maybe using an old version of a drawing or made their own updates to a drawing and they're using those instead of the baseline. So technical data management, all of the other parts of this process that need to be controlled, all the data that's flowing about trade studies and assessments that are being done. Somebody has to manage that so that it's all in one place so that anybody on the team can go look at what's being done, what assessments have been done in the past, what lessons have been learned by the project that's just maturing. And so all of that data has to be managed along the way. The last couple of steps here you see the technical assessment process where along the way you're going to come in and make sure that the project is maturing technically and doing assessments of that maturity. So there's all kinds of peer reviews and other kinds of reviews that the engineering team will use to bring in some people maybe who aren't working on the project day-to-day to look at the design and say, gee is this power system design really coming along as it should? Are there some issues here that an outsider might see that people on the team might have overlooked? And so there's a whole assessment process that's going on where the engineers are kind of going, the system engineers and maybe bringing in peers to look at and make sure that the system continues to mature and stays on track. So the next one here, the last one is step 17, the technical decision analysis process. And so this is a process of making sure that as the system matures if you're doing some trade studies or analysis of alternatives that those are coming to fruition and decisions are being made in a timely manner. So I work on a project right now where we have to make a lot of decisions where in phase B and during that decision-making process if we were to spend more time than necessary on any one decision we would fall behind in our development process. But on the other hand, we are hesitant to make decisions too quickly where we might not have done enough analysis before we make the decision or where we might not have enough people involved from different subsystem areas to do an assessment. So we really want to be cautious, but you really have to make sure that you understand what are all the things we're looking at, what are all the areas where we're trading off maybe one option versus another and when's the right time to make decisions so that we can keep this whole project on track. And so again, all of these steps, steps 10 through 17, the technical management, you think of the word management and you don't think of system engineering, well it is. System engineering is really a management function as much as it is a technical function to make sure that everything is coordinated to get to a point where you have a mature system that can be put into operation. Now click on the icon to read section 2.0 Fundamentals of Systems Engineering in the NASA Systems Engineering Handbook.