This topic is about systems that sense something, decide, and act without a person pressing every button. A greenhouse fan, an automatic door and a plant-watering controller all follow the same pattern: sensor, processor, actuator, with a rule in the middle.
It sits after internet security and responsible use and before algorithm design in the Computer Science learning guide. The reasoning here, reading a rule and tracing what it does, is the same reasoning you will use in every algorithm question.
What should you know before starting?
You should be comfortable with input, process and output as ideas, and with the difference between analogue and digital data. You should also be able to read a simple IF statement.
If an IF statement still looks unfamiliar, spend ten minutes with the pseudocode trace trainer first. It steps through small original algorithms and shows each variable changing.
One orienting example
A greenhouse controller reads the temperature every minute. The rule is: if the temperature is above 30 °C, switch the fan on, otherwise switch it off.
The temperature sensor measures the air. The processor compares each reading with 30. The fan motor is the actuator that does the work.
For the readings 24, 27, 31, 29, 26 the fan states are OFF, OFF, ON, OFF, OFF. Only 31 is above 30. Every other lesson in this module adds one idea to this picture.
In what order should you study the lessons?
- Trace sensor processing and actuator stages: learn the chain and trace one rule by hand. Everything else depends on this.
- Distinguish feedback from a fixed sequence: see why some systems check the effect of their own output and others do not.
- Explain a simple decision model: move from one rule to several inputs and a decision table.
- Assess data quality in an automated system: find out what happens when a sensor gives a bad reading.
- Label 2029-only additions rather than projecting them into papers before 2029: keep notes tied to the right syllabus year.
Then try the mixed practice set and log wrong answers in the mistake log.
What traps catch students in this topic?
- Naming the processor as the sensor. The sensor only measures. The decision happens in the processor.
- Calling every automatic system “feedback”. A timer that runs for ten minutes whatever happens is not feedback.
- Ignoring boundary values. A rule using “above 30” treats a reading of exactly 30 differently from “30 or above”.
- Trusting every reading. A faulty sensor can send a value that is impossible, and a rule will still act on it.
- Using a note from the wrong year. Label what you study, then check it against your syllabus.
How to use the practice set
Attempt each question on paper first. Write the trace table before you look at any answer. Then check the working, not just the final line, and note which lesson each error belongs to.
If you want a teacher to look at how you reason through these scenarios, our online one-to-one Computer Science tuition is built around tracing and debugging your own attempts.