<aside> đźš© A system interface is a specification of a flow of mass, energy, or information into or out of a system.

</aside>

Overview

<aside> <img src="/icons/info-alternate_blue.svg" alt="/icons/info-alternate_blue.svg" width="40px" /> Be sure to have read about Systems and System Inputs and Outputs before reading this page.

</aside>

A system interface describes the quality and quantity of a flow into or out of a system. It is how we document the inputs and outputs of systems.

The quality of an interface is its nature, and is usually quite easy to determine. Does it represent a flow of mass, energy, or information? If you know more about the flow, specify it. For instance, if you know (i.e., can justify with robust evidence) that a particular interface will carry electricity, then call it “electricity”, not “energy”; if you know a particular interface is for humans to enter or exit an intervention, then call the interface “human users”, not “mass”.

The quantity of an interface is usually harder to determine, and usually requires research, calculation, and critical thinking.

When we say that we “quantify” interfaces in engineering design, we are not only talking about quantities that have units, like “3 kg/hr”. In design, quantities can be:

You decide whether a flow is one of mass, or energy, or information depending on the intended purpose of the flow.

Example: a calculus textbook

For instance, consider a thick calculus textbook, which I give to you. The textbook is obviously a mass. However, the reason I give it to you defines whether we should model the flow of the textbook from me to you as one of mass, or energy, or information.

We model interfaces this way to help open up possibilities for creative innovation. That is, by giving you the textbook to burn to stay warm, we open the possibility of finding other things you might use to stay warm, some of which might be much better suited to that goal than burning a calculus textbook.

Example: user commands for an elevator

If we were designing an elevator, one necessary input would be commands provided by the user. Specifics would depend on the contents of the Design Brief, but one possible complete quantification of the user commands for an elevator might be:

Notice that the interface quantification doesn’t specify how the commands are transmitted from the user to the elevator or even how they are triggered by the user. It only describes the information that constitutes each command.

Notice also that this interface specification applies to both of the systems (i.e., the user and the elevator) that participate in the interaction. That is, for each command a user sends to the elevator, we must design a way for the elevator to receive and understand it.

Example: an electric motor for an elevator

Let us assume that we have robust evidence that the power for an elevator we are designing must come from electric motors. We might reasonably then research what the building that will house the elevator can provide, and find the following characteristics of the electricity supply:

Notice that these are not the characteristics of the electric motor, but rather the characteristics of the supply of electricity. This is something you can’t control because it comes from outside the system you’re designing.

Notice also that the current, voltage, and frequency are specified as ranges. This is because in real life, the electricity supply will vary depending on many environmental factors. If you are going to configure an appropriate electric motor, it must respond to the available inputs safely and robustly; that means you have to know what those ranges are before configuring the motor.