Model-Based Exploration of System Architectures

Dr. Chris Paredis Associate Professor G. W. Woodruff School of Mechanical Engineering Georgia Tech

Due to rapid advances in mechatronic and networked, distributed systems, a braod range of competing system architectures is often available. From this broad range, systems designers need to select the most promising architectures for further exploration and refinement, but they are lacking the detailed knowledge and experience to guide them in this effort. In this presentation, we will explore a systematic, model-based approach towards the exploration of a space of system architectures. The approach builds on recent advances in Model-Based Systems Engineering (MBSE). Rather than capturing information and knowledge in unstructured text-based documents, as used to be common practice in traditional systems engineering approaches, MBSE advocates capturing knowledge in semantically rich, structured models. Support for MBSE is provided by the Systems Modeling Language (OMG SysML), which includes basic language constructs for semantically rich modeling of requirements, functions, logical and physical components, logical and physical behavior, etc. I will provide an overview of how SysML can be augmented with domain specific models to support the exploration of system architectures. Examples focus on the capture and use of synthesis and analysis knowledge for hydraulic systems design.

Dr. Paredis is an Associate Professor in the G.W. Woodruff School of Mechanical Engineering at Georgia Tech. He received his M.S. degree in Mechanical Engineering from the Catholic University of Leuven (Belgium) in 1988, and his M.S. and Ph.D. in Electrical and Computer Engineering from Carnegie Mellon University in 1990 and 1996, respectively. From 1996 to 2002, he was a Research Scientist at the Institute for Complex Engineered Systems at Carnegie Mellon University. Dr. Paredis has a broad, multidisciplinary background. In his research, he combines aspect of information and knowledge management, simulation, and systems theory in support of model-based systems engineering. He focuses in particular on decision making under uncertainty in conceptual design and on efficient exploration of systems architectures. In these areas, he has published more that 80 refereed journal articles and conference papers. Dr. Paredis received the 2007 CETL/BP Junior Faculty Teaching Excellence Award, the 2007 SAE Ralph R. Teetor Educational Award, and a Distinguished Visiting Fellowship from the British Royal Academy of Engineering to visit the University of Bath in 2009. In 2007-2009, he was the Chair of the ASME Computers and Information in Engineering (CIE) Division.

Systems Realization Laboratory Product and Systems Lifecycle Management Center

Without necessarily going in depth in one particular topic, in the hopes that we might use this as a starting point for further discussion, not necessarily today but in the future, and see if there are opportunities to collaborate. The title is "model-based exploration of system-architectures". There will be several projects in this talk, themes around this idea of how do we use modeling, not just simulation but formal modeling. How do we use these models to explore large spaces of systems architecture? This is closely related to systems engineering and engineering design. Not so much focused on the part level, or individual component level, but how do we architect and build large systems. Aircraft, cars, spacecraft. How do we think about the definition of such systems?

The example I will use is that of a hydraulic system. This is a relatively simple problem. Consider an excavator. We're only going to focus on the hydraulic. We'll assume the mechanical structure to be fixed. From a systems perspective, how are we going to connect the prime mover, the "diesel engine" that is most likely going to drive this engine; how do we connect this diesel engine to all of the hydraulics of the excavator. We have an engine, hydraulic components, how do we combine all of these with a system architecture with good tradeoffs that we care about? Cost, performance, efficiency. How do we stsructure this system. This is what we mean by defining the system architecture. It is not an easy problem.

There are many competing objectives involved. Cost, performance, reliability, all of these "ilities", like "availability". We need to define a careful tradeoff among those. We need to find the system architecture to then allows us to meet or find the system architecture that is most preferred to us. Since we have multiple objectives, we need multiple models to predict performance of a particular system performs to some objective. To go ahead and develop the models, "the model" for your system architect, doesn't wrok. Every time you have a different systems architecture, the models that represent this. To model your system once and for all up front, it becomes impossible.

What does systems architecture mean? It means from a systems perspective, what are the different subsystems, what are the specifications of the individual subsystems? if it was a hydrualic cylinder of a different size would be a "sizing problem". The systems architecture depends on connectivity or topology of the different parts. If the topology of the connectivity graph changes, you're definitely dealing with a different system architecture. You need to worry about the sizes of the individual components in the architecture. If you choose a good architecture, but the wrong component sizes, well, you might conclude that it is poor, not because the architecture is poor, but because you chose the wrong component sizes. But what if you controlled the system poorly, but the sizes are good? You might claim that there is poor performance. So, choosing a systems architecture kind of subsumes the individual problems of sizing and controlling. Otherwise you cannot judge the performance of a systems architecture.

Why is this a hard problem? How can we use formal models to guide us sufficiently to near-optimal systems architecture? Optimality is a four-letter word at Georgia Tech. We can go into more details as to why there are theoretical foundations as to why optimality is not a good thing to persue. Before I go into the details, I would like to frame it into the larger context of my research. It's modeling and simulation in design in general. In modeling and simulation, you can only do research considering the context. The models and simulation must be used to provide information to make better decisions. Models and decisions are never perfect. Decisions need to be made under uncertainty. At the same time, underneath "modeling and simulation", there's a support infrastructure that helps us develop the models and the simulations. The better the support structure, the more opportunities we have to use different models or better models in support of the decision making. It comes down in the end to creating value. We can think of this in two different ways. We can increase the benefit of models and simulations by using the models to effectively support decision-making. We can decrease cost and thus create value. This deals more with model management. If we make it less expensive to create and use models, we can move to more complex models that are more accurate and lead to better decisions. Decreasing cost can help make value.

So let's see. You can think of these three topics here. A very simple model of design. It's an optimization problem. Well, we start off with some requirements and objectives. We generate system alternatives. We need to model these and predict basically through analysis or simulation, how well these alternatives perform. We optimize and may go back and update the alternatives that we are considering. A very simple model. The parts that I will be focusing on here relate to sythesis and analysis. The top two here relate to reducing cost, how do we generate plausible system architectures cheaply, how do we analyze these in a cost effective way without human involvement, and thirdly how do we choose the right model for the phase of optimization that we are in. Models of different fidelity. All of these models are formally represented in SysML, in the systems modeling language. It's related to the Unified Modeling Language (UML) in the software engineering community. It has been extended fairly recently in the last two years to be used to describe systems in general. It goes actually beyond this a little bit where we are not only modeling formally these different types of system representations, but we also model the transformations between them, like requirements for a system alternative. The transformation itself, we can look at that as a model. The model transformations themselves are first class models. So let's see. We're going to be focusing on how we generate plausible system architectures by going through a model transformation from requirements and objectives to system alternatives. This is the first topic.

The approach that we are taking to generating system architectures is a model-based approach. We're defining a language for fluid-power circuits, in the context of the fluid-power circuits we talked about earlier. We're going to define a language. A language is another model, that defines how you can express models. Basically, a language allows us to describe what valid fluid-power circuits can look like. In software engineering, we would call this "domain specific language". We are encoding into that language, knowledge about a specific domain (fluid-power circuits). The instances of the language are domain-specific-models. We describe the language by a meta-model. Besides the language itself, we have the actual vocabulary that is used in that language. There is a library of model components. What are some of the characteristics and behaviors? A model library with static (analysis) knowledge. The generation of analysis libraries will be using this later. This is a library of possible components to be used in fluid-power circuits. There is a set of generative model transformations, knowledge about how these components can be combined into valid fluid-power circuits. It's not so that by going through and generating a fluid-power model that you will end up with the perfect solution. If you think back to the days of expert systems, the expert system would actually generate one solution that would be "best suited" for a given-set of requirements. Our approach is broader. Let's create plausible solutions, and then use analysis to identify among the set, which ones are the most promising given the requirements and objectives? These are not going to generate the best, but rather plausible solutions.

These kind of diagrams? This is one level up from SysML, we call it MOF. This is the type of diagram that you use to define SysML as a language. And since we are defining a language, this actually fits in at the same level as the definition of SysML, so rather than saying this is a SysML model, well, this is actually extending the definition of SysML. "Are you just defining properties? Are these candidate components in your architecture? Are you defining extra properties?" Within an ontology, within a certain domain of discourse, what are the concepts that we care about, and what are the relationships between them? Here we are defining fluid power, a circuit, a "circuit" is a type of fluid power element. The circuit here has multiple components. Not all of the relationships are shown in this particular diagram. It's a partial diagram. Some of the constraints and relationships have been left off. The white arrows are special cases of a fluid poewr element. We've basically constructed a set of concepts that allow us to define or model fluid power circuits. This is not a model of a fluid power circuit. This is a model of a language to be used to make.... This is a model of a model. And therefore it's called a "meta-model". Don't confuse this with "meta-modeling" as is often used in the design community. You're better calling the "meta-model" that you're familiar with as a "surrogate model". "How would this be similar to function structures? Where you connect components to previously and pre-defined types of slows that are between functions? Transfer, convert, it sounds like this does a little bit of the same thing. The component must have these parts, within it." Let me try to establish the connection. "Functions" themselves are a description of circuits. You can look at a system from different perspectives. What you are referring to is a functional perspective, how a system is built up from different functions and sub-functions. This is a descriptive model that describes a structure of a system. It is going to be such that one of the physical components in a system will most likely implement a particular function. There is a relationship from different perspectives. If you were to capture functions in this formalism, you would capture a second language, a second "meta-model" geared towards functions. I am working on this with Christie Sh.. from Munich. We're trying to formulate a SysML profile. A functional language. "So currently your language is more oriented towards your simulation models are properly used?" This is only physical architecture. How do the physical components connect together? From that we can go to the behavioral perspective and how this system is going to behave (the identification of). We're going to construct a lot of different languages. One language for each perspective, one language for each level of abstraction. Different many different languages, and then have transformations between the languages to map back and forth.

In addition to the concepts, and the constraints betwene htem, we can be more precise about what a fluid poewr component might be. We can build up a taxonomy. These become the words within our grammar. We have words, grammars, this makes up a language, from which we can then generate models. I'll come back to that later. How does this lead to analysis models? So then the last part, the "meta-model", the model library that provides the vocabulary, the last part is the set of rules that defines the grammar. We use a formalism called a storyboard. It's been developed by Endy Shur from the Univ. Darnsmarscht. It's typical of a modeling approach in software engineering to model transformations between different languages. This here is a set of two model transformation rules. The formalism of this storyboard is, "you usually have a precondition and post condition". Here, both of these pre and post conditions are included in the same graphical representation by using different colors. Anything shown in black needs to be matched for the rule to be applied. If it doesn't apply, then you use this branch, and once it does apply, everything shown in green will get added. If there's something shown in red, then that will get deleted. So this is one graph transformation rule, and that's actually pretty easy to read. If you find a circuit that contains a cylinder, and the cylinder that has 2 ports, but these ports are not connected to anything. A cross-out means a negative match. Find a circuit that contains a cylinder that is unconnected. If you find this, then add a directional valve and move on to the next step. Take this directional valve added to the circuit, and connect it to the ports of the cylinder. Graphically, we can build up a simple rule here that says find an unconnected cylinder and connect it to a directional valve. It's fairly straight forward to read. With the graphical editors that come with this, it's pretty easy to define such rules. This is created in a tool called MOFLON. This is still at the "meta-model" level. So MOFLON is the tool. The tool MOFLON is a meta-CASE tool. CASE stands for "computer-aided software engineering tool". This allows you to model different software structures. This is a meta-CASE tool, so instead of modeling structures, you now model the languages in which these structures are defined. Meta-CASE.

Once we have defined them, we can combine them into an activity diagram. That rule was called "add directional valve". We have rules for adding pumps, adding tanks, we can combine these in our activity diagrams. This is the initial node, you add a new cylinder, you then add this, you can traverse through these sets of rules. The rules are not deterministic. We have some branches here that are actually probabilistic. If the probability is different, the implicit tree. These are the probabilities that you would take a particular branch over another branch. I need to be somewhat careful. It may be that it says "try to add another cylinder". If that happens, then you're not really changing the structure of the system itself, but you're basically trying to and fail to perform that rule. So what it comes down to is the following. Our "requirements" in this simple example are that we started from some "prime mover", and we identified what types of loads and how many loads need to be driven from this prime mover. Here's an engine that needs to be connected by a translational load. Through this sequence of grammar rules that we have defined, we will automatically generate a circuit how the engine is connected through the fluid power circuit through the load. This is generated automatically. If you generate it automatically by applying the same rule twice, it ... There are different architectures that you may end up with. This is impossible to read, I recognize that, but there are four loads in this one, and automatically we fill in the remaining components. It can turn into fairly complex systems. Even though the rules were simple. We can have a large variety of different architectures. Maybe I can make these slides available if you want to look at the rest of the slides, if you have questions contact me. Alright. So. Let's see.

The tool that we use is called MOFLON. In German there is some mountain goat called "mooflon", so they used it even though it has nothing to do with it. All of these tools have some name of animal associated with it. Moflon, mooflon, they really wanted to have "MOF" in there because it's at the meta level. All of these things that I have described so far, I cheated a little bit because I showed UML diagrams, but the problem is that we cannot generate UML systems diagrams automatically. The overhead is too large. We define all the rules, in some kind of abstract language that is simple and very domain specific. To go to SysML back and forth, we define an additional mapping. And those kinds of mappings, where you are mapping one-to-one, one concept goes to some other SysML concept, MOFLON captures these mappings very well. This is using a triple graph grammar, where you have at a very high level, where you have a way to define in the meta-model, what the correspondence is. And the nice thing is that you don't need to write any code because this MOFLON tool, if you define what the correspondence is, it will generate the Java code automatically, which becomes a plugin with 20 lines of code that you need to write yourself. You can then implement this transformation automatically within existing UML tools. Let's not go into the details here. Okay. This is the part here on the approach that we're taking within SysML to generate different systems architectures. We have now generated one of these here. We then take the system description and convert it into a behavioral description. This is a description of the structure of the system, and now we are going to generate behaviors from that. The approach that we are using is "composition". We go back to the library of the components that we have defined. For each of the components in our library, we are going to associate with that, a behavioral model. Here, in a fixed displacement pump, this is a structural model that we referred to previously when we created the model. Now we are going to associate a behavioral model. This model here is defined as a Modelica model. That's what we've been working with so far. Basically it means we're capturing that this particular model is a good description of this pump. In addition, we actually define the connections between the interfaces of the behavioral model and the interface of the pump. A pump here has two fluid pumps and two mechanical pumps. The behavioral model in Modelica has a similar interface. And we're defining the interaction between the two. Once we have correspondences between structure and behavior, we can use this in SysML in the following way. If we were to model from a description perspective for a log splitter, this can be represented not only in this fluid power schematic but also equivalently in SysML. This is one of the draw backs in SysML. This looks like blocks with lines between them. Just like the previous diagram. Everything looks similar. You can make it look fancier, but it takes a lot longer. This is in ISO 1219, the traditional approach for representing fluid power circuits. The individual components are represented in SysML, and they correspond to connections between flow ports in SysML. Anything with flows and components and connections can easily be represented with an internal block diagram (IBD) in SysML. We're going to focus on the power subsystem. How can we generate for this power subsystem a corresponding behavioral model? There's a structure, we want to create a behavior with it. Fore ach component in the descriptive model, we found in the library the corresponding descriptive model, and the associated behavioral model. In the library now, we've established now, there is a correspondence between the components in the fluid power circuit, and we end up in the behavioral model. How do we identify how the connections between the structure map to the corresponding connections in the behavioral model? We have encoded these as model transformation rules. We have a sequence of model transformation rules that will identify for each of the components, what the corresponding beahvioral model is, by going through the library, and then connecting the behavioral models in the right way. Each of these blocks, internally, contains equations that describe the behaviors of these components. That's actually one of the efforts that I am involved in with OMG. We are turning that into a formal specification that will be standardized. This representation of Modelica models in SysML, next year around this time. It'll be a standard. Through a model transformation, we can create the corresponding Modelica code, which we then simulate inside a Modelica tool. Okay. That was a quick overview of how we go from "here to here". Dymola for simulations. The idea is that once we generate behavioral models, we can simulate these models in Dymola. Take the results to guide the generation of improved systems architecture. We haven't finished this loop yet, it's on going work. My student, Roaxxane has been working on this. Which behavioral models are best suited to guide this overall process? We call this the "designer's dilemma". We are working with models of different levels of fidelity. Not all of these levels of fidelity are equally suitable. If you are trying to explore different design alternatives. Given a certain level of effort, you're kind of restricted in this space from where you can go. You can spend all of your level of effort on the exploration and optimization. But if you do that, well then there are consequences. The level of fidelity in your models that you use must be very low. It's expensive. If you want to use the models very many times, then they can't be very expensive otherwise you will run out of resources. I will only want two or three alternatives, and then I can spend a lot of resources modeling. Neither one is a good option. We should be somewhere else, to stretch where we go with our resources-- have broad exploration, but high simulation fidelity. Is this possible? Maybe we can use the same resources more sparsely to stretch how far we can go. So, another way to think about this is the following. Let's assume we have formulated this problem in a cost minimization. Here's a cost minimization function. It's expensive to compute. We could actually have a model for this minimization function that is not accurate. There is a lot of uncertainity. The further we are away from the optimum, the broader the uncertainity. If we are far away from the optimum, then I don't care how far we are. If we are far away, we only need to know which direction we need to move in, but I don't need to know how terrible my objective function is. As long as I know that I can get it closer to zero, then I'm happy. Far away from the optimum we can be very inaccurate and get away with it. When we are closer to the optimum, we need to be very accurate, otherwise you can't distinguish between the best and the good. The approach that we have taken is to use two levels of fidelity, only two levels. Start of f by exploring the objective function with a low fidelity model. If the low fidelity model gives you a value below a certain threshold, then you must be pretty close, and then you run in addition a high fidelity model. If you are far away from the optimum, then you run the fast low fidelity model. Once you get close, use the fidelity. How do you know what to set the threshold up? Shouldn't you look at the slope of the objective funcftion? Another student of mine is looking at "value of information" as a metric. If you use value of information, then you can ask "how much should I be willing to pay to improve the accuracy of my simulation?" For a given state of your optimization problem, you can calculate whether or not it's worthwhile to compute one model or a more accurate model. The value of information is too small to warrant a high fidelity model when you are very far away from the optimum. If you are very close to the best solution found so far, then it is worthwhile to perform this high fidelity simulation. We're looking at approaches theoretically that build on value of information theory, which helps us decide when to use which model. At this point, we just "pick a threshold", as if we have some prior knowledge. It's not perfect, but it's a first step.

There's actually a second advantage of doing that. You first start off with the low fidelity model. If it's below the threshold, you return the low fidelity value. If it's below you know it's close (er, so if you're above threshold, you return the low fidelity model). With the high fidelity models, well, they are brittle if your parameters suck. In simulation terms, they may become "stiff". If you have a system that is poorly balanced in sizes, you will often get "stiff systems", and they will fail. Your backup is the low fidelity algebraic model that is very inexpensive. My student Roaxanne implemented this. Minimizing operating costs. We call this an "influence diagram" proposed by Howard and Mathison. It's an easy way to capture what the design problem is that we are looking at. We're looking at different trajectories for the excavator, and the different models determining ultimately what the trench cost is. This is a way of summarizing the design problem. It lets us capture how the high fidelity model is different from the low fidelity model. We include fuel efficiency and fuel cost. These are fairly preliminary results. If we plot low fidelity versus high fidelity. As you get close to the best possible solution, you use the high fidelity model. The low fidelity is usually close to one second, compared to the high fidelity models. By using this simple two-tiered scheme, we save about 25% CPU time when solving a design or optimization problem. I was disappointed by this, because the time difference between 60 or 70 seconds for a high fidelity simulation, and only 1 to 2 seconds for the low fidelity simulation, would seem to indicate a factor of 30, but it turns out that the simulation or optimization would do a broad exploration quickly, and then it gets close to the optimum, and then from there on out, you always run the high fidelity simulation. Overall, you can still broadly explore. We use a genetic algorithm to do this. It does a very broad exploration, fairly inexpensively, but then when you get close, the savings drop to zero.

In summary, I've gone over three different aspects here of what it takes to explore different systems architectures. What I would like you to remember is that you can do this with a very formal model-based approach. I really encourage you to look carefully at the tools and methodologies that have been developed in the software engineering model, where they are moving towards a completely model-based approach. For systems engineering, there are fantastic opportunities to apply these tools to this context also. It will increase benefits, reduce costs, and very importantly to me, everything is a model. Our slogan is "model everything". Model structure, function, behavior, and model the model transformations, they are first class citizens also. Model everything.

Any questions?

"You put a threshold. Back to Ben's question when you pick to high fidelity. We were scheduling the fidelity to a temperature in simulated annealing. Early in the optimization, you use high fidelity. At the end, you use low fidelity, regardless of the value of the objective function. It's a threshold in time. You switch from low to high fidelity at particular moments or particular iterations, regardless of the quality of the candidate. It could do that in a GA too, you could say the first 25 low fidelity, the second 25 fidelity." Assuming you are converging, switching with respect to time, and switching with respect to candidate quality, might be related. If you come to a solution that is really off the mark. ... "The way you could say is that, you are comparing at a particular time, is A better than B, so in order to compare you want them to be on the same.." The direction that we are thinking is, this will require a leap in the way simulation. We need to move towards "predictive modeling" where you don't just run a model or a simulation and get a model. You need to characterize the uncertainty with this. If you end up with a situation where you already have one point, and you come across one point, even if the uncertainty is very broad, if you compare the distributions that one will dominate, is virtually zero, then there is no point in moving towards more detailed analysis. If you can characterize in predictive modeling, then you can guide these processes in a more directed fashion. At the moment we do not have the capability. It mostly depends on the quality of the models. It's hard to judge whether we should go to a more detailed model or not.

"A large thing that doesn't really convince me is the focus on graphical language to describe your model. Are there tools to describe SysML not using blocks and arrows?" Very good point. I glossed over this. Let's pick this SysML model here. What shows up here as blocks and connections between blocks, or ports even, this is just a typical SysML model. It's really a "diagram". The "diagram" is not a model. A "diagram" is a visualization of the model. So in computer science we refer to this as "concrete syntax". In addition to the concrete syntax, there is a "abstract syntax model" that defines the concepts and the relationships between them. When we manipulate this model, we're not saying "look at the pixel", we're actually looking at the abstract syntax model. SysML is no different if you look at the abstract syntax, then if you look at any other model. In addition to the abstract syntax, there is a graphical concrete syntax. If-then statement. But that's exactly if you use a model transformation framework. If there is something connected, that means "if the model contains this pattern, then perform this operation". The big difference between describing it in that way, rather than describing it in code, you could do more in code, or even more in assembly code. It's pretty darn hard. So if we raise the level of abstraction at which we would like to see happen, then it makes our life easier. The level of abstraction has been rbought up here to a "declarative model". You say, "find this pattern, and transform it into this". This is a declarative modeling approach. There are declarative programming languages, but most of them are imperative. And, people feel that declarative modeling, I'm one of those people, is a higher level of abstraction and is easier to work with and maintain, rather than working at the code level.

"How hard would it be to use some of these techniques on a different system, like heat exhcangers and different things like that? How hard would it be to take it and go to a different domain." At this point, starting from scratch would be very hard. Just getting familiar with all of the terminology and tools is non-trivial. The vision that I would like to see pursued within the engineering design community is that we start encoding, from the bottom up, some of the knowledge, related to formalisms such as functional behavior, structural, but also according to domains. Fluid power, mechatronics, pick any domain and say, hey, let's encode our knowledge about that particular domain about function, behavior, etc., and let's start building this up from the bottom up. If people start contributing, we will have a lot of knowledge in a formal representation, so that we can exchange it and share it with others. The idea is that once you have something defined in a formal language, describing it, extracting information from it, or describing it in another language, is really easy. People have said OWL, why not use it? Yes, you could do that. It's easy to write a mapping between SysML and OWL. If you prefer working in OWL, then let's just translate it back and forth. The expressiveness is very similar. You can do some things in OWL not easily done in SysML. All of these languages are converging. People are building translators. It's more of a style or a preference for what language is better suited for what you are doing.

"How do you combine the hydraulics language, and your structure language? Doing all of those things at the same time with a single model?" Hydraulics versus structural is straight-forward because there are certain interfaces that allow you to go from one domain to another. In order t ogo from hydraulic to structural, you need to have a sensor or an actuator, that relates it to concepts in the other domain. Now, thermal versus hydraulic, you may say, well, both need to be considered simultaneously. Well, then it becomes more difficult. If these two are coupled, coupling is significant, then you may need to move towards a thermal-fluids domain, rather than saying here's my thermal perspective, I might need to combine them to capture the coupling efficiently. What's the level of abstraction that we need to go to? We need to be focused on the fluid part, or do we need to be concerned with both?

"Are your architectures limited to standardized connections? In your fluid-power system,s you can run a cable with fluid under pressure. Versus a more abstract or generic architecture. Where am I going to put the pub or other components? Are you putting more focus on fluid connections?" Well, we need to start somewhere, so we focused on something simple. The architecture is connectivit,y and we don't have interference of parts, nesting, or anything in a more generic architecture." We actually have control over how well suited this formalism is for what we're doing. If you ask that same question to a systems engineer, the person who thinks at the systems architecture level, then the problems that you run into with coffee makers are not very common, ebcause if you think at the systems architecture level, you allocate functions to components, and the intermingling of functionality to different components is not that common at the systems architecture level. If we architect systems, we tend to choose systems that are easily decomposable. This is a way of managing complexity that we choose. If we decide and often that it is the case that at the lower levels that you are better off combining the functions in a varfiety of ways, then these languages may fall apart.