Many Boolean minimization errors begin before the K-map is drawn. A word problem uses everyday terms such as “and,” “unless,” “only when,” or “either,” and a designer may turn those phrases into an expression without agreeing on what each input means. The map then simplifies a misread requirement perfectly.
This worked example translates a small alarm specification into named Boolean variables, a complete truth table, a minterm list, and a minimized SOP expression. It shows how to preserve conditions, distinguish inclusive OR from exclusive OR, and verify the result against edge cases. The same sequence applies to sensor logic, interlocks, status lamps, and exam questions.
Write the specification precisely
Suppose a small heating system must turn on an alarm under either of two conditions: the system is armed and the access door is open, or the heater is enabled and the measured temperature is above a limit. The alarm should be high when at least one complete condition is true. If both conditions are true, the alarm remains high; no priority is specified between them.
That last sentence matters. “Either condition” in ordinary language can sometimes mean exactly one, but this specification says “at least one” and explicitly allows both. The Boolean operator is inclusive OR. If the requirement instead said “alarm only when exactly one condition is true,” the function would be XOR of the two condition expressions and the truth table would differ.
Before translating, list assumptions. Treat each input as a Boolean signal already representing its physical condition. “Armed” is a 1 when the system is armed; “door open” is a 1 when the door is open; “heater enabled” is a 1 when heating is permitted; “over limit” is a 1 when temperature exceeds the threshold. Sensor filtering, hysteresis, and analog threshold behavior are outside this combinational function and need separate specifications.
Define input and output meanings
Use variables A,D,H,T and output Z:
- A=1: alarm system is armed.
- D=1: access door is open.
- H=1: heater is enabled.
- T=1: temperature is above the specified limit.
- Z=1: alarm should be asserted.
The variable order for minterm numbering will be A,D,H,T, with A most significant and T least significant. State it now. Without a defined order, the minterm indices are ambiguous. The output condition is Z=1 when (A and D) or (H and T), so the direct expression is Z=AD+HT. The plus sign denotes OR, and adjacency denotes AND.
This formula preserves both complete conditions. `A+D` would be too broad because either arming alone or an open door alone would activate the first branch. `ADH T` would be too narrow because it would require both conditions at once. Parentheses in the prose map to product terms; the phrase “or” joining the conditions maps to the sum of those terms.
Translate conditions to logic
Break the sentence into independent clauses. “The system is armed and the door is open” becomes AD. “The heater is enabled and the temperature is above the limit” becomes HT. “At least one of the conditions” becomes AD+HT. This clause-by-clause translation makes it easier to compare every term to a phrase in the requirement.
Negations must be attached to the right variable. If the alarm should sound when the door is closed while armed, use AD′, assuming D=1 still means open. If the alarm should sound when temperature is at or above the limit, define T accordingly; a strict “above” versus “at or above” threshold is an analog comparison requirement that must be decided before the digital logic receives T.
For a more complex statement, make an intermediate table of conditions before expanding to all input rows. Named conditions such as C1=AD and C2=HT can prevent a long sentence from becoming a fragile string of symbols. But the intermediate names do not replace the original input variables when creating a K-map; the map axes still correspond to A,D,H,T.
Build and inspect the truth table
There are four inputs, so the complete table has 16 rows. The alarm is high in four rows where AD=1, four rows where HT=1, and one row where both are true, for a total of seven on-set rows because the overlap is counted once.
| AD | HT | Number of underlying input rows | Z | Interpretation |
|---|---|---|---|---|
| 0 | 0 | 9 | 0 | Neither complete condition is true |
| 1 | 0 | 3 | 1 | Armed door-open condition only |
| 0 | 1 | 3 | 1 | Heater over-temperature condition only |
| 1 | 1 | 1 | 1 | Both conditions are true |
This compact table groups the 16 rows by the values of the two clauses. To create the actual minterm list, use the declared order ADHT. Condition AD covers assignments 1100,1101,1110,1111, which are minterms 12,13,14,15. Condition HT covers 0011,0111,1011,1111, or minterms 3,7,11,15. Their union is {3,7,11,12,13,14,15}; minterm 15 appears in both clauses but is listed only once.
Convert rows to minterms
The canonical SOP is Z(A,D,H,T)=Σm(3,7,11,12,13,14,15). Verify each index by binary conversion. Minterm 3 is 0011, where H=T=1. Minterm 12 is 1100, where A=D=1. Minterm 15 is 1111, where both conditions hold. These anchor rows check the two branches and their overlap.
Write the zeros too: {0,1,2,4,5,6,8,9,10}. A candidate expression must be 0 on every one of those rows. This is a useful check against an overly broad interpretation. For example, A+D would be true at minterm 8 (1000), where the system is armed but the door is not open; that row should not trigger this condition unless the specification says otherwise.
If input variables are active-low at the hardware pins, first convert pin levels into the logical meanings A,D,H,T or explicitly build the complements into the expression. A physical `DOOR_N` signal may be 0 when the door is open; in that case the logical open condition is DOOR_N′. Signal names should reveal polarity wherever possible.
Minimize on the K-map
Place the seven 1s on a four-variable K-map with AD as rows and HT as columns, both in Gray order 00,01,11,10. The four minterms 12,13,14,15 form a 2×2 group where A=1,D=1 and H,T vary. That group yields AD. The minterms 3,7,11,15 form a group where H=1,T=1 and A,D vary, yielding HT. The two groups overlap at m15, which is valid and necessary to express the inclusive OR compactly.
The minimized expression is therefore:
Each group has four cells, so each product term retains two literals. There is no single group of eight covering all seven 1s without including a zero; the two pairs of conditions vary independently. The two-term expression matches the clause-by-clause translation, and the K-map confirms that it is already a natural minimum SOP.
Minimization can sometimes produce a form that is not visually identical to the original sentence. That is fine if the truth table matches. Conversely, if a group includes a zero row, revisit the variable order, Gray-code layout, or source minterm list before accepting the result. Map geometry is only reliable when the cells were placed correctly.
Test edge cases and ambiguity
Test each single condition. If A=1,D=0,H=0,T=0, then Z=0; arming alone is not enough. If A=0,D=1,H=0,T=0, then Z=0; an open door alone is not enough. If A=1,D=1 and H=T=0, Z=1. If H=T=1 with A=D=0, Z=1. If all four inputs are 1, both clauses are true but Z is still 1, not 2; Boolean OR has no arithmetic double-counting.
Now test the word “unless.” If the requirement said “alarm when armed and door open unless maintenance mode is active,” and M=1 means maintenance, one possible interpretation is ADM′. But natural language can mean that maintenance suppresses only the door condition or suppresses the entire alarm. Ask what the exception modifies and write the requirement as an explicit truth table before mapping it.
Similarly, “either” can mean inclusive OR or exclusive OR. If the alarm should assert when exactly one clause is true, use (AD)(HT)′+(AD)′(HT). If both true should also assert, use AD+HT. The K-map cannot infer which meaning was intended; requirements wording must resolve it.
A reusable translation method
- Extract the input conditions. Define each variable with its asserted meaning and polarity.
- Rewrite the prose as clauses. Keep each “and,” “or,” and exception visible.
- Resolve ambiguous words. Clarify inclusive/exclusive OR, priority, thresholds, and exceptions.
- Choose a variable order. Record it next to every minterm list.
- Fill the truth table. Enumerate all input combinations or use a logically complete reduced table.
- Convert output rows to minterms. Check binary indices and include overlap only once.
- Draw and minimize the map. Use Gray order and legal groups.
- Test positive and negative examples. Check both intended trigger cases and tempting non-trigger cases.
For a sequential system, first distinguish current-state conditions from input conditions; a state register may be required. For multiple outputs, repeat the truth-table and K-map process for every output, then consider whether product terms can be shared. For don't-cares, record why a row is genuinely unspecified rather than omitting it accidentally.
Turning prose into logic is a modeling task before it is an algebra task. The alarm example ends with a simple expression, but the confidence comes from defined signal meanings, an explicit variable order, a complete on-set, and edge-case checks. Once those are correct, the K-map provides a clear and auditable simplification.
When assumptions belong in the design
The four-variable function assumes that all combinations of armed state, door position, heater enable, and over-limit indication are possible inputs to the logic. A system engineer might say that an over-temperature signal cannot occur while the heater is disabled, but that may describe normal operation rather than a guaranteed invariant. If the combination can occur during reset, sensor fault, or test, define the alarm response instead of silently marking the row X.
Similarly, the Boolean variable T represents a digital comparison result. The threshold comparator has its own behavior near the boundary, including hysteresis or filtering if required. Keeping the analog measurement layer separate from the alarm-combination layer clarifies what the K-map proves and what remains a sensor or interface requirement.