The interface between two (or more) systems describes how the systems “communicate” by allowing mass, energy, and information to flow between them.
A system transforms its inputs into its outputs.
Fig. 1: A schematic model of systems, interfaces, and boundaries.
In figure 1, we have a schematic model of how two systems “connect”1).
Example: When you plug an appliance like a blender into a wall outlet, the blender system will interact with your home's electrical system.
Since systems are black boxes2), we do not know or care how a system provides its interface; we only really care about the interface itself.
In engineering design, we only care about three principal types of interfaces: mass, energy, and information. There are other types of interfaces that may concern other specialists, but we do not need to worry about them.
Interfaces are functional in nature, not behavioural. That is to say, they describe, in quantitative terms, the purpose for the input or output3).
Exercise for the reader: How many different commands can you think that the user of an elevator might need to be able to transmit to the elevator system itself?
Interfaces let us describe what a system is supposed to do to be useful as an element of a larger system.
These are just some examples of products with mismatched interfaces for the situations in which they are to be used.
Furthermore, as we recurse down to lower, more detailed levels of a design project, each preceding level of user interface provides the foundation for the requirements we will need at the lower, more detailed levels.
Finally, quantitative specifications of system interfaces will also be essential in the next stage of the design process (concept design) when we seek out ways to implement the functions that the systems have to provide, because the quantity of flow through an interface will help us decide what technologies we can use to implement those interfaces.
Since design is about solving existing problems (or improving identified imbalances), we can only specify interfaces when we know what systems will be interacting, and why they will interact. It is best, then, to first identify interacting subsystems, and then figure out exactly how those subsystems will interact, constrained by the requirements of the problem and the product strategy for the project.
Because of the richly interconnected nature of system interfaces, specifying them is a task that is best done as a team exercise, with everyone present.
Also, because systems are functional units, interface specification should be done before concept design, when embodiments are developed. (Indeed, coming up with good embodiments rather depends on there being well-defined system interfaces.)
Fig. 2: A system diagram of an elevator system just before starting to specify interfaces.
We specify interfaces on system diagrams, where we can graphically show the flows, in conjunction with supporting documentation. Assuming you have already identified what the inputs and outputs are to your overall system, there are three steps to specifying interfaces:
Each of these is described below.
The first step is to draw arrows on your system diagram denoting the various flows.
Matter and energy can be neither created nor destroyed, so every bit of mass and energy that goes into your system must come out somehow. Information, on the other hand, can be completely “consumed” (or “created”) by a system.
Consider figure 2.
The designer's job is to figure out how to route each flow through the subsystems till it comes out as an output.
There are two ways to figure out the routing of the flows through the system.
You must use both methods to help ensure that you have identified all the significant flows.
Fig. 3: A relatively complete [[system diagram]] showing the principal interfaces between subsystems for an elevator.
One possible architecture for the elevator system is shown in figure 3.
Some notes on figure 3 are in order.
To keep the system diagram tidy, label each flow with a number ID, as in figure 3. You then use a separate sheet or sheets to describe each flow in detail.
Consider the user commands
information input in figure 3. You can develop a complete list of every possible user command that any user, as exemplified by your personas and usage scenarios, could ever need to “tell” the elevator system.
User Interface
subsystem for processing.feedback to users
, which must also be exhaustively defined.
Consider the User Interface
subsystem. In addition to receiving commands
and produces feedback to users
, it also sends commands
to, and receives feedback
from, the Control System
.
user commands
and feedback
.Control System
electronics, one that the Control System
interprets in a specific way. This information could be completely different from the information exchanged between the User Interface
and the users.Obviously, not all the details of the interfaces will be known at the beginning of the design process.
commands
is not acceptable; there must be a good reason for making that choice.
Exercise for the reader:
Note the information flow going from the Shaft
and Cab
to the control system. Can you explain what roles are served by this information flow? Can you specify what kinds of information would constitute that flow? How could you justify those specifications?
The electricity
input splits three ways within the boundary of the elevator system.
Exercise for the reader: Are there any other subsystems that might need electric power, besides the three specified in the system diagram? Are these errors? Or can you imagine how the diagram might be correct as is?
The mass inputs of air
and people & cargo
are kept separate because the designers expect to treat air differently from people and cargo.
Exercise for the reader: What would be implied about the elevator's operation if they had been specified as a single mass input to the system?
The three kinds of waste energy output, heat noise friction
, are treated as a single output because the designers' experience tells them that these waste energies will be comparable in quantity with respect to the behavioural limits of the system.
Given that each flow in a system diagram has a numeric ID, as in figure 3, we can now use a simple numbered list to exhaustively quantify each interface.
Since these interfaces will end up being the foundation of the requirements for the subsequent design of the subsystems, it is very important to quantify the interfaces as crisply as possible.
You may find that some of the interfaces have already been specified in the requirements for your design. In that case, you can just refer to the specific requirement; you should never duplicate information.
When we say “quantify” in engineering design, we are not only talking about quantities that have units, like “3 kg”. In design, quantities can be:
30 kg/hr
or 120V / 15A / 60 Hz
;
For instance, here is one possible specification of the user commands
flow in figure 3 for the elevator system:
1. user commands
This list describes every possible function that a user could request of the elevator.
Here is another example, this one for the electricity that powers the lifting system4).
3. power to lift system
While this specification is more than what most student teams would generate, we include this to show the extent of the information that might be needed in real life5). Some notes are in order:
See the Deliverables section of the PAS.
There are some particular hazards in defining interfaces.
The most significant is in knowing when to branch an input or output, and where to put the branch. Putting a branch within a system boundary implies that the designer of that system bears the responsibility of (and control over) that particular branch. Also, branching (or merging) implies a more physical confluence of the corresponding flows. Any such confluence requires careful thought (as in the example of merging the flows of air
and people and cargo
in our elevator design).
Another typical mistake is to overspecify an interface by grounding it in physical artifacts or properties that cannot be justified yet. For instance, if you are designing a car, and you have not been constrained to use gasoline to power the car, then it would be a mistake to define a gasoline flow into the car. It would be more appropriate to specify an energy input into the car, because while the car needs energy to work, you have not yet decided exactly how that will be done.