Systems Engineering - Principles & Approaches from Systems Engineering Domain | 2026 ASP Colloquium

[music] So when I came to ENCAR four years ago, I had no idea what convergence research or science is. I had not heard about it. But I had a lot of great conversations with Mariana and Chris Wears that you will hear from at the end of this week. can be at the time we were posttocks and I slowly started to learn a little bit about convergence and then Julie of course started to uh have more conversations and talks and slowly getting to know about convergence I could see similarities with what I would call systems engineering and I was very curious to see where are the overlaps uh is this just two different communities coming together uh from different angles uh trying to solve similar problems where systems engineering is coming from the engineering perspective and convergence from the scientific perspective. And so those were the questions that we're still thinking about and trying to figure out where do these uh disciplines have overlaps or similarities. And when we started to plan this colloquium, I was so excited and appreciative of Mariana and Julie to be open to bringing that systems engineering lens into this uh colloquium and introducing that concept as well. And I was just having conversations with Allison as from her perspective now hearing from convergence. I was kind of gut-checking with her. Do you see the similarities? And she was like, yes, I do. And I see now why I'm here and why you wanted me to give a talk. So, um, uh, just a quick introduction to Allison. Thank you so much for accepting our invitation. And I met Allison about a year ago, I think almost. Um, and so if you're not familiar, the professional organization for systems engineering is called INCOI, International Council for Systems Engineers on Systems Engineering. And it has a variety of working groups that people come together and work on a specific topic. And Allison co-chairs the natural systems working group. and that's how I got to know about her. But she has uh vast experience of applying systems engineering in the medical field. Um so a practitioner of applying it and one of the main things that I really wanted Allison here is that she's also an educator for systems engineering. And she's been educating in informal settings and by that this colloquium is an informal education setting where we're not in academia but we're still learning about important topics. And so I really thought that she would be the perfect person to bring that systems engineering lens and she has taught and educated people on systems engineering from different backgrounds in different organizations at different levels. So really excited that she accepted our invitation. And with that I'm going to ask you Allison to really introduce your own background and your journey. And I think it would be more interesting if they hear it from you than if I go through a bio. So thank you Alison. >> Thank you. Yeah. Thanks. Hello. Uh, thank you so much. Can you guys hear me? Well, okay, great. Uh, thank you for the introduction and also a huge thanks to all of you and the work that you guys put in uh to creating curating this program. There's just so much thought and care that was put into it and it's only day two and I'm just like yesterday I was like sa can I stay [laughter] can I stay for the whole thing and watch um because it's just you guys it's I know how much I don't know how much work it was but I can imagine how much work it was and I'm very appreciative to be a part of it and so when you asked me you know the question you know about what my response was when I was asked to come talk my answer was curious because what can I offer What do we have in common? How do these worlds overlap? And hearing Lor's talk this morning, oh my gosh. And and it's we're in these des disperate, you know, spaces, relatively speaking, but there's so much common language and so much common ground. Things we've discovered, you know, independently, but can be shared. What are all of the things we learned? What what what would I strike if I were to do it again? what are some best best practices that we can share with your group so that you can kind of stand on the shoulders of giants which I'm standing on the shoulders of other giants um to incorporate into your work. So um so I've been invited to share some learnings and knowledge from the engineering domain and specifically the systems engineering domain um which I hope can be helpful um for you when you're thinking about all these complex problems um that we've been hearing about uh yesterday from Colin and um that are inevitably embedded um in the the large and interconnected global uh network that we all participate in. Um so there's a lot to get through with my presentation. I I hope unlike Colin I I I think I overfilled my time. So I'll try to keep my intro a little bit brief but I think it's also uh relevant. So um my engineering education is in mechanical engineering. So I've got my bachelor's and masters in mechanical engineering and I focused in biomedical engineering. Um but before that I actually have degree in communications and psychology. So that's where I started. I wanted to solve people problems and help people. Um, and I worked in HR doing internal investigations and mediation and dispute resolution. Uh, that is very challenging work. And, uh, I didn't feel like I could really solve their problems unless, you know, we had a couch and I had a notebook and we had more time, right? Um, and so I went back to school to solve what I was hoping would be more black and white problems, right? Math and physics problems that had discreet answers. And, uh, so you can guess how that turned out. You know, how often is the answer black and white? you know, never um because there are always people involved which adds complexity and richness. Um and and so the bulk of my engineering career has been in medical devices. So designing surgical and diagnostic equipment um and I came into the systems engineering world I'll say seven or eight years ago. Um when I was just I'm a curious person so I'm just always kind of asking why um why are these disease states what they are? Why are we seeing this increase of colorectal cancer in in youth? Um why why why right which surgeons and other researchers were also asking? Um, but I just kept zooming out further and further, right? What are what are all of these variables that lead to this disease state or this pathology and how do we make sense of them? Like they're so concmpatant, right? It's just so complex. So searching for tools and one of my colleagues had done some work in systems engineering and we were applying it in our discipline to figure out how our devices fit into the broader health care space, right? regulatory requirements. How do they fit into the O space with all of that other equipment and beeping and alarms and the user interfaces and patient needs, right? How do they fit into purchasing and acquisition? How does it fit into the insurance and reimbursement system, right? Just that small bubble [laughter] in and of its own is quite complex. So, I was looking for tools. Um, and so systems engineering wasn't the, you know, the the silver bullet for any of that. So, just spoiler alert. Um but it it started to open my eyes um in terms of kind of how to look at a complex system, how to start to kind of nail things down at least um and then we can kind of figure out how what else we can kind of pull down and nail down temporarily albeit um to make sense of all this space. Um, and so since then I've kind of moved into kind of I think between my communications background and my curiosity and um I've moved into the educational space and kind of training and consulting space because I want to share that information. I want to help all of the super smart people that are working on these hard problems give them some tools or translate bring tools that I've seen be successful um to help them do their job better and accelerate and uh um solve some of these vaccine problems. Um so I've worked in um with teams from aerospace, the department of defense, uh transportation, uh agriculture, healthcare and med devices. Obviously I've started to kind of move into um into food systems um and with embedded within the agricultural space to figure out, you know, talk about soil systems, nutrient cycling systems, and all of the um farming practices that we use, regenerative agriculture systems, things like that. And I'm just fascinated and I've um recently started working with um a wonderful woman. She's an ecologist and we're looking now at how what can we learn from natural systems um and apply them to our physical systems, right? Because that's the ultimate model of sustainability and resilience and adaptability, right? So, if we could kind of anthropomorphize the functions and the elements and what they're doing, their roles in this system and how they're adapting to these disturbances that are mostly man-made, but obviously some natural disturbances that they have to field. Um, what can we learn from them? So, I'm really excited to move in that space. It's called biomimicry or ecosystem mimicry if you're familiar or interested in that. Uh, all right. So, um, spoiler alert, systems engineering, it's just it's all about organizing things. Okay? So, it's naming things. It's putting them in buckets so that we can make sense of them so we can rotate them around. We can hand them to someone else and ask what they think about it. Um, so I've organized the content for this talk into three buckets, three categories. Uh, kind of borrowing from systems engineering. Um we talk that um when you're kind of working on a project some some a tool here is to think about what is the the language that you're using um to communicate with your team. So what is that kind of establishing a common ground? So we're going to talk about some really basic vocabulary in uh systems and systems engineering just to kind of start building that baseline and we can start adding more and more layers to it. Uh and then we'll talk about uh our uh a method. So we've got all of this information. We're we're all thinking differently. How do we begin to solve a problem? How do we be begin to apply our knowledge and our our motivation, our inspiration, and our our empathy towards solving these problems? And then um I'm going to talk about some tools that you can use really simple classic systems engineering tools that you can use right away. Um but then you can also advance them and add more complexity and use really complex software to run simulations and and and create models of your system um that you can use to communicate with your teams. So, we're talking about how people think, right? We're talking about how the mental models that people have in their head, right? We all have mental models, right? Based on what our parents taught us, our teachers, our mentors, our colleagues have taught us. Um, and we often kind of go down that path automatically because we can make sense of it. Um, it's familiar, it's comfortable. Um, but that doesn't always mean that's what is, right? And so we've been talking, this whole colloquium I think is about learning about different ways to think, acknowledging, recognizing that other people think differently, right? And how can we train ourselves to think differently and turn those filters on and off, right? Switch those hats. Um, so we can just start thinking differently and maybe start to illuminate some of the real truths about what is happening, right? It's what we can observe based on what we can understand, but there's so much more. So to really see and understand the world around us, it requires some systems thinking. Um so this involves moving beyond just observing individual events and reacting to them, which is um what we do often at larger scales, right? We've kind of heard about we know that this is coming, right? And we have some information about the patterns um in tornado alley or in these um high aid montaine environments, right? Um we know that there is infrastructure that exists and people that want to help, right? But how do we change our mental models to get us to see it all and to take action to do something a little bit differently? [snorts] So, so when I say system, I'm sure all of you have something that pops into your head, right? Um, based on your background here, I'm guessing it has something to do with an earth system, right? Um, some abiotic system or a weather system or water cycle or something like that. Um, so of course that is a system. Um, but we can talk about all sorts of systems. We can talk about um energy and material cycle systems, nutrient cycling systems, uh the human body as a system and all of its subsystems. Um all of the systems that humans are involved with, right? Our social systems, our municipal systems, our government systems, economic systems, and then we've talked about um those being separate from our our built systems, our tech systems, um and so on. And so what I'm hoping is that the principles and tools that I'm introducing today, you'll see that you can apply them to any type of system as large as an earth system or a space system, a solar system, the universe, or as small as a human cell and the mitochondria and all of the elements that are within that cell, how they interact, the functions they perform to produce some behavior to connect it and add value to the next larger system that it operates in. So what is a system? There are a myriad of definitions for this. You've probably seen a version of this or maybe you've heard that a system is more than the sum of its parts. Um or that system systems pro produce emergent behavior that couldn't be achieved by any of those individual parts or subsystems. And this is all true, but but what do we do with that definition? This is kind of abstract and grandiose right like okay what does that mean the purpose and what does that mean the interconnections so we're going to talk about that and to start we're going to talk about a system as being comprised of three kind of categories of content so there are the elements in the system right the things we can see and count and and touch and talk about these are the nouns they can be individual things this computer, this mouse, a student, a parent, a mayor, a quarterback on a team or they can be collections of things within a broader system. A system is comprised of functions. So those elements are there, they exist in that system for a certain reason, to do a job. They have a purpose and that's to perform some function, at least one, often more. And so when we're talking about functions, we're talking about verbs. So what is the thing doing? So typically we're talking about action verbs, right? So there there's some function that's acting on some other object in the system to transform it. And we want to separate the function from the form. And I'll talk more in detail about why that's valuable. But it first of all it helps us to kind of make sense of the system and kind of characterize it, put it in buckets because we like buckets. Um but ultimately it allows us to design better systems uh systems that are more modular and adaptable um and uh maintainable. And then a system has relationships or specifically the elements in that system have relationships to each other. Um and and these are a little bit more complicated, but this is what makes systems work, right? These relationships are necessary to connect the elements together so that they can perform their functions in coherently so that they can exchange information or matter or energy with each other. So these are to stick with the grammar uh kind of theme here. These are going to be uh verb structures like these auxiliary verb structures but they they'll have constraints or qualifiers to them. So let's consider the human body as a system. So what are some elements in the human body? You guys can just start shouting things out. The heart, >> muscles, brain. That's it. [laughter] >> The nervous system. >> The nervous system. Yep. Thumbs. >> Skin. >> Skin. Yeah. All correct answers, right? These are elements in the system, right? And they might we might be talking about a circulatory system which is all over within our body, right? But or we might be talking about the heart that interacts with that system, the circulatory system or the thumbs that receive something from that circulatory system. Right? So we're talking about kind of different levels of hierarchy within that system. So there are systems within systems, systems within the human body system. Oops, sorry. All right. What are some functions of the human body? Breathing. Yep. moving, sleeping, [laughter] yep, talking. Yeah. Again, all correct answers, right? Verbs, right? What what is the system doing when it's in a given state, right? And we can start to also think about why. Why are we breathing, sleeping, moving, right? So that's an important question that we'll come back to and we're not going to get too philosophical about [laughter] why humans exist, but we can. Okay. How about relationships? What are the relationships in a human body system? Okay. So these are like flows, right? Moving between the elements, right? Yeah. Relationships are a little harder. They're a little harder to kind of nail down, but as I said, they're key. Um, they're what make the systems work. They're what create that emergence. And so, let's talk about some relationships. So, people will organize these and describe these in a number of different ways. This is what makes sense to me. So, relationships can be structural, right? So, physical attachments, right? tendons connecting muscle to bone. Um, a bolt threaded in a nut, my shirt sewn together, right? These kind of obvious and um, physical attachments, but they can also be spatial relationships. So, how are things physically related to each other? So, why is my stomach below my esophagus? Why is my small intestine after my stomach in terms of how my the gastrointestinal system is organized, right? Has to do with the functions that they perform, but they can't perform those functions unless the stomach can't do what it needs to do unless it until it gets food passed to it from the esophagus and vice versa or on down the line rather. Hopefully, your stomach's not passing something to your esophagus unless you have reflux. uh there are functional relationships. So um exchanges just as you were describing right blood moving throughout the system, nutrients, oxygen, um lymph within the human body. So two elements oftentimes are going to have some physical connection or some conduit through which those exchanges can occur, but they have a relationship or perhaps multiple relationships. And one of those is to exchange information. So this can be communication you know raw data right my computer system is transmitting information data right to projecting it onto the screen right it can be communication signals right so birds chirping that's an exchange of information between those species they can exchange matter right so again blood moving through the system being pumped by the uh cargo being transported by an airplane. Uh they can be energy exchanges which is a lot about is very relevant in your space. Um difficult to characterize but we have a lot of um tools to measure um absolute and relative energy presence in a system and how it moves. So these can be you know electrical um power uh form of energy as it's being passed into your house and into your refrigerator. Uh it can be force transfer u mechanical energy um as I pinch my pencil to write. So those are exchanges and and these are um very common uh relationships. There are also rules in systems that guide how the elements can interact with each other. Right? So laws of physics um how atoms can bond together based on their you know availability and their electron shells. Uh Newton's laws equilibrium seeking seeking dynamics. Uh laws in a government or in a social system right that protect its citizens that guide um ethics hopefully. um laws or rules in an organization that guide the reporting structure, who answers to who, rules in a game, a football game, social cultural norms. So these are rules about how the elements in the system interact. And then dependencies. So these are going to be a little bit more uh context specific and they're going to change with the system um over time. Usually it's going to be in response to some stimulus, right? Some disturbance. So like a plant's response to a cold snap. It's going to react differently than it does, you know, during normal operating conditions when the sun is shining and we're kind of moving through the seasons as expected, right? Something changed and it has to respond in a different way to protect itself to survive. Um, a coach's strategy in a game, right? Are you winning or are you losing? Okay, I'm going to change my strategy now based on that. And that's different than when we started the game. And it's not a formal rule that always applies like laws of physics and things like that. So these are types of relationships, PhD in and of itself, honestly. Um, so a system has elements, functions, and relationships. And those all exist to serve some purpose, right? They're there for a reason to do a job to accomplish some higher goal for the system. And then there are other principles that guide systems, right? They they they're comprised of structure that perform behavior like we just talked about that align with the purpose. And systems don't exist in a vacuum. They have context. So those elements in your system, they take the form that they do because they're operating under certain conditions because of their surroundings. Right? So if you look at two different ecosystems, they could be described or modeled similarly in terms of the functions or services that they perform, but the form, the elements, the species in them might look very different depending on if you're talking about a tropical or an aid environment on land or in water, right? So we can describe a systems functions independently of its structure and we can make sense of why that structure looks the way it does based on the context the operating context. We'll talk more about analyzing operating context. Uh and those systems they interact with their environment. They take something from their surroundings. They do their job perform their functions and then they will pass something out into their uh external environment. And so we can observe that and quantify that by drawing boundaries around a system. And those boundaries, they can be easy to see like the skin, right? That's just bagging up all of our organs, [laughter] right? Or they can be difficult to see, right? When we're talking about things that, you know, in the air, weather systems and things like that, which leads to number four. So systems are inextricably connected. So, like I said, some systems have boundaries or containers that we can um see and and quantify and use to guide our analysis, but ultimately we're all just energy and atoms, right? Constantly being reconfigured throughout time and space. And then all systems exist in their state temporarily. They have a life cycle. right? They take a certain form and that changes whether it's, you know, the the birth of a baby moving through an adult life cycle and a human dying or any of the other um plant or anime kingdom or it's a physical system where we conceptualize it, we build it, we deploy it and we need to decommission it or it's the nature of a natural system, erosion changing the form of a mountain and then its impact on the wind and the air cells that move around it and pass it, right? So, it's all changing. So, what systems do you see here? All right. If you're struggling, that was a trick question. [laughter] >> Infrastructure. >> Yep. >> Yeah. lots of systems that if we choose to draw a bound a boundary around that uh transmission line or that wind turbine, we can see energy infrastructure. But we could also remove all of those lines and understand that it's just flows within the same system. >> Oh, sorry. Um, can community be a system? >> Yes, absolutely. Yeah, great question. Yeah, absolutely. All right, so what we're looking at here is a system of systems, right? And so we can draw boundaries around a portion of it, zoom in, scrutinize that particular entity. It allows us to focus on what's what's contextually important. Um, identify the elements within that boundary, the functions within that boundary, the relationships within that boundary. And then we can look at where its outputs go. What's the next system down the line? What receives or absorbs or goes out to collect the outputs of this other system. So this transmission line is receiving electrical power and then it's distributing throughout this community. So they're linked together. They have a relationship. Well, how about where do the inputs of this this power system this um generation plant come from? Its external environment, right? So, a variety of different energy um harnessing um systems can generate um the energy that's required for this power plant to transform it into electricity. Well, where did the inputs to the wind turbine come from? Right, its surrounding environment. And so, we can draw boundaries around these things and we can make those boundaries as large as small. We can shrink them, grow them, erase them, um, draw them in per permanent marker and then we can connect them together to see how they influence each other dynamically. There are concepts about this that aren't new, right? This is system dynamics, right? Nodal and network analyses, uh, FAS, things like that. But we're trying to we're now we're looking at a macro view. We can still use some of the same principles when we're talking trying to quantify and analyze these systems, but they're a lot more complex and difficult to name as I'd mentioned. So if we review that grammar, we're talking about a noun, a verb, or a constraint or a qualifier, a relationship, we can make more sense of it. So we're going to talk about some approaches and tools that you can use. Um they're a little bit abstract. It's kind of hard to talk about them without like a notional example. So we're actually going to use this power grid as our system of interest that we'll be studying. Um and the context here u might be familiar to [laughter] um people who live in Boulder. So, we're going to be talking about a small city that's rethinking how they um provide power um to their residents and businesses. Um so, in the face of climate change and increased weather hazards, they find that the risk of relying on a centralized electrical grid is causing uh more uncertainty and cost. Uh the residents and business owners are also asking for more sustainable uh energy solutions as well. So, they've organized this group of decision makers and community voices. um stakeholders to talk about and explore what that might look like. Okay. And so you can see here in the background here there maybe they might be covered by this storm cell that's coming but um this this city resides in in the foothills right in this kind of transition between a montaine um an alpine environment to this kind of high aid desert desert prairie or high desert prairie rather um and uh so it's aid the con citizens are concerned about high wind events um and other weather threats that might impact the grid um and that energy distribution caused some wildfires as we've um seen here and other communities in the Mountain West. And so before they embark on this grand system overhaul, they want to ensure that they've thought it through, that this is a good idea, that they can have add value um and make sense of it all. So where do you begin? Where do you begin? >> [laughter] >> Okay, I didn't expect you to answer that one either. Um so um um I'm going to walk you through a method um a very high level method um from the that's been um kind of brought about from product development and systems engineering and we're seeing it in other spaces too as we are from Lori right this isn't unique or new to this SE space but I think they've formalized it as engineers tend to do right we need to write it down and standardize it um and so hopefully we can use this as a navigation tool for any type of system so I've tried try to kind of extract out all of the the best parts, the marrow um that can be um utilized in all these other domains. So hopefully this will help you kind of find your way as you're dealing with these messy unstructured problems. So a little bit [clears throat] about systems engineering. Uh so here are two definitions. The first one's a little kind of um vague, but this is put together by um the uh Inosce organization that Suda had mentioned in international uh council on systems engineering. So they're uh kind of an overarching body that provides guidance and education on systems engineering principles and processes. The second definition also very wordy. Let you read through it. But I like it. It's all-encompassing and it's idealistic. [clears throat] That second sentence, it ensures that all aspects of a project or system, all aspects of a project, a system work together effectively and they address all of these different factors. Isn't that amazing? Are you guys excited? Uh this is can be true mostly true um but only when done well it's not guaranteed if you follow this process um that these outcomes are guaranteed. So, it's going to require discipline, attention to detail, patience, uh a large dose of courage, um to have some of the difficult conversations that you need to have to stand up for some stakeholders as we heard um is so critical in our civilized society so that we make the right decisions and that our system truly provides value for the greater good. I I personally believe that that most of our failures or unintended consequences that we're seeing from our built and physical systems is it's because we rush. Um we have fixed budgets. We've got fixed schedules. We need to get to revenue as fast as possible. Need to get our margins right. We might lose out to a competitor. And so we skip crucial steps. We ignore crucial stakeholders. We think short term, not long term. So in systems engineering, what we're trying to do is we're systematically studying a problem and we're systematically taking action to use the word in its own definition. So again, there's nothing particularly novel that we're doing, but we're kind of trying to nail it down to be useful as we explore some of these problems. So systems engineering it arose in the uh 50s60s um as a result of you know the space race. So we're starting to kind of move outside of the earth um designing large complex systems um operating in these challenging and remote environments that weren't fully characterized. We knew enough obviously um to launch and put men on the moon. Um they had huge budgets. They had high risk. Little to no room for failure. So they had to get it right. And so as our systems have evolved, the processes in systems engineering have also evolved. They've gotten more sophisticated, more interconnected. And so here's a process. Here's a systems engineering process or set of processes. So this is uh defined by an international standard uh ISO 15288 um a guide created with collaboration and um solicitation from companies and subject matter experts um primarily from the aerospace defense and transportation realms. Um so [clears throat] it's the standards called the uh the standard for systems and software engineering and life cycle processes. So a lot of the content on this slide, a lot of these these guidance and these processes exist so that organizations and developers uh build and deploy systems with integrity so they systematically uh incorporate quality, accountability, traceability uh into their products and systems. And so and then if you're dealing with say a government contract, you're often beholdened to doing this to satisfy that contract, right? So they want to put that down on paper. That's another motivation for this standard. But you can see so much content here. A lot of this is related to project management, planning, document control, test protocols, how parts are managed and um revised. So we're going to thankfully uh just focus on two areas here. So within technical processes, we're going to talk about how we define our concept a concept of a system, where that comes from, how we define the mission of our system, how we identify stakeholders and their needs and what they're asking of the system. And then once we understand that what the system needs to do, we can move on and start defining the system. So we can nail down requirements. this is what the system shall do and then that guides the design teams. Okay, it has to perform these functions. has to meet these stakeholder needs. And so then they can get to the engineering work um of the design and testing. And then uh we we won't cover what happens after that where you have to integrate all of those parts and components and sub assemblies and test them, verify and [clears throat] validate them and then deploy the system, maintain it and decommission it. And so I'm going to distill it even further, simplify it so that it's hopefully useful in your space. And so I've kind of pulled out some of the core steps that when I've worked with a variety of teams from different domains and disciplines and seen them apply it to different system, levels of systems and types of systems um what I see used often and what I see used effectively and what's most approachable honestly. uh because if we start getting beholden to our process and it distracts us from the real work uh we're already we're in trouble coming out of the gate. So we're going to I'll talk about each of these in detail, but we're going to start with the stakeholder analysis. So we heard about stakeholders being critical, the who and the why. Why are we doing this? Because we have a problem that we're trying to solve and some subset of that stakeholders is asking us for help. they're asking us to solve the problem. And then we're going to be at uh talking about use cases. So the stakeholders and how they want to use the system are going to drive the purpose of the system. And then we'll analyze what the system has to do. The functions that have to exist in our built system or in the system that we're observing and trying to study and characterize. What fix functions are already there that are critical that we need to recognize? And then we'll move on to define the elements that are performing those functions and their relationships. And then we put it to work. We implement it. And then voila, we get emergent system behavior. And then there's some auxiliary tasks that we'll u I'll talk to you about that we want to do along the way to make sure we're designing a good system, an effective system, an adaptable system. Um, and I'll talk about how you can use your system architecture to help you assess risk and evaluate tradeoffs. So to enable your decision- making. So the reality is this is not linear. This is a place to start and some big buckets of of these exercises that you want to complete, but you're you're going to be going back as you're defining your system. You're going to go back and check some use cases. Does this match with how they want to use it? When you're defining your functions, you're going to go back and check in with stakeholders and to have conversations with them about is this really what you need it to do. So it's uh a process, a method, but it's it's iterative and you can take any one of these things and all a cart and and apply it and I think add value to your project. All right, so first we'll start with stakeholder analysis. And I apologize in advance for the crude graphics. I'm using a systems modeling software to kind of draw some of these diagrams and very good at executing simulations and building complex models, but not so good with the the human um wow factor. [laughter] Uh okay, so the stakeholders, who are the stakeholders in our municipal, we're we're going to design a municipal power system. That's our goal. That's our task rather. Who are the stakeholders? We have community residents. We've got the people that are coming into town, visiting, hiking, going to our football games. We've got the business owners. We've got the governance, city governance, and some emergency response services, the grid operator, weather forecasters. This is just a very minor subset of the stakeholders. But in this exercise, what you want to do is cast the broadest the broadest net that you can. So, as we talked about this morning, bringing a diverse team to the table to help compile this list. And it doesn't mean you have to do something or address the needs of every single stakeholder. But if you capture that and you put that on the list, somewhere down the line, you're going to be grateful because when it comes to decision- making and trade-offs and risk analysis, you're going to want to be thinking about who this system is impacting, whether it's the designed system or it's any unintended consequences that come about because of that. So cast a broad net and then you can kind of start to group them together about some shared needs or interests or asks, shared characteristics, right? So, the grid operator for a power system, what is their training level? How good, how well are they going to be able to operate this system? Are they going to need training to be able to use it? Is there a human error factor that could come about? We want to list them all out and then identify some of the characteristics of these stakeholders. And this can just be in an Excel document. Um but there is modeling software that exists where you can create objects for each of these for a stakeholder for a need and and you can these are reusable objects that you can connect to each other and you can so you can extract that out of your model later and then we move on to analyze use cases. So how do these stakeholders interact with our system of interest? How will they use it to either survive or how how do they want to use this system as an extension of themselves to add to their capabilities or advance a certain goal or improve their environment. So first we identify nominal use cases. So kind of the day of the life of the system. How do how does the resident want to use this power grid, right? cool their home, cook dinner, charge an EV, right? And then we can do that for every single stakeholder on our list, ideally by going out and talking to them. How do you want to use this system? What do you want to see from it? We can go talk to the BA business owner. You can go talk to the city council. You can talk to emergency response services. How would the emergency response personnel interact with this system? Right? that will use power like any other resident or business, but also how are they going to interact with the system to manage or respond to threats to the community if something should go wrong? How is the grid operator going to interact with the system? So we define these nominal use cases and then we start thinking about different scenarios. So these off-nominal scenarios, right? So extremes, error or fault conditions, all of the different ways that the system could be used that wasn't maybe in our original thinking, but it can it's not just the bad stuff, it's also these additional capabilities that the system might be able to offer that um don't happen every day. So we create scenarios or some people call them user stories to describe the path of execution for a use case. So we're analyzing that use case context, analyzing it from the perspective of the stakeholder that is living and using that system or being affected. It's not just the users. It could be anything that's passively affected by the implementation of the system. So you see I have earth there. That should be on every stakeholder list and it should be more detailed, right? We should be talking more about specific ecosystems or species or landscapes that we're impacting, right? But just by popping that little icon on my list, whoa, okay, if I'm going to design a power system, crap, I got to think about Earth. Like, you know, you're just already starting to think a little bit differently about emissions and the outputs and its its u impact. And then we can link the stakeholders to the use cases that they're associated with, whether they're direct participants, they invoke the use case, uh, or if they are in any way affected by it. And again, in this modeling software, you can create these associations and then you can create a matrix and and view use cases and any stakeholder that's associated with it. So when I want to go think about manufacturing widgets and the power that that's going to consume, I can see this list of all of the business owners and I can go out and I can talk to them. Okay, what do you need from this? What are you concerned about when it's really hot and all of the residents are cooling a home and you've got to get, you know, volumes of production out and you have to still, you know, how do we balance those power demands? So you're starting to kind of create a set of user needs and sort of a traceability, a thread of traceability for why this system needs to exist and who's asking for it and what would bring value. Oh boy, I got to move faster. I'm sorry. Okay, so functional analysis. I get I I just want to keep talking. Okay, so after we analyze our use cases, then we move on to a functional analysis. So we identify a stakeholder, the use case, and then we need to identify the system function that's going to carry out that use case. So we're moving from what we call the user domain to a system domain. So now we're talking about the system we're going to design or the system that exists in a natural system that we're trying to observe what's happening. So the system needs to be able to distribute power so that we can execute this use case to cool a home to make this resident happy. emergency response services. They want to detect threats to the community. So, what does the system need to do? It needs to do some monitoring. It needs to self-monitor and perhaps provide us with some data or an alert or a warning about its status. the grid operator. They want to control the grid power operations which means they also they need to distribute power and they're they need the system to monitor itself but they also need it to balance the power load. So we can define a system function that has again traceability back to a use case and a stakeholder and you can repeat this for every use case that you identify. So you can create links and create functions that realize them and you want to do this throughout the entire system life cycle. So we want to talk about maintenance and upgrades and de decommission and disposal of the system as well. And so once we define a system function then we can start to talk about what the system structure the elements in the system are that need to implement that. So, if we're going to distribute power, what's the thing that's going to do that for us? The element in the system. It's some set of transmission lines or some network of transmission lines. We're going to monitor the grid state. We need a fault protection subsystem, something that's looking for and detecting anomalies, sensing its environment, and determining whether or not uh our uh EMS needs to be alerted. Oops. And then for balancing the power load, we need some sort of control command and control subsystem. So here we're talking about top level system functions. And so that kind of translates to some top level structure. So it's kind of hard to think about a fault protection subsystem. What does that look like? If I picked that up and moved it over here, right at the highest level of your your kind of system, I'm going to talk about system architecture shortly. These are kind of aggregates. It's just kind of describing trying to capture the essence of what is really below. Um, and then we can decompose that and build. Right? So, we've talked about the first four steps of a process very generally, but hopefully this will get you started. [snorts] Um, and now let's talk about some tools to add some more color to all of these elements. Uh, show us how they're connected, how they work together to get the job done. So, how do we get from this messy pile? Oh, we've got this long list of functions. We know what the system needs to do. Oh, we've got this set of um elements and architecture um solution architecture, but how are they connected? So, I'm going to talk about some tools to help you straighten them out to untangle this mess. So, one of those tools, very simple generic tool, is called decomposition. So, you're basically decomposing a function into its lower level functions that kind of roll up to achieve that higher level function. And we can do the same thing with structure. We're decomposing our our subsystems to um describe, you know, the the sensing module, the computer out the software algorithm that needs to exist to be able to monitor and alert um the MS to the grid status. We're talking about sequence and logic. So, we can put those functions in order. What happens first? What happens next? What are the dependencies? where do we have choices to make about if we go and follow path one or make this decision to go down to path two and then context and interfaces. So every function operates in context. Every part of our system has something that it needs to consider when it executes and this is all a part of your what's called a system architecture which is in itself a very powerful tool. So decomposing functions uh this is I think intuitive enough maybe not for powering a city but um the concept is intuitive enough. So if this anything that's uh any of these rectangles that are green these are going to be functions. Any rectangles that are blue those are going to be structure the nouns in the system just for my color coding um guide here. So if we want to power a city, [clears throat] we take the functions that we derived from those use case analysis, right? Distribute power, monitor grid state, balance power load, and then we looked through all of our other use cases and we kind of grouped things into these five buckets for our tier one functions. So in order to distribute power, we need to capture the energy and transform it from energy into electrical power, right? So we need some other a couple of other functions that might not have been intuitive when we're going through our use case analysis or immediately derived from a use case and then we can decompose those and we can keep going further and further down um on each of these functions. So for example, if we were going to monitor the grid state, what are the sub functions that need to execute to kind of accomplish that goal of monitoring? So we need to detect anomalies and classify events, isolate um the damaged or vulnerable segment. And when you're decompos when you're creating a what's called a a functional hierarchy, we're just kind of putting them into kind of levels of importance or levels of um aggregation and then we can move on to define the order in which they execute. So I'm going to take the tier one functions, these top level functions, and I'm going to describe the order in which they operate. You can do that by obviously placing them spatially here in your architecture. Um, but there's going to be some more logic that you might want to describe. And so there's a tool called a functional flow block diagram. And you've seen these in various forms, right? Um, flowcharts or gant charts, things like that. So we begin on the left and immediately we have two paths. So two things are happening in parallel. We're going to start to capture energy and then at the bottom in parallel we're monitoring the grid state and we continue to do that as we transform the energy and then we have two other parallel functions distribute power and balance the load. So we can describe what happens first, second, third, what has to happen before another can based on inputs and outputs and the natural flow of exchanges and then we can add decision points as I mentioned. So this is called a functional flow block diagram and these are really powerful again to kind of work with your stakeholders. What do you what happens first logically and this might be really obvious you know in your high level functions but as you start getting down into the details these are really helpful when you're talking in cross-disciplinary design teams but also with your stakeholders because I can just slap this up here and maybe some of you already have opinions about whether this is accurate or not. Let's talk about it. Wait, why are those two in parallel? Don't we distribute power, balance the load, and then circle back and check. Isn't this actually a loop? Why do you say that? Let's talk about it. What are you thinking about? Let's communicate. Let's participate in the design process instead of me saying this is what it looks like. We good? Okay. [clears throat] And then we can take each of those functions and we can analyze the operating context. So, I'm going to introduce another tool, and I'm going to use an acronym a lot, but I'll try not to. This is called an IPO or an input process output diagram. It's also called a context diagram, which is much more um intuitive. And so, what you do is here is at the center you identify a process or I'm going to call them functions or set of functions. And just like in math, right, a function, it takes some input and it transforms it into an output. Right? So that output is different than the input. It might be the same thing but translated or moved somewhere else or it could take an entirely different form. [clears throat] So we identify a function first. We identify what are what outputs it produces. So this is everything we're asking the function to do or the system to do, but it's also everything else that comes along with it. So if we operate a power plant, we want to provide electrical power, but what else happens? We get emissions and particulate, right? In today's systems, right? What could we do better, right? So we want to identify all of the outputs that come from this system or this set of functions that are executing. And then we work our way backwards and we identify the inputs. So if we're going to say what we're going to do what we're going to say, what do we need to supply to that function or to that part of the system so it can accomplish that produce that output? So these are going to be data, matter, energy that are passed into the system or that the system has to go out and sense and and and retrieve and then that's what's acted on by this the the system. And then we can think about context. So we can identify what are called controls. And this is basically anything that could inhibit our system from performing this function could impact its performance or its ability to produce a high quality output. Okay. So these are independent variables. These are risks. And then we can think about enablers kind of countering [clears throat] the controls. What helps us what helps the function or the system produce those outputs? So to give you kind of a simple example, here's an input process output diagram for taking a hike. Right? So if I want my body to perform this function, take a hike, what do I need? I need some energy. I need motivation. I need a command signal to get me out to go, right? And then what do I get? Bliss out hiker, maybe serotonin, um, sweat, metabolic waste, body heat. So, all the things I wanted. I wanted to just clear my mind and get some exercise, but I also sweat and I'm also very hot if I just did it right now. And then we think about all the things that could complicate my hike, make it a little more challenging. the terrain, the weather, the humidity, the altitude, my fitness level. Maybe I'm someone that can't leave home without a cell phone or I need it to navigate um find the trail. So, these are all the things that are we can't get around them. They exist, right? You've heard that saying like you can't change the weather or the humidity, deal with it, right? So, we can't change these things. We have to deal with them. But we can design our the awareness of those things can help us to design our systems better. And then the enablers, what's going to help get me out there and pass through this um tricky terrain in inclement weather. So another example here is for our power system. So if we take that function monitor grid state, what do we want it to produce? We want it to provide some real-time updates on the status of the grid. Uh maybe some historical operational reports. We want it to alert us to some potential threats. And then there also going to be some energy losses or heat from it just using electricity to with all the um sensors and processors. And this is just a subset. You can see I'm quickly running out of room here. Uh but then we work backwards and think about okay so if we're going to provide these grid status and and thread alerts, what do we need? Well, we need to understand something about the power demand. So, we need to capture that data so we can run these algorithms, check whether it's operating anomaly or starting to get out into the um the danger zone. We also need to go out and capture some environmental data, right? What's the temperature, the humidity, what are the winds like? What's the wind velocity for those wind turbines? Turn them on or off? Or what are some of these threats that could uh impair or damage our system? and we identify our threats up and then controls. So the distance between the power station, the inner source, the data network reliability. So our ability to make capture good data and make sense of it might be impeded by some of these controls. Obviously the weather hazards and the topography, the accuracy of the alert thresholds, we talked about that a little bit yesterday. Where do we set those thresholds? That's the hardest part, right? And so if we can just recognize that we might not always get it right or we might have to change it and update it as we glean more information. I'm going to design that part of my system to be a little bit more modular so I can change that and then my system can respond to those differences in those thresholds. And so this is um another example of why you want as many people in the room as you can. I came up with this list. I ran out of room, but there are a lot more that I could think of. And I'm sure as you guys are sitting there looking, you're like, you miss this and this and this and this and this. Or we can get more detailed as well. Some of these are stated very generically. As we decompose this function monitor grid state, we can repeat this. We can create an IPO for the lower level functions and then we can get a lot more detailed about some of those hazards or risks um that we might need to be aware of as well as all of the other content we get more detailed. So this is a nice little kind of modular tool that you can use to analyze any function at any level in your system hierarchy. You can do it once and I love these when you're working with teams. Um especially if you're trying to have conversations about why the budget is we're asking for more project budget, why the timeline's been delayed. Well, sensor accuracy. We cannot measure solar radiance, you know, as accurate as we thought or you know what have you, right? And you can add a lot more qu uh quantification qualification any of these to help you with that conversation. And then of course we have our enablers. And so these are like enabling technologies that you may not have made decisions about. They may not exist in your system currently and you might never add them. But it's something to think about that might help you to counter some of those risks, those controls. So you often find yourself kind of oscillating back and forth between controls and enablers. As soon as you identify a risk, okay, we have something that can counter that, right? But then there's going to be some aspect of quality and reliability to that technical solution that okay, now I got to add that back up to the controls. [clears throat] So it's very iterative. We can create these for any level of any function in our in our system hierarchy. And we can take that sequence diagram, that functional flow diagram that I had drawn earlier, and we can overlay this information on each function. And we can check to make sure the sequence, the order of operations that we decided on is accurate based on what outputs the function before it produces it. Does it produce what that downstream function needs to operate or do we have to provide it from some other function operating in parallel? So this is called something if you're interested this is called an ID def0 zero. There are different layers and and an integrated definition model. But level zero is this functional model where we can show the sequence the order of operations and some of that decision logic. And then we can also show the inputs to each function, the outputs of each function where they flow between functions and then we can layer on the controls and enablers or mechanisms they're called in certain spaces. But these get really busy really fast obviously. You can um see why. Um but [clears throat] it's really I love thinking about like IPOs as just little Legos and then we can connect them together, string them together, order of operations, and they're all bundled nicely together with all of that information. And so then I can go to my spreadsheet or my software that's has all of that and think deeply about that particular function in its context. All these lines connecting them. These are flows, relationships between the functions. All right. So, put together these these tools, decomposition, sequence and logic, context, and interfaces. These are creating what's called a system architecture, a representation of your system that you can now point to, discuss with your team, your decision makers, and arrange as you need to as you glean more information, as you learn more about your system. And and these can be these kind of exercises can be performed in any order. And the reality is is you'll have to kind of go back and rearrange and revisit as you learn something more in your IPO uh input process output diagram. Um but we're just kind of putting things in buckets, right? As promised. That's all it is, right? But the real work is gaining agreement with your team about how to name something. That's often kind of I think that isn't a skill. It's an art. If you ever meet a talented system architect, I just I carry a thesaurus around with me if we're trying to describe like a function. All right, what really kind of encompasses what's going on here? Because we haven't decomposed it or we haven't made decisions or there's not enough space to list everything else that's going on. So, what's that verb that I can pick that just really everyone gets what I mean, you know? So, naming things and this concept of it's called abstraction is a really important skill. So your archite your system architecture this as I mentioned is a tool in and of itself and it comprises all of those elements that I talked about before the hierarchy of your system the flow um and behavior of your system and the context but your system architecture it's it's a your conceptual design um it's a model right so until we formalize them using some software or a PowerPoint flow diagram Um, until then they were all just mental models, right? It was what I was holding in my head and and using to make sense of when we're in engaging in this conversation about what the system needs to look like. And every disciplinary group that you work with develops its own models, its own data sets, its own terminology and priorities. And so until I take a look at your mental model, we're never sure we're talking about the same concept of a system. You can't be sure, right? And so this creates what's what we call a map of your the entire enterprise and you can use that road map to move forward to design or to understand your system and you're going to be updating it and evolving it as you learn more. So your system architecture is a really important tool to communicate with teams. Um so as I mentioned we're dealing with really complex phenomena. So to be able to visualize it, see my mental model, compare it with your own, point out why you see it differently, and then we merge our models into that system architecture. Go out and talk with stakeholders. Does this jive with what you're thinking, what you're looking for? Um, I think that's the most undervalued, underquantified um um reason to use a system architecture to build a system architecture for complex systems. because we're trying to visualize this complex phenomena phenomenon and we're trying we're dealing with uh stakeholders from different disciplines on our team right I'm often talking with electrical and engineers and no offense but suda I do not understand but you know if we're talking abstracting out these functions and the structure okay I don't know what some of these you know schematics are that you're talking about but I trust that they perform this function right and I see its role and I see the data that it produces and I'm going to use it in this other part of the system and in your domain it's going to improve integration across institutions right so client science science it's inherently uh distributed right your data is coming from all of these different um locales and different instrumentation uh each organization just owns a different part of the system or their subject matter um priority or their research focus right you could build a system architecture of that research environment. You can build a system architecture of your organization and how it interacts with other research organizations and researchers and you can think about the stakeholders involved. So when you're producing data and results, who else is going to read this? Who are the stakeholders in your research ecosystem? What's the format of that data? What's the application? What's the context? thinking about those stakeholders in your system and think about just building out kind of constructing just a quick little uh decomposition hierarchy of that um that institution and what the functions are between each of those elements. System architecture is a blueprint of your system. You're creating [clears throat] what we call in systems engineering a digital twin. And so we can create this system functional hierarchy as I mentioned a structural hierarchy but we can also connect them and it's key to connect them right so on the left we're describing things independently of the structure that performs them and we're doing that for a reason once you've developed that functional architecture what is the system doing for what purpose does it exist it rarely changes is right. The performance attributes of some of those functions might change over time. We want it to do it faster and more accurately, but that rarely changes. While your system form, the structural elements, the species in the ecosystem that perform a function, those are going to change. So, we want to keep them separately, but we want to relate them. And so, we do what's called allocating, or you could kind of assign functions to structure. So if I say my system needs to monitor itself, monitor the grid state, what in my system is responsible for that? I'm responding assigning accountability or responsibility. So that's going to be my fault protection sub subsystem. So you can draw an association. Now as I think about some of those lower level functions, if I want to detect anomalies, what in my system is responsible for that? my s environmental sensors, they need to sense the environment, bring that data into the decision- making. If I want to classify the event, that's going to be my fault detection algorithm. If I want to send an alert, that's going to be my alert module. So, we can connect the functional to the structural or the solution architecture. This allows you to identify alternative solutions, backup plans, replacements, upgrades for adaptability. Um, it also reveals gaps, vulnerabilities, redundancies, right? You should have a onetoone allocation. Every function should have one s subsystem or some element in the system that's responsible for it. You can design for two if it's for protection mechanisms. If subsystem A goes down, subsystem B can swing in and fill its place. But being aware of those redundancies or being aware of gaps. If you find some lonely function doesn't have a structural allocation. Who's doing it? How is it getting done? Is it essential to the system? You can ask that. Do we need to be doing that or what are we missing in our design? And then we can also use those allocations to understand the flows and interfaces into that part of that system. So we could take the inputs and outputs from a function and if I've allocated that function to the fault protection subsystem. I can just plug that subsystem right in. Okay. Okay. Now, what does that design need to look like to be able to monitor, receive the power demand data to monitor or go out and um capture the environmental data? What are the parts and components of that subsystem that need to exist to achieve this real time or achieve some of these outputs? And then where do they have to do it in the environment of what controls? And so then you can start to create what's called the form of your system. So down here we have our fault protect. I know I'm cordoned off here, but it's been so hard to like physically resue myself. So, the fault protection subsystem down there, it has a set of environmental sensors that receive wind velocity and some of these environmental data. Where do they where do they come from? It has to come from outside of the system. So, you can also model these other external systems and show these flows flows of data, matter, energy into your system, into a specific part of your system. And then we can see how it's transformed as they perform their assigned functions and then where that goes. So my fault protection subsystem then sends the grid status, operational alerts and thread alerts to my control and operations subsystem. And then in the end we're delivering electrical power to our city. So this is a very high level. It's called an internal block diagram. It describes the form, the interfaces and the flows between elements of a system. And you can do this for natural systems as well. I have an ecologist colleague I mentioned earlier and it's very challenging but we are bu trying to build a model a greater model of um a couple of different ecosystems and their part in a larger ecosystem some of our built systems. It's really fascinating and complicated and [laughter] um so this architecture highlights the dependencies and feedbacks um that helps inform and enhance system design as you move forward performing risk analyses. Um, so I have 15 minutes left, I think. Okay. So, I know you were really interested in talking about risk analyses and it seems super relevant. So, I'll try to kind of run through that, but I also want to leave time for questions. Um, so I apologize if this next portion is kind of hurried. Um, but I want to show you how that system architecture can be valuable. So, down here, we've talked about characterizing operating context. Now, we're going to talk about assessing risk. There are a number of different risk analysis tools out there. You've probably used some of these. One of them that I'm going to reference um because it's very familiar to me and um I'm familiar with how the architecture can um create these failure modes and effects analyses. Has anyone heard of an FMEA, a failure mode and effect analysis? You're basically looking at the components of your system and trying to figure out all the ways it can fail. um what in your design caused that failure? So the failure causes and what does that failure look like internal to the system, right? So if I'm designing two things to stick together and I choose an adhesive, a glue, okay, the failure mode is that if I chose the wrong adhesive, the failure mode is that that those two parts delaminate and then maybe something else falls apart, right? And the cause is incorrect selection selection of adhesive, right? And then the effects are kind of these broader effects. How does that impact the performance of the system itself or how does that impact the user or the stakeholder that we've designed this system for? So it's a really comprehensive analysis. And then you can talk rate things in terms of the severity of the failure, how the probability of detection or occurrence. Um very commonly used tool. Um and we can talk about the use of it in natural systems too or earth systems. Um so I've created a little IPO input process output um diagram for analyzing risk. So if if our task right now is to analyze the risk of our system what do we need to be able to do that? Well, we can take our stakeholder analysis, our use case analysis, and everything I've talked about so far, do that analysis, and we can understand or create a list of hazards, harms, failure effects, failure modes, causes, and then some mitigation opportunities. [clears throat] So, I've kind of laid out again using tools that I've talked about before. Sorry, this is really small on my screen. Um so the functions are in green here of our risk analysis process here. So we want to analyze the environment of use. We take our context diagrams, our IPOs. We look at those controls. What is that operating context? What are some of the risks? And that helps us to think about or list out at least hazards and harms and system failure effects. So you should have at least one hazard or I'm sorry one harm for each of those items in your set of controls. Then if we want to um analyze our use case scenarios, we take the stakeholders and use cases and we can understand the the effects that come as a a result of application. This is basically misuse conditions. So as a system, a human or a society or group of people interact with the system and use it, they're not always going to get it right. Right. They're going to misunderstand how they use it. They're going to be unskilled, untrained, what have you. How are all the ways that we the system can fail if it's operated incorrectly? Those are called application failures or use failures. And so we can determine the effects by analyzing our use cases. And then we look now we start moving into the system domain. What we can control up again. We can mitigate application failure effects by designing things into the system. take the human out of the loop in terms of certain decision making or add some automation. We've gone that way maybe too far in certain cases. So we can design system mitigations to counter application failure effects. That would be our um a goal. But then if we analyze the functions of our system, so we take that hierarchy, that functional hierarchy I talked about or any one of those flow diagrams that's listing our functions and we can take a look at any single fail uh function and if that fails to execute, what happens? And you want to do that for every single function in your system. If this doesn't execute, if it doesn't produce the inputs or do its job, what happens? Same thing with your system uh solution architecture. We can analyze the interfaces and the the design structure and understand those failure modes, right? Do we choose the right adhesive? Then what happens within the system or beyond the system if that fails? And then identify opportunities for mitigation. Look back at that architecture and try to understand how we can prevent it, get ahead of it, avoid those failures. And so going back to our use case analysis again, talking to those stakeholders, getting them in the room, getting them on the phone, building those relationships that you feel comfortable reaching back out to them over and over again. Okay, sorry to bug you, but what if this happened and this happened and this happened and this happened? What do we do? You know, what are your suggestions? What is your input? Building those channels of communication is really key. And then these last couple of slides are just included in case I didn't get to it. So it's kind of just a review of what I just talked about, right? So looking at your functional hierarchy and identifying um what happens in our system if this function fails to execute, if we can't detect the anomaly, our environmental sensors are not working, not capturing one of those data sets properly. What happens downstream based on that sequence diagram, that flow diagram that we created? What are kind of these cascading effects as a result of one of our functions not ex uh executing? And then for our structural architecture, what are the the modes and design flaws basically that we want to try to avoid or how can we mitigate some of these other risks that come about it from user application. Okay, now just one last one. [laughter] Um, so I don't have time to to go through this in too much detail, but I just wanted to again pop this up and kind of get you get you thinking. Um, this is what's called a state machine diagram. So you guys have probably heard about states. Every system or thing is exists in kind of a an operating state at a given time. Um, but it moves between states as conditions change, right? Is there are certain triggers triggering events. So sometimes we want our system to do that, sometimes we don't. Um, but here's a state machine for our power grid system. And on the left, we're describing the system operating nominally. So, we're generating power, we're distributing power. Yep, that's what we want. Um, in parallel, we're monitoring the grid status, right? Which in entails detecting and evaluating threats. And so, when we're what I'm telling you, um, as a as a group here is when I am designing this system, I want you to be assured that we are going to be monitoring threats. We're detecting and evaluating. And that happens when we're in the normal operating state day-to-day. If a an anomaly is detected and we confirm it's a threat, we move the system moves into a different state responding to the threat. So, it's doing something differently than it did when we were operating nominally and then we can describe um using other diagrams what happens. But we're going to avoid adaptability, these strategies of avoiding threats, absorbing the threats, and recovering from threats. We're going to model that, model our system after that to try to be adaptable. So, first we're going to try to avoid it, get ahead of it. But we may need to absorb it. We may may need to recover from it. And that [clears throat] recovering from threats, that's where the learning comes, right? What did we do wrong? What did we miss? So when the system's operating, how do we uh upgrade it, update it, improve it so that we can avoid it or absorb it um and avoid those threats in the future. Okay, so now I'm going to just kind of wrap up here. Um so just wanted to a couple of um as I mentioned a process a very generic process some very classic tools that you can just pick up and uh use to scrutinize any part of your system or all of your system um to help us move from these kind of unstructured um messy problems. Yeah. Uh and so in your space I think I just want to say that system architecture that might be a little unfamiliar because [clears throat] you're not focused on designing physical systems and most of us are never designing them from scratch. We never have that wonderful opportunity but you can apply these when you're um thinking about an existing system. So you're you're t we mentioned talking about uh or mentioned um modeling the enterprise right that you're operating in as you're doing your research. Um, but we could also use this to model the Earth's system, um, to kind of nail down some terms, develop a common language, um, and talk really deeply about how things work and why we have a profound amount of information available to us. So, systems thinking helps with sense making. Um, systems engineering helps with that synthesis. I hope hope you found some value in all that. >> Thank you so much, Alison. So, I think we have five minutes for Q&A. >> Yep. So, if there's any questions, I'll run the mic for you, Alison. Um, I was wondering how kind of thinking about systems or conceptualizing them differs between like humanmade systems where we kind of know a lot more about like the decisions that went into things and kind of like the relationships between the variables versus natural systems where maybe we like are relying more on observations or kind of are uncertain about those relationships. >> So, how does the model look differently or >> Yeah. or just kind of like how do you how do you how might you think about them differently? like you kind of mentioned this ecosystem project and like how how does that differ from like I don't know maybe more of the like engineering stuff you've done in the past. >> Yeah, I the key is about picking the the terms, right? How do you name a function? Um and there's value in kind of anthropomorphizing what the elements in the ecosystem are doing. Um but there's also value in switching them. So I really like thinking about what is an ecosystem doing um and and using uh let's see how do I describe this uh biomimicry it's it's creating bi biological analogies basically so it's really diving deep into that thesaurus to try to describe what's happening in that ecosystem so what is the service that's being provided and you definitely have to look broader in terms of that operating context to kind of nail that down because it isn't so visible you definitely have to kind of draw undraw boundaries to to isolate a certain segment. Um it's not easy, I'll be honest. Um yeah, it's it's basically um extracting function first, I think, is where you start. Um and then you can move on. you're you're kind of oscillating back and forth between structure and function because you could also place that natural system um in a context that we see in our human systems where I can identify all the pieces and parts and think about why they're there. Think about you can kind of work back and think about stakeholders and use cases, right? And apply that to your ecosystem. What is this system ben or what does a species benefit from being in this ecosystem? What functions does it perform? what benefits from it being there and what does why is it here? What's it trying to extract? And that helps you to kind of identify some of those functions. That helps. >> Thank you so much. >> Excuse me. [clears throat] Yeah. Thank you so much for this. I mean it's an in-depth you know information you've given and I was just following I was like wow I just need to stop writing just to to follow through. So yeah I I agree with some everything you've said and I have a lot of questions but I'll just just I have a lot of questions because this is what I do and this what I'm teaching this what I'm learning to do. >> Awesome. in the context of agroe but then I'm curious about two things when we think about the adaptive circle how can we design the the a system to be more adaptive and then adaptable >> right >> two question in one and then how can we use the feedback loop analysis to understand the system breakdown and then project [clears throat] it to guide against prop you know foreseeable breakdown in the future Yep. Yeah. I think designing our systems to our physical and built systems to adapt or to adhere to the adaptive cycle um on our terms. I I'm not sure that can happen. So, I don't know if anyone else you guys know about the adaptive cycle. It's um I don't know if I can Google it, but it's just it's this this kind of infinite figure eight loop that natural systems follow where they're conserving resources and kind of building themselves up then conserving resources and then there's some release. And so how do we design is that your question? How do we design our our systems to adhere to that? The release, right? [laughter] We build them up. We know how to conserve them sort of, but how do we accept the release or design it for an acceptable release that we can kind of live with those those impacts? Is that what you're >> Yeah. Yeah. I I think you know your your your response is part of it. But then we have the human factor the human factor engineering in the system within the system engineering. So when a system is designed to react to environmental impact automatically that is designing the system to be adaptive. >> Mhm. >> But then when a system is designed in such a way that we need an human human modification >> like this system I need to touch this laptop to to put it on. That means that this laptop has been designed to be adaptable. >> Mhm. [clears throat] So I can modify it from Microsoft Word to Excel, change it the way I want. That is an adaptable system. >> Yes. >> But then if it is designed in such a way that it will automatically move from Microsoft Word to Excel, from Excel to PowerPoint, that is an adaptive system. But then the complexity is how do we move away from adaptiveness to adaptability. That is the complexity. Mhm. >> And in a case where we have you know multiple stakeholders, Eric wants Microsoft Word. I want PowerPoint. >> Eric is not techsavvy. >> I'm not techsavvy but this person is techsavvy. So how do we prioritize the you know stakeholders needs in that complexity? >> Yes. Yeah. Yeah. I think that is the ultimate question. Um my short response would be modularity, right? Having very deep and broad conversations with your stakeholders to understand, okay, and and and narrowing it down to h, you know, percentiles, right? What percentage of people want to use PowerPoint? What percentage of, you know, it's like Samsung versus iPhone, right? Samsung phones, you can get in and you can modify and configure a lot. iPhone, you can't. Some people don't want to see all those menus and what have you, right? And so understanding those stakeholder needs is key, but I also think modularity, right? So I'm I'm designing if I design an iPhone to be in kind of easy mode, I have another software module, I swipe left and I can go into this kind of expert mode, right? If the user wants to be able to do some more advance, have some more advanced capabilities, right? But then it's the risk analysis, right? What if a a non-advanced user swipes that button, turns that button off, and now they break their phone, and we have to provide customer support, right? So, it's just it's risk analysis and trade-offs really. And then it's the decision makers. What are they willing to trade off? Um, and what are the risks? Are we talking about loss of human life? We have to prioritize that, [laughter] right? Versus, you know, inconvenience and maybe having to staff our customer service lines 24 hours with three extra people. Um, thank you so much for your talk. Um, I didn't really think about it like system engineering in this way, but you've given us like the tools and the processes. You've really broken it down. So, thank you for that. >> Um, so my question is do you have like any postimplementation strategies? Is that part of the system engineering process? So for instance like power a city right? So you have you go through all these steps um but like there's a timeline I'm thinking >> so after implementation are you still involved in this process is like how do you make sure that there's still this system engineering process is still ongoing and making sure that the plants that you've and like the things that you've put in there is still functioning in the long term. Yes. I don't know if that makes sense. >> Yes. Yeah. That's so important. Um we can't just design our systems, put them out there and forget about them. Um so that is addressed in this system and deployment in use and there's some um processes for monitoring that you can implement. Um but ultimately hopefully you've identified some of those things upstream right these use cases or functionality of the system. But for V1 version one I we can't do that. we have to you know that's that comes in our our second um derivative of this this platform basically but so how do we design our system to be modular to be able to implement that so spending as much time as you can upfront right have you guys heard that saying go slow to go fast couldn't apply more I just I wish I could live that mantra myself but that is so important studying those stakeholders and use cases triaging and prioritizing your functions and okay, this is what we're doing first. This is what we plan to do next. Now, we have to kind of throw it out there. And because there are so many other variables, you can't incorporate your test for, right? No matter how much work you do and how much time you spend there, you have to get something out there to learn. But again, modularity, it's a it's a discipline in of itself. And if you're interested, I can send you some resources. But designing for modularity so that you can upgrade or repair a part of the system that once you deployed you learned something or it failed in a way you weren't expecting. Um the the failure effects are minimized right because you considered it but then your your upgradability is also possible >> and I just wanted to add to that sometimes you even think about the retirement of your system. So, and that's what uh Allison is saying to bringing all of that from the beginning so that as you're building it, you're already thinking, well, at the end of the life of this system, what's going to [clears throat] happen to it? Now, you might build it and give it away to someone else and whether they follow your plans, that's a whole other thing, but yeah, it is usually included. >> Um, I think that's all the time we had, right? Yeah. Thank you again, Alex. [music] >> [music]