The world is composed of distinct function elements that interact with each other, and are elements of bigger functional things. This is the basis of the systems perspective, and those things are called systems. It's a way of looking at the world that lets one compartmentalize phenomena to understand them more easily and better. This perspective can greatly help designers understand the impact that the products they create has on the world, and vice versa.
A system is (1) a set of (2) interacting elements, (3) that provide a specific set of transformative functions, and (4) that is distinct from its environment.
That is, a system has four characteristics:
Consider the design of a paperclip. From the point of view of the paperclip, it and the papers it binds together do constitute a system, but an unused paperclip and the tray in which the paperclip lies does not constitute a system. This is because when the paperclip is binding paper, it is providing a function and interacting in a manner of interest with the paper; but when the paperclip is just lying in a tray, it is not providing a function and it is not interacting in a manner of interest from the paperclip's point of view.
The situation would be different for the design of the tray: the tray's designer would indeed consider the tray and a paperclip in it to constitute a system. Can you explain why?
Point of view is very important when dealing with systems. It can, however, be confusing when you have many systems to design together.
Exercise for the reader: Identify which of the following items constitute a system, and explain why it is or isn't a system, with respect to the definition given above.
There are two terms we use to describe one system's relationship to another system:
Exercise for the reader: Refer to Figure 1 below: Identify all the subsystems, naming the corresponding containing systems, and all the co-system groups.
The systems perspective works best when you admit only two kinds of things: systems and parts. Systems can contain other systems or parts, but parts cannot be broken down at all - they are “atomic” items. So a product would break down into a hierarchy: the product itself is a system, which is composed of other systems, each of which is composed of still other systems. Eventually, though, one finds some level of sub…subsystem that contains only parts; and there, the hierarchy ends.
What is interesting here is that any product we design is not only a system in its own right, but is also an element in some larger system. And that larger system is an element in a still-larger system. So the hierarchy works both ways, down in detail from our product system, but also up into larger and larger supersystems.
Refer to figure 1, and consider a piston in a car's engine. It is a part of the engine, both structurally and functionally. Since the engine is part of a car, it follows that all parts of the engine are also parts of the car. Put another way, the piston is an element of the car system. The engine is an intermediate system (a subsystem) that is useful in its own way, but it doesn't really exist except as a mental thing.
Exercise for the reader: Imagine you are looking under the hood of a car, at the engine. Except for knowing what an engine is, how exactly can you tell where the engine ends and the rest of the car starts?
Of course, distinguishing the engine as a particular subsystem of a car is very useful. It helps manage complexity by letting us break up functions a car must carry out. Indeed, the functions of the engine are unique over all other systems in a car. There may be cases of cars that have more than one “engine” (or at least motor) — consider hybrid vehicles, or cars that have wheel-motors1). But in this case, the functions provided are substantively different than those of a conventional internal combustion engine.
Exercise for the reader: How are the functions of wheel-motors different than those of an IC engine?
This logic follows right through to the other “end” of the chain, the economic system per Figure 1. That is, a piston is in essence a part of the economic system.
What we're missing here is the degree to which the piston is a participant in a system that contains it. The piston is essential to the engine, but not very important at all to the economic system. The “distance” between the piston and the economic system is a rough measure of this.
Still, one cannot discount the influence in certain unlikely circumstances.
Thought experiment: Can you think of a circumstance where a piston could influence an economic system (e.g. the economy of a region or even a nation) significantly?
Exercise for the reader: If you're interested in how different technological things connect together throughout history, then you'll love James Burke's television series Connections.
Exercise for the reader: Think of 10 systems. For each system, think of as many possible supersystems as you can.
Systems have certain key features. Understanding those features is the essence of understanding what systems are and how they operate.
Consider a refrigerator. Its function is to provide a small cold space for preserving things. How it executes this function (that is, its behaviour) is irrelevant (except to HVAC engineers and refrigerator repair-persons), because all any other system cares about is its inputs and outputs - its system interface. You don't care how or why your refrigerator works, so long as it does - its behaviour is encapsulated within it. The behavioural performance of the transmission of an automobile is entirely independent of the behavioural performance of the engine. It doesn't matter if the engine has four cylinders or eight, or operates by internal or external combustion; the transmission accepts certain outputs from the engine as its inputs, and does something with them to create new outputs. Thus, a system hides - or encapsulates - its internal structure and behaviour within it, such that no external system cares at all what is going on inside it.
Sometimes, we call a system a black box to underscore that its internals are completely separated from the system's environment. This is described in different ways in the literature. For instance in [AEO11], functions are categorized as basic (external functions visible to agents outside the system) and secondary (internal functions that operate entirely within the system); in this case, the secondary functions are entirely encapsulated by the system. There is also a common - and arguably simpler - convention: behaviour is what happens inside a system; function is how that transformative behaviour is used outside the system.
An important consequence of system encapsulation is that one can substitute any one system for another, so long as its inputs and outputs are the same. This is the foundation of modularity.
This underscores the importance of understanding the boundary of a system. Encapsulation only works if there is a crisp separation between systems; that is what boundaries are for.
If you are not sure where the boundary of your system is, then you're doing something wrong.
Systems are dynamic: they do things with and to other systems, and other systems can do things with and to them. However, since the internal structure of systems is hidden from outside its boundaries, the only way systems can communicate is through interacting - exchanging things between them.
In engineering design, there are only three broad classes of things that are exchanged between systems: mass, energy, and information. Specifications of system interactions between systems (which is a part of designing) are the system's system interfaces. A system's interfaces describe its behaviour.
Exercise for the reader: For each system below, (a) identify its boundaries and (b) describe its interfaces as fully as possible.
A system is a dynamic entity that responds to stimuli by performing some kind of transformation. You can think of it as an analogy with a simple function:
y = f(x).
x is the input,
y is the output, and
f is a function that transforms
y. The function
f is the system,
x represents the mass, energy, and information inputs to the system, and
y represents the mass, energy, and information outputs from the system. NOTE: This is the view from outside the system; if we were inside it, we would be talking about behaviour.
Inputs and outputs are not necessarily things that enter and exit a system in the usual sense. They are the things that are changed by the system. Here are some examples of non-obvious inputs and outputs:
aand one output is the user at floor
b. The same argument can be made for the driver and passenger of an automobile or other vehicle.
Sometimes, the changes to the inputs can be quite profound; these are the changes we are more accustomed to thinking of as inputs and outputs. Gasoline is an input to an automobile engine and the corresponding outputs are mechanical energy, heat, noise, and various unpleasant chemicals.
The important point here is that anything that is transformed by a system is an input/output.
Exercise for the reader: For each system below, identify as many inputs and outputs as possible. Be sure to match inputs to outputs.
This view of systems is supported by Eekels ([Eek00]), who wrote that an action is performed by a subject on an object.
A system's components do not have to be in physical contact to interact. The earth and the moon constitute a system. A billboard and the condominium the view of Lake Ontario that it blocks constitute a system. The furnace and the people who live in the building that it heats constitute a system.
Assemblies are a special kind of system, where there is physical contact between the parts.
A corollary of this is that system components may be distributed (intentionally) throughout other systems. For example, the electrical system of a car has elements scattered everywhere within the car, and yet is considered a system distinct and separate from all the others; this is because it provides a distinct and separate set of functions.
Consider an automobile and its engine. The automobile is a system. So is the engine. The engine is a subsystem of the automobile. One function of the automobile is to move people and cargo. The function of the engine is to create mechanical power sufficient to move the automobile. The function of the engine is not the function of the automobile. But the automobile needs the engine's function to provide its own function.
In this case, a system uses the function of subsystems to deliver a possibly different function.
This is supported by Eekels ([Eek00]), who wrote that parts of the subject are connected to parts of the action by a functional organization, and an action method connects parts of the action to parts of the object.
Consider instead a warm air humidifier. This product serves two functions: to warm air, and to control the humidity in the air. Inside the product is a heater whose function is to warm the air that passes through it. This heater is a subsystem of the product. In this case, the function of a subsystem (the heater) is the same as one function of the product as a whole (the humidifier).
Here, a system simply passes the functions of its subsystems up to the user (it “inherits” the functions of the subsystems).
Two different systems can share physical parts. A system groups functions, not parts. For example, an engine block is part of the combustion system and the lubrication system (the engine block contains passages that let lubricant move from the top of the engine to the bottom); the block is part of two different systems.
Unless there is a specific reason to introduce redundancy into a system, then systems must provide non-overlapping sets of functions. In a car, for example, only the engine provides power. The battery provides power too, but only to start the engine and run certain electric systems. The battery is recharged by the engine. Even though both the battery and the engine provide power in the general sense, they have very specific and non-overlapping roles.
There are three basic types of system inputs and outputs: mass, energy, and information; but since systems are functional units, their inputs and outputs should be functional too. That is, deciding whether a given input or output should be one of mass, or energy, or information depends on the function that the input/output will serve. It also depends on how much one already knows about the design.
For instance, one might be tempted to define an input into an engine as a mass input: gasoline. This assumes, however, that one has already decided to use gasoline as a fuel. It may be that the problem is constrained such that gasoline is the only reasonable energy source; in this case, the assumption is justified. On the other hand, the assumption is not justified if no such constraint exists; in this case, it makes sense to specify an energy input - which opens the possibility of using other kinds of engines - rather than a mass input. This is to say that one specifies input and output types based on the needs of the problem, which is defined by the situation one seeks to address.
The situation becomes even more tricky when dealing with information inputs and outputs, because information can be carried by both energy (such signals in wires, or RF radiation) and mass (text in books). Again, the specifics depend on the reason why the transfer between systems is needed. Consider the following example:
If I give you a heavy textbook, it can represent:
In all three cases, the same book is passed between systems, but it is treated as one of mass, or energy, or information, depending on its role (function) in the situation. This underscores the important difference between the physical form and substance of a design intervention on the one hand, and the way that it gets used on the other. As designers, we always start from the use (function) and move toward form (structure).
Thus, when one identifies inputs and outputs of a system, one must consider the role of those inputs and outputs within the larger ensemble of systems that includes the system being designed.
No system is perfect. This means that all systems produce “good” and “bad” outputs, and have to deal with “good” and “bad” inputs that come to it from other systems.
The terms “good” and “bad” are relative; that is, they depend on the roles assumed by the inputs and outputs in specific situations. For example, a gas-powered internal combustion engine produces a good output - mechanical energy - and several bad outputs - waste heat, noise, and a variety of noxious chemicals. The engine also has to tolerate a variety of bad inputs: impurities in the gasoline, acts of vandalism (e.g. putting a sugar cube in a gas tank), a range of possibly harmful ambient temperatures, etc.
To design a good solution, a designer must account for both the good and the bad inputs and outputs. So both good and bad inputs and outputs must be treated in a system design.
The good inputs and outputs are quite naturally treated, and tend to be identified very easily based on requirements for the design problem. Bad inputs and outputs are generally treated in two ways:
No matter how one deals with bad inputs and outputs, it is essential to include them in any system design exercise.
The systems approach is to start by considering a system to be a black box; that is, an entity the internal structure of which is not apparent. At this stage, we can only talk about the system's inputs and outputs (i.e. its behaviour) without thinking at all about how the system converts its inputs into outputs.
When designing a system (mechanical or otherwise), the outputs are determined by the functions (functional requirements) that the system serves in its environment. The inputs, though often constrained by the environment, can be specified by the designer. Besides the functions, a product might have to exhibit certain qualities (product characteristics) that further limit its behaviour (how it can transform inputs to outputs). The inputs and outputs together constitute the a complete set of interfaces between a system and its environment – every possible interaction of consequence must be accounted for.
Notice how a product architecture corresponds nicely with the needs of systems design.
Exercise for the reader: Consider a pen. It is a system. Its inputs are forces transmitted to it by a human hand and by a writing surface. Its output is ink left behind on a sheet of paper. The internal structure of the pen and how it transforms its inputs to its outputs is unknown to us, because at this stage the pen is a black box. The output is constrained by its environment and the nature of its intended interactions with the environment. Many questions are unanswered, though. Will the pen be used in space? Will it be used underwater? What kind of paper will it be used to write upon? What color is the paper? (Writing on black paper with black ink is not very useful….). How do we stop it from writing (so we don't get a pocket full of ink)? Have we omitted any inputs or outputs of a pen?
Once the behaviour of a system are determined and specified, then the black box can be opened to reveal its internal workings. Of course, there isn't really anything there yet – we still have to design it! But it is only after we have determined the system's inputs and outputs that we proceed to design the system itself.
Designing a system consists of finding transformations that convert the available inputs into the required outputs. In the early stages of design, these transformations are best described as actions the system has to take to convert inputs to outputs, while making as little commitment as possible to how these actions will be carried out physically.
Exercise for the reader: Consider the pen again. How can the forces that are inputs be transformed into writing? Where does the ink come from? How can forces be used to renew the supply of ink when it runs out? One way of getting the pen to write is to use the forces to cause friction between a part of the pen wetted with ink and a sheet of paper. How does ink get delivered to the wetted surface? Do we use human forces to get the ink to the wetted surface, or is there another force we can use? Did we include that force as an input to the overall system?
This leads us to setting up a set of subsystems, which are components of the overall system. Each subsystem takes some inputs and converts them into some outputs. By piecing together these subsystems, we can fully define the overall system.
We can then imagine subsystems of a pen might be
Notice how each of these subsystems is specified in terms of what they do within the pen system. At the level of each of these subsystems, the pen itself is in the environment.
Each subsystem is itself a black box. To continue the design, we have to open all those black boxes and repeat the procedure (i.e. system design is a recursive process). Eventually, we reach a point where the subsystem components are either (a) no longer systems themselves (they can be implemented with a single part) or (b) we have a fixed, available solution for implementing the particular component.
Exercise for the reader: What are the sub-subsystems of the ink storage subsystem mentioned above? Are there any?
Now, we start working back up towards the overall system. Starting at the smallest level of subsystem, physical components are assigned to each system component, and assembled to constitute subassemblies. These subassemblies are in turn assembled to form higher level assemblies until we reach a single assembly representing the overall system being designed.
The ink storage subsystem gives rise to the ink cartridge, the cartridge's writing tip arises as the delivery mechanism, when combined with the cartridge itself (notice how multiple functions are provided by one single physical component). The pen's “body” or shell provides a housing to provide structural integrity to the other components.
Here is another example. In designing an elevator, the first level of design will require development of requirements and design concepts for the elevator system as a whole (i.e. not just the elevator cab). Once a winning concept has been established through the use of the decision matrix, the overall system which has been a black box up to now, is opened the various subsystems are identified, each subsystem providing one or more of the overall system functions.
The elevator's cab would constitute one of many subsystems in the overall elevator system. The cab provides a number (but not all) the functions expected of the overall system. The cab now becomes the product being designed. So long as the design of the cab proceeds so that it provides all the functions expected of it, then any suitable design of the cab will fit into the overall elevator system design.
Consider figure 2 of a gas station. Note that some of the system elements have been indicated. A gas station is a far more complex system than just a place to pump gasoline into cars. If you're going to design a good gas station, you need to understand how it performs as an element of a bigger system before you can figure out what the gas station will look like and how it will work.
The gas station has inputs of gasoline, cars and other vehicles in need of gas, people (customers, employees, passengers, etc.), other products (snacks for the shop, air to fill one's tires, possibly a car wash — what does that require as inputs), electricity, information (via computer connections to set the price, say, or to validate credit/debit card purchases).
Even the environment (the local environment, at least) can be thought of as an input2).
It has many outputs too: vehicles with full gas tanks, employees who have earned a living, environmental damage, revenue and profit for the owners, certain waste products (e.g. sewage from the customers-only washrooms, dirty water wiped from the windshields of cars, candy wrappers from snacks purchased at the snack shop….)
What's more, the gas station itself is made up of subsystems that all have to work together properly. Each pump at the gas station is itself a system that has inputs and outputs. You can probably guess what they are.
Now consider this. A system transforms its inputs to its outputs. A gas pump changes a car by filling its tank, thereby transforming the car between two different states. So the pump takes the car as an input.
This is certainly true, but there is something new about this situation that changes things a little: the pump interacts directly with the car. The interaction is a transmission of gasoline (from a reservoir) through the pump and into the car's gas tank. This means it makes more sense to think of the pump and the car as two subsystems of the same larger system, which interact with each other.
So, from the point of view of the gas station as a whole, the car is an input; but from the point of view of the gas pump, the car is another system with which it interacts. This may sound confusing, but it isn't so long as you carefully keep track of which system you're thinking about.
Here is a rule to help keep things straight:
So, systems do not only interact with one another, but can be inputs and outputs of other systems.
Exercise for the Reader: Try to describe how a car interacts with a gas station, without mentioning a subsystem of the gas station, and without mentioning a function that is handled by a subsystem of the gas station.
There are lots of other examples of this sort of change. The driver of a car is input to it as a whole, but becomes a component of the car and interacts with its subsystems. Batteries are inputs to a flashlight, but once installed become a subsystem of the flashlight. A CD-ROM is input to your computer, but once it's in there, it becomes a component of the the computer's “file system”.
Exercise for the reader: We've seen how the pump changes the car. But the car cannot pump gas itself. That's where the user comes in. How does the pump change its user? Is the user best thought of as an input/output of the pump, or as an interacting co-system.
In other words, as Amory Lovins says, “People don't want heating fuel or coolant; people want cold beer and hot showers.”
Indeed, we can't know what a product will look like until we understand what it's supposed to do.
Of course, we will often use nouns to represent a system, like “gas station” and “car.” But these are very general nouns that capture the essential purpose of the product, and not the actual structure of it. They're labels and little more at this point in the design process, that stand for functions that most of us take for granted. (You wouldn't use a “car” to drive a nail into a piece of wood, and you would not ride a hammer to school!)
So systems are about functions, not (yet) structures.
Now here, we come to an interesting feature of systems (functional things) versus products (structural things): the individual parts of a product can be elements of more than one system at the same time. This is easily shown by example.
Consider an overhead projector, like the one shown in figure 3. It has a hard outer shell. This outer shell is probably made of a few pieces of metal or plastic. Each piece of the shell could itself part of several different systems simultaneously. The shell pieces may be part of:
This is an important distinction to be made: physical parts of products are not necessarily just elements of one system, but can simultaneously be elements of many different systems. And since each system provides different functions, then such product parts are multi-functional.
Developing multi-functional parts is a good way to improve the quality and robustness of a product while also lowering its cost. And it comes from having a systems perspective.
Exercise for the reader: Here are some other examples of simple systems that you may see with every day, listing some of their subsystems. Do you understand why the subsystems are there? Do you see any subsystems missing?
Exercise for the reader: For each item below:
Then think about or discuss any difficulties you had in grouping parts into systems. Why do you think that might be?
When we design something, we're planning to create something that is new to the environment in which it will be used. If the things we design are systems, then our products transform the environment.
Since engineers' first ethical duty is to the public good, we need to design products that will transform their environments in beneficial ways. This means we must understand why we are introducing the new product — what transformation do we want to happen?
So we need to understand what the environment currently is — how things are. Then we must set down a preferred environment that will result from a product being added to that environment. The product will transform the current environment to the new and preferred one.
But a product can only change parts of the environment.
Thought Experiment: Think of a product you recently purchased. Think of how this product is beneficial to you. Now think of other things in your life that are not affected at all by that thing you bought.
Even if a product is beneficial in some ways, it will probably be harmful in other ways3).
When we design things, we have to design them to work harmoniously with other things in a the environment. We have to find designs that balance the benefits of the product's use against the damage it can also cause.
Since systems design makes us think in terms of transforming the environment, it is an excellent way to help us design products that work well, harmoniously, in their environment.