Why the boundary comes first
Before analysing any design, you need to say what you are analysing. A system boundary is the line that separates the things you are responsible for, the system, from everything it interacts with but you do not control, the environment. The line is a choice, not a fact of nature, and a different choice gives a different problem.
Consider a room heater with a thermostat. If the boundary encloses only the heater, the room air is the environment, and room temperature is an input you cannot influence. If the boundary encloses heater, thermostat and room, temperature becomes an internal variable and the question changes to how well the whole arrangement holds a set point. Both views are valid. They simply answer different questions.
Inside, outside and the line between
A useful way to draw the boundary is to sort things into three groups.
- Inside: parts you can design, specify or change.
- Outside, but influencing: things you cannot change but must accommodate, such as ambient temperature, users, mains supply, other equipment or regulations.
- Outside, and irrelevant: things that do not affect the design in any way that matters to the question at hand.
The middle group deserves the most attention. Most surprises come from outside factors that were never written down because everyone assumed they were obvious. Listing them explicitly, and noting who owns each one, turns vague assumptions into items someone can check.
A quick test for any candidate item is to ask whether you can change it, and whether the system’s behaviour depends on it. If you can change it, it is probably inside. If you cannot change it but behaviour depends on it, it is an environmental input to record. If neither is true, leave it out.
What a block diagram shows
A block diagram is a simplified picture of a system as boxes connected by arrows. Each box represents a function or a part, and each arrow represents something passing between them. It deliberately leaves out internal detail. Its value is that it fits on one page and can be understood by people from different disciplines.
A few conventions keep a diagram readable.
- Draw the boundary as a clearly different line, such as a dashed rectangle around everything inside.
- Place environmental items outside that rectangle, so it is obvious what the design depends on.
- Label every arrow with what flows along it: power, a signal name, a material, a request, a document. An unlabelled arrow invites each reader to imagine a different flow.
- Show direction. If something flows both ways, use two arrows or label both directions.
- Keep boxes at a similar level of detail. A box called “controller” next to a box called “resistor R7” signals that two levels are mixed.
There is no single required style. Teams often adopt their own, and consistency within a project matters more than which convention is chosen. Good presentation matters as much as content, as with any set of engineering diagrams.
A small worked sketch
Take a simple automatic plant-watering device. The following is an illustration only.
Inside the boundary:
- a soil moisture sensor
- a controller
- a small pump
- a water tank
- a power supply module
Outside the boundary, but influencing:
- the soil and plant, which determine how fast moisture changes
- the mains outlet or battery that supplies energy
- the user, who refills the tank and sets the target moisture
- room or outdoor temperature, which affects evaporation
The arrows would then be: moisture reading from sensor to controller, on/off command from controller to pump, water from tank through pump to soil, power from supply to each active part, and the user’s setting into the controller. A further arrow, water leaving the soil, shows the environment acting back on the sensor.
Even this small sketch prompts useful questions. What happens if the tank runs dry and the pump keeps running? Who is responsible for noticing? The user is outside the boundary, yet the design relies on their refilling the tank. Because that dependency is visible on the page, it can be handled deliberately, perhaps with a low-level indicator, rather than discovered later.
Choosing a level of detail
A single diagram cannot serve every purpose. A common approach is to draw a top-level view with a handful of blocks, and then draw a more detailed diagram for any block that needs it. Each lower diagram should account for every arrow entering or leaving the block it expands, so that nothing disappears between levels.
Some practical guidance:
- Aim for a number of boxes a reader can take in at once. Many people find that somewhere around five to nine is comfortable, though this is a rule of thumb, not a law.
- If a box needs a paragraph to explain, it is probably doing too much and should be split.
- If two boxes are always changed together, consider whether they are really one function.
Common mistakes
- Leaving out the environment. A diagram that shows only the design makes it look self-contained. Failures often originate in what was omitted.
- Moving the boundary mid-discussion. When people silently use different boundaries, they talk past each other. State the boundary and keep to it.
- Arrows that mean different things. Mixing power, data and control in unlabelled lines hides important differences.
- Treating the diagram as finished. It is a working tool. Update it when understanding changes, and avoid letting an outdated version circulate, which is the diagram form of stale documentation.
- Confusing a diagram with a design. A block diagram records intent and structure. It does not prove that the connections work.
Using the diagram with others
The most useful thing to do with a block diagram is to put it in front of someone who did not draw it and ask them what is missing. People on the other side of an arrow often spot a wrong assumption quickly. The diagram also gives design reviews a shared starting point, and it can seed the careful definition of system interfaces, since every arrow crossing a box edge is a candidate interface to specify.
Practices and standards for safety-related or regulated products vary by country and industry. This article is general background, and projects of that kind should follow the standards and professionals that apply to them.