The product system is the highest level system that you are designing, the overall design intervention to address the design problem (aka imbalance).
Systems nest inside one another in hierarchical fashion.
Consider again figure 1. Let's say you're designing the
car system. That system is bounded to contain all the subsystems that constitute a car. The boundary is drawn where it is because, among other things, it defines the limit of your control as a designer. If you're designing the car, you have no control over the gas stations, the roads, the stoplights, or any other system in which your car will have to operate. And even if your car is part of the transportation system, you still have no control over it. On the other hand, you do have control (to an extent) over all of the elements inside your car system.
The system boundary that describes the limit of your control is the overall product system boundary. There is only one product system boundary for a given project or design intervention, so it is quite special.
The control that this boundary marks is particularly important in terms of determining the inputs and output of your design intervention as a whole. You cannot control the inputs that enter your
car system from beyond the product system boundary. The best you can do is accommodate them within your design. Similarly, you cannot control what happens to the outputs of your
car system once they leave the car and enter the environment; the most you can do is try to control the amount and quality of outputs your intervention produces.
Because of these special characteristics of the product system, we have a specific task intended to identify it as crisply as possible.
We design interventions to “fit” into a particular environment and to balance forces that exist in that environment. Since the environment is existent, but your design intervention doesn't exist yet. The only rational place to begin the design process is with the information you already have: the environment. The “edge” or boundary of that environment which separates it from your design intervention is the boundary at which you can start to fit your design.
Exercise for the reader: You can think of this as working on a jigsaw puzzle. Imagine you have assembled most of the pieces. There is a hole in the middle of the puzzle and there are several pieces available. What strategies do you use to speed up finding the right piece? How does this analogy translate to the situation of system design as described here?
Identifying the product system defines the boundary across which you must accommodate inputs and send outputs that your intervention produces. It also defines the scope of control you have over the project as a whole.
Systems thinking, design, and analysis are methodologies best used for complex problems. Virtually any design problem or imbalance can be sufficiently complex to benefit from a systems perspective.
Since a product system is defined by its boundary with the environment of the situation that gives rise to the imbalance that you're design intervention is intended to address, it is best to identify that product system immediately after requirements have been established (and documented in a PRS) - that is, at the very start of the system design stage of a project.
Properly identifying a product system may require doing additional background research to address questions arising during this stage. These questions will usually require defining more crisply the nature and amount of inputs and outputs one can expect to enter and exit, respectively, the system you are designing.
Remembering that documentation is key in engineering design, not only to stimulate crisper thinking but also to ensure proper justification for all decisions, we identify a product system by drawing an appropriate system diagram (with supporting text documentation).
figure 2 shows a sample system diagram for the design of an elevator system, showing only the system boundaries and the inputs and outputs. (NOTE: there are some errors in the diagram that are explained below - and in lecture.)
Since you haven't yet designed the system, then using a simple box to represent it is sufficient. The dilemma is in carefully specifying the inputs and outputs. This requires referencing the requirements, so it's essential to have a proper product requirements specification available.
The most important point about system boundaries is that they are not boundaries in space, but rather boundaries between functions. Don't think about where boundaries are in space, but rather about which functions are inside the boundary and which are outside.
Whatever you design will have to “fit” within whatever already exists, physically or otherwise. Therefore, there must be some boundary within which your design as realized will exist and likewise there must be things in the situation that will still be there after your design has been realized.
It is essential to understand as precisely as possible where that boundary will be, for several reasons.
Since systems are functional and not necessarily structural in nature, the system you design is bounded so as to include all the functions that your product is expected to provide, and nothing more. This is usually relatively easy, if you have a good PRS. The PRS essentially defines exactly what your product has to do. Your system boundary will encapsulate those requirements and nothing more.
One proceeds one requirement at a time through the PRS and identifies the nature and, if available, type and quantity, of each input and output. One then adds those inputs and outputs to the system diagram.
We remind the reader again that our perspective on the word “transformer” is analogous to a mathematical function, that transforms its inputs to its outputs. So, the things that are transformed by a system, are the combined inputs to and outputs from the system.
For example, consider the following diagram, which shows graphically the things that are transformed by a gas station.
To identify the inputs and outputs at this very “high” level of systems design, you need to think about how users get along without the new product. In designing the gas station, we need to know if we're designing a gas station to be built where none currently exists, or if we're designing a gas station to replace an existent one.
If we need to replace an existent station, we need to study it, to understand how it functions, what is wrong with it, and what people wish were available. This will tell us how people are getting on without the new gas station that we shall design.
If no gas station exists, we still need to understand how people are moving around the area where the station is to be located, what other facilities are nearby, and so on.
Then, we consider what things will change once the new gas station is open for business. We can't talk about details yet, because those will depend on the details of the new gas station – which doesn't exist! But we can make some general statements: a few jobs will be created; traffic patterns will change; pollution could increase; increased risk of environmental damage; more light pollution at night; improved local economy; and so on.
And from these considerations, we can list the major existent elements in the particular context or setting, that will be transformed by the new design, just as the figure above shows.
Notice we've said nothing about the gas station itself; all we've discussed is the setting into which the gas station will be introduced.
Remember: don't think about the specific structure of your product because that's the solution – and we're not quite ready to think about that yet.
There's a problem: the transformed entities are so far too generic, too vaguely defined to be useful in engineering design. So next, we want to describe the specific attributes of each transformed entity that figure in the transformation. We may sketch it out visually as shown in Figure 4.
Notice how, in figure 4, we have labelled the arrows to describe something about the specifics of the impact each attribute can have. This is very important: we need to know which impacts will be beneficial and which will not, and we will design to try to maximize those benefits and minimize the detrimental aspects.
There's still something missing: the relationships between the attributes. Any one of the attributes shown in figure 4 can influence one or more other attributes. Improving one attribute may make another attribute much worse, and the net result will be a bad design. So we need to identify those relationships before moving on with the design. figure 5, below, shows some of the possible relationships between entities. (Note that the central part of the diagram has been hidden to keep the diagram legible.)
Diagrams are very useful, because we can capture more information with diagrams, and capture it more densely, than we can with, say, tables. If one were to try to represent Figure 5 with tabulated data, one would get something like this, which is nearly impossible to comprehend.
Whenever a new input or output is added, one must carefully check to ensure that all the other inputs and outputs still “make sense.” For instance, if a diagram already has an energy input specified as electrical power, and if one needs to add a second electrical power input, then one must decide if it is best represented as a separate input, or as part of the existent one.
There are no rules for how to make such decisions because they are entirely dependent on the specific nature of the particular problem one is trying to solve. However, you must remember that every decision must be justified. So however one decides to handle a particular input or output, one must be able to explain why that decision was made.
These so-called rationales must be recorded. Usually, they cannot be added directly to the system diagram without making the diagram too difficult to understand. A reasonable way of getting around this problem is to number each input and output, and then have a supporting document listing all the rationales. Each rationale is also numbered so the numbers match up with the numbers in the system diagram.
Defining the inputs and outputs - that is, the system interfaces - of a system can be much more difficult than drawing its boundary. figure 6 is a system diagram of some of the inputs and outputs that might pertain to the design of a gas station. (NOTE: There are some shortcomings in the diagram that are there for pedagogic reasons; i.e. they are discussed in lecture.)
Exercise for the reader: Based on figure 6, can you identify the transformations that the gas station must manifest to be a successful design? Do you think the transformations you identified are all the transformations that the gas station must manifest? In what type of document would you look to make sure you have identified the transformations correctly? Do you see any errors in figure 3?
Remember: a system transforms its inputs to its outputs. So anything that the station transforms is an input. This is why both vehicles and people can be inputs and outputs. Some notes about the specifics of figure 3 are in order:
vehiclesare separate inputs because a person may come to a gas station on foot for some reasons.
Station personnelare their own input stream because the sort of things they are likely to do at the station are substantially different than those of other potential users.
It is important to note that this same process can be applied to any system, subsystem, or supersystem.
Remember, there is one very important feature of the inputs and outputs to the product system: they are not under the designer's control. The inputs are derived entirely from things in the environment, and over which the designer has no control. Similarly, the outputs are defined by the requirements and are likewise not under the designer's control. However, within the boundary of the overall system, the designer does have control and so can specify the inputs and outputs in whatever way the designer deems best (subject, of course, to various constraints and limits like the laws of nature).
There are not only good inputs and outputs; there are also bad inputs and outputs.
Bad outputs are usually our doing as designers – no matter how we try, every product will have some undesirable effects. Sometimes, these effects will be minimal, but other times they will seriously affect the overall quality of performance of the product. Any machine will make waste energy. But there are many other kinds of waste that systems can produce. Any source of waste that can have significant detrimental impact on the system's operating environment must be included in the systems design.
We have a responsibility as engineers to mitigate those bad effects as much as possible, and to make very clear to potential users what those bad effects might be. We prefer to minimize the production of bad outputs.
Bad inputs are different. They are best described by variations in the expected inputs to our product.
Example: Many electrical products are not designed with electrical surge protection. An electrical surge is a spike in the electricity supply that often results in permanent damage to the product and, occasionally, severe injury to the product's user. The surge is a sudden and unexpected variation in a system input.
Example: When this module's author was having his house's basement finished, a plumber suggested rerouting a drain pipe from a sink on the main floor so that the basement ceiling could be a little higher. But rerouting the pipe required adding several more bends to it, each of which becomes a possible “trap” for foreign objects. In other words, the pipe would be more likely to get clogged.
Just as one can consider inputs as good and bad, so too can one think of the outputs of a system.
When we looked at inputs, we defined good and bad with respect to the needs of the system: a good input was one that the system required or preferred to operate well.
However, when considering system outputs, we define good and bad with respect to the situation in which the system operates. That is, a system is put into place to serve some function in a larger system.
The functions in these examples – power, passenger comfort, and writing – only make sense in the context of the supersystem that contains the system we are designing.
So when we decide which outputs are good and which outputs are bad, we must do so in the context of how our product will be used.
System outputs return to the environment from which the inputs came and in which the product must exist and operate.
This is important because these outputs can change the environment in ways that engineers may not have expected during the system's design. The outputs may so change the environment that the inputs may no longer be available, or may be somehow degraded. The outputs may actually prevent the inputs from entering the system at all – which means the system won't work.
Example: Imagine a candle burning. In gravity, convection causes the hot outputs of combustion to move upwards, which in turn draws more oxygenated air to the flame, and the candle continues to burn.
So, when you're designing a system, you need to consider the impact that the outputs will have on the environment in which the system will be used, which includes the inputs that the system will need to continue functioning.
What's more, we have a unique opportunity at the systems design stage to evaluate qualitatively2) the response of the environment to the product's introduction.
This kind of assessment doesn't necessarily mean only “bad news” for the product developers. A careful study of how a system's outputs will impact the operating environment can lead to:
All these things can actually help the business aspects of engineering while at the same time lowering the net detrimental impact of a system.
This also underscores the importance of following up after the introduction of a new product. How bad were the bad outputs really? If you didn't predict them accurately, what can you do to do better next time? What lessons can be learnt for future products?
All inputs and outputs can be classified into one of three types: mass, energy, and information.
In many cases, the principal inputs and outputs are very obviously classified. However, there are often also cases when classifying a particular input or output as mass, energy, or information depends more on why you need the input or output than what specifically the input or output will be in the finished product.
For example, consider the dreaded automobile. For a conventional car, it seems quite obvious that gasoline and air are mass inputs to the engine. But let's say you're designing a concept car, a vehicle for which an a-priori decision to use a gasoline engine is unwarranted at the beginning of the design. If it isn't given as part of the problem that a gasoline engine must be used, then what are the inputs?
In this case, we would say that we need an energy input. The energy might come from a fuel cell, from batteries, or from an internal combustion engine – we don't know yet which. But thanks to the first law of thermodynamics, we do know that we will need to get energy from somewhere to make the car work. So we define an energy input.
At some later point in the design process, we will be able to decide where that energy comes from. At that time, we can redefine the input, depending on our decision of how we will get the energy.
Let's consider another example: say you're designing a flashlight. One kind of flashlight requires the user to insert batteries and change them when they're exhausted.
Another kind of flashlight has “permanent,” rechargeable batteries; in this case, you plug the flashlight into a power outlet to recharge. When the batteries no longer hold a charge, one throws the flashlight away – or at least puts it in the recycling bin.
In both cases, power is needed to make the flashlights work. But in one case the batteries are inputs to the system, whereas in the other the batteries are part of the system.
The diagram to the right shows how we might architect these flashlights. These diagrams are only partial (i.e. incomplete) architectures meant to emphasize how different design decisions can be captured in diagram form.
The upper architecture is for a conventional flashlight with replaceable batteries. Here we see the batteries are shown as input. The thick arrow is used to denote a mass input/output to the system; thin arrows denote input/output of energy.
Note that batteries are legitimate system inputs because they are transformed by the flashlight. They enter the flashlight in one state and exit in another. We could have labelled the input “fresh batteries,” but didn't because it is not necessarily true that the user would know that the batteries going in to the flashlight are fresh.
We would specify batteries, of course, only if we had made the decision that batteries are appropriate – and that we can justify the decision in some way.
Exercise for the reader Describe as many situations as you can where a user would not know if the batteries start off fresh.
Follow through with this line of reasoning. What undesirable situations could this lead to? How could a designer help a user by designing features into the flashlight?
It's important too, to remember that what goes into a system, must come out one way or another.
A common mistake in creating architectures is to forget certain outputs.
Rule of thumb Whenever you add a system input to an architecture, take the time to think of what outputs can result. Do not add all the inputs first, then all the outputs; doing this increases the odds that you will forget some outputs.
The other flashlight architecture is for a flashlight that has permanent, rechargeable batteries.
Exercise for the reader Compare the architectures of the two kinds of flashlight. Note the differences in how the architectures are diagrammed. What are the implications of the rechargeable flashlight architecture with respect to other stages of the product's' life cycle?
Sometimes, you won't know exactly what kind of inputs you will use until later in the design process. Consider the architecture diagrams to the right, of automobile engines. The upper one is an initial architecture of the type that might be used before you have decided exactly what kind of engine to use. In this case, all we can say for certain is that energy will go into the engine, and that mechanical power will come out (along with some waste products). We really have no choice but to use thin energy arrows here.
The lower architecture represents the engine after we decided to use an internal combustion engine. Note that we've completely changed the system inputs. We could do this only because we made a design decision to use an internal combustion engine. That is, designing happened between the two architectures.
By keeping good version control over your architectures, you can generate quite a detailed trail of the major decisions you made during your design.
Sometimes, it's not so easy to decide if a particular system input or output should be one of mass, energy, or information.
Consider a person A who gives another person B a book. Is this exchange one of mass, energy, or information? The answer depends on the reason for the exchange – that is, the function that the book serves for person B, who receives the book.
If B needs to read the book, then what he really wants is the information in the book. The information might have been sent to B via email, or spoken out loud by A to B. In every case, what matters is the information in the book, not the book itself. So we would model this transfer between A and B as an information transfer.
But what if B needs a doorstop instead? In this case, a sufficiently large book would do the trick. In this case, it's the mass of the book that is especially important; the information contained in the book is irrelevant. We would model this transfer between A and B as a mass transfer.
Exercise for the reader Can you think of a situation where A giving a book to B would constitute an energy transfer?
You might be wondering now: Does this mean that the architecture of the internal combustion engine (above) is wrong? After all, it shows the gasoline and air entering the engine as mass inputs. One could argue that the only reason the gas and air are inputs are to put energy into the engine.
That's true, of course. The real issue is the context in which we are describing the architecture. That is, it depends on the design teams perspective. One can represent the gas and air as mass inputs, if the team decides that an internal combustion engine will be used, and that everyone involved in the project will understand why the gas and air are being inputted into the engine. That is, you can do this if the audience of the diagram can be expected to know the reasons for inputting gas and air into the engine.
If, on the other hand, a design team thinks its more important to represent the reasons for inputting gas and air – perhaps because some people who will use the diagram are not familiar with such things – then you could represent them as energy inputs.
In other words, it's up to the designers to decide how to represent the inputs and outputs, taking into account who else will be using the diagrams. This is a great example of how important communication is in designing.
Also remember that anything that is transformed by your product system should be given as an input when you start an architecture. So for example, if we model a cup of coffee as a system, then the person drinking the coffee should be an input and an output too.
Refer to the figure to the right. The coffee is an input because the cup is empty to begin with, but it's not output because it is consumed in the process of drinking. That is the alert drinker that is the output contains the coffee.
Identifying an input to or output from a system is a decision: by stating that this is an input, you are excluding every other possible input - which constitutes a decision. All decisions must be justified. So you need to document your rationale for identifying your inputs and outputs.
Fortunately, because the product system is a “special” system, justifying the inputs and outputs is relatively easy to do in this case. Since the inputs and outputs were drawn from the requirements, then all one needs to do is note which requirements relate to which inputs and outputs.
One can just use some numbering system for the requirements, and then note by their identifying number which requirement justifies which input/output.
There is no direct deliverable from this task. However, the work done here is needed to achieve the deliverables of a PAS.