Session 4: System Architecture and Concept Generation

• Download English-US transcript (PDF)

The following content is provided under a Creative Commons license. Your support will help MIT OpenCourseWare continue to offer high-quality educational resources for free. To make a donation or to view additional materials from hundreds of MIT courses, visit MIT OpenCourseWare at ocw.mit.edu.

OLIVIER DE WECK: All right. So let's see. Mr. Sticky. Let's see, EPFL. Who picked Mr. Sticky? Anybody?

AUDIENCE: Yeah. So the definition is a cylindrical container containing a date covered with a [? basic ?] substance that can be deployed in order to attract and capture insects.

OLIVIER DE WECK: Good. I'm glad you added the last part because I was worried that you weren't going to talk about the function. So it's good. I think it's good. You started describing the form, and then you explained what the function is at the end. So that's good.

Anybody else do Mr. Sticky here? Yeah. Do you want to share?

AUDIENCE: So we said it was a portable canister deployable, fly-attracting sticky tape, fly-catching mechanism.

OLIVIER DE WECK: All right. Yeah, I think you've got the right elements. I think it needs to flow a little better, but you've got the right ingredients there. What about the i3. Anybody? Yeah, go ahead. Justice.

AUDIENCE: You said it was an efficiency and urban-optimized transport vehicle made by BMW.

OLIVIER DE WECK: Say that again?

AUDIENCE: Can you turn on the mic, please?

AUDIENCE: Does yours work?

OLIVIER DE WECK: Do it again.

AUDIENCE: We said it was an efficiency and urban-optimized transport vehicle made by BMW.

OLIVIER DE WECK: Urban-optimized transport vehicle. I think it's good. I think you're missing the effect that it's an all-electric, the fact that it's fundamentally an electric vehicle. I think it's key to the i3. Because you have you have other urban-- like the smart car. And so architecturally, distinguishing feature is definitely the electric drive. So I think it's good, but I think you're just missing a little bit on the technology there.

What about i3 and EPFL? Anybody do the i3?

AUDIENCE: Nobody.

OLIVIER DE WECK: Nobody. Anybody else here? Yeah, Veronica.

AUDIENCE: Thank you. Sorry. A transportation system responsible for moving people and products with an enclosed metal frame equipped with various safety devices using electrically-powered control and locomotion subsystems.

OLIVIER DE WECK: OK. That's pretty good. There's a lot there. I would throw a question. A concept you defined could almost apply to a Tramway as well. If this was like a streetcar, don't you think it would apply to that as well?

So I think the fact that it's a personal vehicle, I think it's important. So the key in this is, describe the concept using few words precisely, but to set it apart from neighboring concepts. What about Rolex Center?

AUDIENCE: Yeah. It's a single-layer building with multiple straw used as a library for people to meet and study.

OLIVIER DE WECK: A single-story building using multiple--

AUDIENCE: --floors.

OLIVIER DE WECK: Floors. Oh, yeah. So that's right.

AUDIENCE: You have one layer. However, it has this wave shape and therefore, you have something akin to two floors. So the library is one something like the upper floor and the meeting areas, the noisy areas on the lower floors. So you can connect both, but the noise doesn't connect that easily.

OLIVIER DE WECK: Yeah. No, that's very good, and I think that's the architectural. And then the library is there. That's for sure? But isn't there a lot of other things or services provided in that building beyond the library?

AUDIENCE: Yeah, you have a bank, a cafeteria, student services. But you could encompass it in a meeting area. You meet and you do some stuff like eating, going to the bank.

OLIVIER DE WECK: Right.

AUDIENCE: I think we missed some functions.

OLIVIER DE WECK: Yeah. So I like your definition, but I think by pointing out the library, you're missing the other functions. And my understanding is that the reason this was built was to put two things. One, is it's a focal point for the community at EPFL. We have a student center here at MIT. People go there to do their banking, their eating, their meeting, and so forth.

So in that sense, it's pretty similar, but I think the Rolex Center is such an iconic building that it also serve a kind of a prestige function, to put the institution on the map in terms of it's a statement. It's not just a utilitarian building. Whereas, I would argue our MIT student center, it has very similar functions to the Rolex Center, but I wouldn't call it an iconic building. It doesn't have that wow factor. Would you guys agree with that? Yeah.

Maybe it did when it was initially built. I'm not sure, but very good. So we could spend a lot of time on these, but really crisply refining and thinking about the concept is very, very important

So let me very quickly go through the refrigerator case study to show how do we transition from concept to design. So the first thing you do is understand where is the value-- the stakeholders and the stakeholder analysis and the requirements definition. And so in order to do that, you ask the question, first of all, value identification. Where is the value?

And so you understand that then who is the beneficiary? That's a stakeholder. The stakeholder has needs. I'm using OPM here to describe this. And then this is a funny thing here. The needs have these little bumps. This is meant to indicate a cloud. This is not standard OPM nomenclature. Just point that out.

So this means that the needs are somewhat vaporous. They're not very well defined. And then you interpret and incorporate some of the needs into goals, which become requirements. And so the goals then are an instrument of the primary delivery value delivering process, which is your value proposition.

To then actually deliver that value you need to design the product, the product system, the product object, and understand the operand, the thing that is being operated on or transformed by the primary value delivery process. That's a very abstract, high-level way to think about where's the value in the system.

But fundamentally, this is part of the reducing ambiguity work that you do as a system architect, as a system engineer. And there is a recipe for doing this. So first you start examining the operand associated with value. What's really the thing that generates the value that the user, the beneficiaries care about.

Next you say, this is the attribute link. What attributes of the upper are changing or being affected associated with value? And so the attribute-transforming process is where the value is generated.

So for food, I think we briefly talked about this before. Usually people will say, when you think about a refrigerator, keep the food cold. But if you step back and think about it in a more abstract way, it's really about preserving food or reducing the spoilage rate of the food. So the refrigerator effectively becomes a food spoilage rate reduction device. and I know that sounds terrible, but that is really what it's about.

So when once you think that way, you can really start being creative and focus your creativity. So here we have the food, and our goal is to reduce its spoilage rate. And then you can ask, well, how can we do this? What are all the different ways of reducing the spoilage rate of the food?

So from among the system operating processes, we then specialize and pick a particular one for our concept. So beside chilling or keeping the food cold, we could irradiate the food. We could we dry the food. What are some other ways that we can reduce the spoilage rate? So irradiating, drying, chilling. Sam?

AUDIENCE: Preserving.

OLIVIER DE WECK: Preserving. So you add chemicals essentially. EPFL, how else can we do it? Spoilage rate reduction?

AUDIENCE: Using chemicals?

OLIVIER DE WECK: Yeah. So that's chemical. That's right. What else? Keep going. Because food is pretty essential for humans, this is actually one of the areas where humans have been very creative. There's a lot of ways to do this. So keep going.

AUDIENCE: Yeah, for example, for conserving grapes, maybe you do wine, which is a process to conserve this wonderful [INAUDIBLE].

OLIVIER DE WECK: Yeah. Please keep some wine for us too, please.

AUDIENCE: Beer is the same.

OLIVIER DE WECK: Yeah. So marinating it, vacuum packing, smoking, on and on and on. My favorite is actually eating it. What do bears do? How do bears conserve food?

AUDIENCE: Fat.

OLIVIER DE WECK: Fat. Right? So bears, they actually consume it and then transform it into fat, into a different storage form, store it inside their bodies, and then as they hibernate, that energy, that food is being gradually consumed. That's a very different way, but it's essentially the same function.

So that's the key idea is start thinking in this abstract way, and all of a sudden all these other possibilities become possible. And that's really the cool part about design and creativity. But eventually, you have to pick a particular concept.

So the chilling part is not enough. That's the function. And then you say, well, we need a chiller. In order to chill, we need a chiller, and there are different types of chillers, like a cooler or refrigerator. And it's the combination of this specific way you're going to operate the system. The element of form and then the specialized element of form, in this case the cooler, that combination is what we call concept.

So once we have that, we can start managing complexity, decomposing function and form, so our system operating process gets decomposed into the primary supporting processes like interfacing, powering, controlling. And then our system object, you can decompose it into different elements, supporting systems, the operand, the operator, and so forth. And then we can start connecting them.

So let's look at for chilling the food, let's look at a cooler and a refrigerator in terms of this decomposition. So here's a picture of a very simple cooler that you would take out on a picnic. It has the chilling function, and then the sub-functions when we zoom in are holding the food, exchanging the heat between the food and the environment, reducing the heat load, interfacing, connecting, powering, regulating the temperature, et cetera.

And then on the form side, the cooler itself is very simple structurally. It just has a bottom, a box with a bottom and a top. And then we have the ice, the food supporting the surface, the external heat load, ambient light, and the operator.

What's surprising here is when you map the two, there's a surprising amount of complexity. It's not a very clear one-to-one mapping. Let's just look at the ice. So here's the ice, and you can just follow these links to see what functions, sub-functions does the ice support-- exchanging heat, powering, and regulating temperature. So exchanging heat means, essentially, the ice itself acts as a heat exchanger. Just the surface of the ice is where the heat exchange happens.

So what forms can you put ice into a cooler? What are the different shapes of ice that you could put into a cooler?

AUDIENCE: Like an ice pack.

OLIVIER DE WECK: You could put ice pack or you could put a block or chips. And if you put the same quantity of ice, but you put a block of ice, you put little chips, what will be the difference? Will there be a difference? Surface area, right?

So the speed at which the ice will melt for the same given external temperature is going to be different. So there's an attribute of the ice, which is essentially its quantity, but also it's form that will influence the-- but that's the heat exchanger function.

The powering function is pretty clear. That's essentially the energy storage right there. And then the third one is regulation. How does that work? How does the ice provide a thermal regulation in the cooler? Physics 101. Yeah? Go ahead.

AUDIENCE: [INAUDIBLE]

OLIVIER DE WECK: Right. So as long as you have any ice left in the cooler, what will be the temperature inside? Not opening and closing, but if you keep it closed, what will be the temperature in the cooler?

AUDIENCE: 0 Celsius.

OLIVIER DE WECK: 0 Celsius. As long as you have ice left, this is the phase transformation, you're at that point. As soon as the ice is all melting, the temperature will rise. So the phase transformation of the ice from solid to liquid is what, in fact, is the regulation mechanism inside the cooler. So even though you think of a cooler as being something super simple and trivial, once you start listing its internal functions and how the top, the bottom the ice itself, how they interact and support those functions, it's pretty complex. And you can go very detailed here, even for something very simple like a cooler.

One question and then we'll talk about the refrigerator and how it's different in a minute. One question I often get is what's the difference between system architecting and system design? Isn't that the same thing? And I think they're somewhat different. They're overlapping, but there's a distinction.

So architecture selects the concept, the decomposition, mapping of function to form. And architecture essentially establishes the vector of design variables. What are the key design variables and operating parameters of the system? Design, then, given that, selects the actual values for those design variables, and then you can optimize.

So if we look at the example of the cooler here, we have our cooler with the box in the bottom and then the ice, and we can decompose the attributes of that. So the box with bottom has length with height. It has a wall thickness. It has a type of material. The top has thickness and material, and the ice, like we just talked about, has quantity, surface area, and maybe initial water content. And those are the operating parameters, and on the upper right, those are the design variables.

So when you are making a material choice, we're going to use PVC. We're going to have a 2.1-inch thick wall. We're going to use this much insulation. This will be the aspect ratio of the cooler. It's going to have wheels maybe, so we can pull it easily. Those are essentially design decisions. You're instantiating that concept.

But the fact that it has a bottom and a top and it's hinged and it uses this phase transition as the regulation mechanism, that's conceptual design. That's system architecture, and you need to do both. But they're not quite the same. Is that pretty clear? That's a very important distinction.

So let's look at the form function mapping for refrigerators. So this is actually a big difference between the US and Switzerland. People in the US, we like to have big refrigerators, big gallon of milk, and refrigerators in Switzerland are much smaller. I'm not sure why. Maybe you go shopping more often, but it's definitely one of the big differences.

But here we have essentially the decomposition of the refrigerator. So we have racks. We have the air. We have-- I guess freon is banned now, so we should use some other. This is a refrigerant, a working fluid, the insulation, the feet and rollers, the frame, the electric motor, sensors, controller doors, lights. And then we have those functions, essentially, the same functions we had for the cooler, holding the food, exchanging the heat, powering, regulating. But the difference is that we have much more of a one-to-one mapping. So in the refrigerator, each of these elements supports, essentially, one of the primary sub-functions.

So the form function mapping in the refrigerator is actually much simpler. It's a much simpler form function mapping than the cooler. And you say, well, I thought a refrigerator is much more complex. How can that be? Well, the real complexity comes in when you look at the form form mapping. So this is then the decomposition of the refrigerator in terms of all the elements of form and then how they relate to each other.

And I'm not showing here all the sub-processes, but you can see that the mapping and the relationships are much more complex than in the case of the cooler. So to wrap up on this piece, when we do a conceptual design or system architecture, you have two major activities. One is concept generation. So take the requirements and think creatively about how these requirements could be fulfilled.

So that means understanding the operand, the attribute of the operand that you're trying to affect-- it could be multiple here-- the intent attribute-- this means the required, desired state-- what is the system operating process, and what is your major element of form. So that's generating this and specializing that. That's concept generation, finding systems that do the right thing. And then once you have several concepts, you've got to select among them, which we'll talk about next week. That's our topic next week is concept selection.

So finding systems that do the right thing and do it well, deliver value, and comply with regulations, standards, and so forth. So there's going to be consumables involved, side effects, like noise, waste heat, pollution. The operator, how skilled does the operator has to be or how autonomous is the system. What is the reliability, safety, cost, the quantity. All those things are describing the concept and its instantiation in more detail and will help you do concept selection.

Do you do you see the difference? Concept generation is take the requirements and come up with the fundamental form function mapping of how the requirements can be met. Then you instantiate that in terms of designs and then you can evaluate those and compare concepts using other criteria like consumables, quantity, how skilled does the operator have to be, et cetera. So those are fundamentally different activities.

So let me summarize on system architecture and then talk about the NASA approach and then creativity. So architecture requires consideration of both function and form related through concept. It's about starting with the operand. What is the thing that the beneficiary, the stakeholder cares about, and how do we transform that?

Concept then elaborate these into architectures that have form function and structural complexity. And then the goodness of an architecture is really a pretty complex concept where we have multiple objectives to satisfy, including performance, resource utilization, cost, operability, safety, capacity, and so forth. And we'll defer that to next week.

So let me briefly talk about the NASA approach to this and then talk about some methods and tools for concept generation. So the NASA approach is basically described in the system engineering handbook in the SE engine as step 3 called logical decomposition. And so the logical decomposition process, as described in the NASA standard, is used to improve the understanding of the technical requirements and the relationship among those, transforming that initial set of requirements into a decomposition.

So the idea that we need to partition the system and then derive lower-level technical requirements based on that lower-level definition, and that's what's called architecting. Getting back to our high-level system design process, this is, again, that diagram that we've looked at several times already. You can see the red box is where this happened.

So we started with mission authority, stakeholder expectation, and then defining those high-level requirements. Level 0, level 1 requirements, but then you get stuck. You get stuck because you have to make some decisions before you can go to lower level requirements definition. And that's what's known here as functional and logical decomposition.

Once you've decided on a composition and you can carry several compositions with you for a while, then you can do the lower-level trade studies, derive and allocate lower-level requirements refine your CONOPS, and so forth. And then do functional and performance analysis to see whether you have enough detail. Is it workable? Is it safe? Is it reliable?

And if yes, then you can select that as a baseline, if not, you might have to go back to the red box, which means that architecture didn't work. We have to look for a different decomposition or different architecture. And if that doesn't work after multiple iterations here, you might have to go back and change the requirements, because you come to the conclusion that the requirements are not really achievable.

So some examples here of decomposition models, here's a timing diagram. On the right side, you have a state diagram, the different states that the system can be in. So you can see this relates very strongly to the system modeling languages that we talked about. So you use the system modeling languages to decompose and define the system in more detail.

And we really talked about much of this already. And in terms of the logical decomposition flow diagram, you start with your basic high-level requirements and measures of performance. You essentially do your decomposition. And then on the right side, you come out with the lower-level derived technical requirements, logical decomposition models, which would be essentially a description of your different subsystems and the logical decomposition work products, which are essentially lower-level definitions of what these subsystems look like. And then you can go off and do the detailed design and then the testing verification and so forth. So it's essentially focused on decomposition, which is an important part of architecting, but it's not the only thing you do.

So let me talk about methods and tools for concept generation. So I'm going to start with this. This is another really fun thing we do in the system design and management program, which is a full-year program, is the we call it the creativity workshop. So what are different ways of stimulating or organizing creativity.

And what I'm showing you here is-- that's essentially a mind map of how to think about the creativity space. So I'll briefly go through this, and then we'll look at a couple of examples. So one idea is that creativity is better if it's a group process, that people stimulate each other. And so this whole group up there is called group dynamics. These are all different methods for stimulating creativity using groups of people.

And some of these are authors that have written and methods, so de Bono, Six Hats, powwows, mind boggling, workouts, creativity workouts, these are all different variations of group dynamic processes. The one that I'll talk about in some more detail is brainstorming. This is probably the best known. What's not so much known about brainstorming is that there's a right way to do it.

On the upper right branch, creativity and system architecture, this is just describing the importance of it, the three themes we talked about-- creativity, ambiguity, complexity, different types of innovation, radical innovation, modular, or incremental innovation, and so forth, and the high leverage that it has.

The next branch are called models of creativity. What that essentially means, and I'll give you one example here, which is Leonardo da Vinci, is understanding people that universally are claimed as having been very creative thinkers. Why were they creative? What was their recipe for success?

Below that, we have structured processes, which are essentially trying to organize the creativity, which seems like an oxymoron, but there are actually ways to have a structured process to stimulate concept generation. And we'll talk about very briefly mind mapping and then morphological matrices. And then we have this whole area here, which I'm going to mention, but we're not going to do as part of the class, which is stimulants. So this is the idea that somehow people are more creative when their brain, when you put yourself into some other state.

So bio-inspired design would be you go in nature, or you read books about seashells and animals and you really try to understand from nature-- and bio-inspired design is a very important field of research now. It's pretty serious. So you put yourself in nature and be inspired by what you see.

Random inputs, provocations, challenges, and then things like alcohol, and even drugs. So a lot of the music that was done in the hippie age in the '60s, I mean, a lot of these artists were consuming large amounts of drugs and alcohol. And there's a big discussion on is this fundamentally why they were creative. So I'm not advocating that. I'm just I'm just telling you that there is this idea that you can stimulate creativity in these different ways.

So let's talk about mind mapping. So this is an example of a mind map that I really liked. This is from several years ago. This is from a student that took the system architecture class. And so the idea of a mind map is that you look inside yourself and you try to put down on a map different ideas and concepts. So in the core of it, you have the key focal point of the mind map. In this case, it's system architecture, and then you have these branches coming off.

So the class itself, the skills, the concepts, the themes, and then it almost looks like a neural network. You branch off into the sub ideas and sub concept. And in order to really make it memorable, you draw it by hand even though there is software for doing this. But I really like this, drawing it by hand the old style. And then you add icons and symbols and colors to really make this sticky and memorable.

So you can look at that. I really like this example. And it probably takes a couple of hours to do a really good mind map like this. But the idea is that by doing this, you're going to develop your ideas and concepts. And there's books about mind mapping. I mean, it's a whole industry almost.

Brainstorming. So by the way, who has done brainstorming and organized brainstorming? Who's been part of a brainstorming exercise? Do you want to describe it, how that worked? Make sure you use the mic.

AUDIENCE: So we started with our problem, and if I remember it right, it was to redesign a coffee mug.

OLIVIER DE WECK: This was for a class?

AUDIENCE: Yes. And then basically, for the first part, any idea could go. And the only role was you couldn't criticize anyone else's idea. So he basically tried to come up with as much as we could, wrote as much as we could on the board, things along those lines.

And then once we had all of our ideas down and some people built off of other ones and then it was oh, but we can also add this. And then we started to look at well, we can't really believe that. This is going to be way too expensive and started down selecting from there.

OLIVIER DE WECK: Did you take a break between the two parts?

AUDIENCE: Yeah.

OLIVIER DE WECK: So yeah, you described it very well. So the key idea is there's some rules for how to properly do brainstorming, and some of them are listed here. And then I have another on the next chart, there's sort of a step by step.

So it's really try to remove creativity barriers, stimulate each other. There's an ideal group size, and it says 5 to 10 here, but I should probably revise this to be-- what do you think? 7 plus minus 2. If you try to do brainstorming session with 30 people in the room, it's too big. It's not going to be that productive.

So use of intuition, associations. What's important is that you have a clear idea of why you're doing the brainstorming session. So there's some solution neutral question, like how can we improve a coffee mug. What did you come up with, by the way, at the end? Did you have a result?

AUDIENCE: I think it was we were going to redesign the handle so it would be more ergonomic. But, yeah.

OLIVIER DE WECK: So what can be done too, how can we improve. There's got to be a driving question for the brainstorming session. Actually, the first time this was described was by AF Osborn in this book in 1957.

There's why is brainstorming useful. We can talk about that. A lot of it has to do with this group dynamics. How to organize and host a brainstorming session. I'll talk about that next.

And then there's this killer sentences you should never say during a brainstorming. Some of these are pretty funny. And then what do you do with the results. How do you actually then take the brainstorming results and use them for further refining or down-selecting concepts.

So here's a six-step process for doing a brainstorming session. So you send out invitations a few days ahead of time. And the idea is that people can think about this question so that when they come to the brainstorming session, their brain is preloaded with ideas. That's the idea. You don't just pull people in like five minutes earlier.

The idea is give a few days, not weeks, but a few days of warning so that people can think about this and come to the brainstorming session ready and charged to share their ideas. 7 plus or minus 2 participants. There should be a facilitator. This is somebody who is helping to moderate.

Participants take turns expressing thoughts, suggestions, ideas. You should take notes. So for example, these big whiteboards are great for that, with idea paint, the whole wall. That's great. Or you can do flip charts. You can do different ways of capturing these ideas.

And then I think you mentioned this. It's called the principle of delayed judgment. So you're not allowed to criticize or particularly praise. So you could, for example say, oh, this is the best idea we've had so far in this session. Even though it's praise, it actually implicitly is criticism of the other ideas. So avoid that. Avoid the killer phrases. And then the idea there is produce a large amount and diversity of ideas.

And then at some point, maybe 30 to 60 minutes, you end. Brainstorming session that last four hours, the first hour is probably really good and then the second hour OK, and then the rest is everybody is kind of shot and, there's not a lot of new ideas coming.

Creativity killer sentences. I highlighted a few. This will never work. We don't even need to talk about this. Everybody does it this way.

I've already studied this problem for years. Don't worry, I know I'm right, and et cetera. How long have you been with this company? Anyway, so that's the idea.

All right Leonardo. Who's been to Italy or tour in France, or who's seen one of the exhibits know where his notebooks are on display?

AUDIENCE: [INAUDIBLE]

OLIVIER DE WECK: Yeah. What about EPFL? Have you guys seen these wandering exhibits about Leonardo's work and his notebooks? Anybody had a chance to see that? Go ahead.

AUDIENCE: Yeah. Actually, he do a lot of sketch, and he [INAUDIBLE] the fact that sketching is more important than writing.

OLIVIER DE WECK: Yeah. That's right. So really, he didn't build a lot of his ideas. So that's one of the-- did he actually then. But he was a head of his time in many ways. So he's really been identified as an exceptional individual.

So here's a book called How to Think Like Leonardo, Seven Steps to Genius. And I'm not a big fan of these popular books, but this one is pretty interesting because what's been extracted from this is the seven da Vincian principles of creativity. And they're here in Italian. I'm just going to go through them very quickly.

So curiosita, lifelong quest for learning. Dimostratzione, testing your knowledge through experience, trying things out. Sensazione, continual refinement of the senses. Sfumato, which is essentially also a style of painting, like the Mona Lisa is painted in sfumato style. Mastering ambiguity, paradox, uncertainty. Arte/Scienza is the whole brain thinking, left-right brain. Corporalita, balance of body and mind, so a healthy mind and a healthy body. And then connessione is interesting. That gets close to system architecture, which is the appreciation of patterns, relationships, connections, and systems.

So the idea is that, this from Leonardo, his work, his way of thinking, these seven principles have been extracted. And then you can say, well, which of these do I feel really resonate with me?

All right. So we have only a few minutes left. Let's move to some of the structured processes for creativity. So the first one I want to mention is this is probably the simplest and the one that's used the most. This is known as a morphological matrix.

So the idea there is that you try to define what are the key features, factors, or decisions that you have to make when you define a concept or an architecture. So the key decisions are the rows. Let's say there's n key decisions. There are factors in the rows. And then for each row you think about what are the number of possible alternatives for doing this.

And then you enumerate all possible combinations. So an example here would be here's our morphological matrix. And then one possible concept here would be A2, B1, C3. That's our concept here. And then you can see that for a full-factorial enumeration, you would have 27 architectures that you could generate.

So the number of architectures here is 27, based on this morphological matrix. And I find this to be very, very helpful. When the table gets too big, very quickly because of this being a product, this can really explode on you. It can be very large. And the big challenge with this, of course, is if you have many factors, you could generate many infeasible architectures. Not all these combinations are actually feasible.

So the question then is, how do you prevent that, and that's where so-called architecture enumeration comes in. And I'm not going to go in a lot of detail here. But the idea is that through creativity, expert knowledge, and analysis you're going to define your components, which are essentially the rows in the morphological matrix. But you're also going to establish rules that tell you which combinations are actually valid combinations and which ones are not.

And that, in fact, is [? Narek's ?] PhD topic is, how do you increase the number of physics-based rules rather than just empirical rules. Because if you think about it. If you apply rules that are just based on current practice, then you're just going to recreate concepts and architectures we already have. You won't really come up with something fundamentally new because you've constrained the combinations to what people do now.

So the real challenge here is, between generating all possible combinations, many of which are infeasible and only the ones that we currently have, there's a middle ground there. So that's architecture enumeration, and there's different ways of doing this at different layers of abstraction. So here's an example of airplanes, different configurations of airplanes.

If you think about the tail of airplanes, we have the traditional tail with a lower stabilizer. We have T tails. We have we have V tails. I mean, there's like 12 different tail geometries here. And you could think of this for the wings, for the fuselage, for the engine locations, very quickly, you can generate thousands or even millions of architectures. But at that higher abstraction layer, it's just a single tail.

So how do you combine these using compositional rules? That's architecture enumeration. So here's also an example from [? Narek's ?] work. So at an engine, a turbo prop engine at a high level of abstraction, that's basically a propeller, an intake, a core, and a core nozzle.

And then to break that concept in further detail, the core itself gets shown at a lower level of detail. And you can see that inside the core, you have, in this case, a single compressor, a burner, and then a turbine that drives the compressor.

And so one of the advances in engines has been from World War II to go from single-stage to two-stage, thee-stage engines, and so forth. So the complexity has been going up, but you can actually generate through architectural enumeration, essentially, all architectures that have been built and that are known and have been certified through a organized architecture enumeration process.

Some of this can be done in Excel, for example, where you essentially list your components. This is your library of components. And then on a different sheet, you define all the different rules that allow you to combine different number of instances of these components into architectures. And we'll post some information on this if you want to try this out for your concepts.

So let me summarize. So system architecture is definitely very abstract, but it's also, potentially, the most influential activity that we do in system architecting. The concept is mapping function to form. We typically, in the conceptual design, don't do all the details. We just go down two levels of abstraction. So not all the details are defined.

The NASA approach specify or is really focused on this idea of logical decomposition, which is very important, but it's not the only thing we do in system architecture. And then the really cool part, the exciting part in concept generation is the one that it's really a creative activity.

And when you look at the set of creativity techniques, you can think of group dynamics like the brainstorming. That's used very heavily, but you have to do it the right way. If you organize a brainstorming session, and there's some wiggle room, but if you violate some fundamental principles of brainstorming, you're not going to get the full benefit.

Models. So thinking about really creative individuals and what drove them, what were their principles, and try to emulate some of that. And then the structured processes, which include mind maps, morphological matrices, and then architecture enumeration.

So when you look at assignment A3, which is now out there, that's really what it is about, is you've done the stakeholder analysis and initial CONOPS, you have a requirements set. So now be unchained, and within the constraints that are set by the competition, come up with different concepts.

And in the homework, what I ask you to do in A3 is try out at least two different techniques, a structured one and an unstructured one and then compare the results. And this will be due in two weeks.

Free Downloads

Video

• iTunes U (MP4 - 101MB)
• Internet Archive (MP4 - 101MB)

Caption

• English-US (SRT)