Programming a product
Design & Technology · Key Stage 2 · The School
Input, process, output
A sensor takes an INPUT. The program PROCESSES it. Something happens — an OUTPUT. A security light: sensor detects movement, program checks whether it is dark, light turns on. Nearly every electronic product is this three-part shape.
Conditions
IF it is dark AND movement is detected THEN turn the light on FOR thirty seconds. That single line contains a condition, a logical AND and a timer, and those three cover a large share of everything embedded software does.
Why products are programmed
A programmed product can be changed without rebuilding it, can respond to conditions, and can do different things at different times. The cost is that it can also fail in ways a mechanical product cannot — which is why a good design asks what happens when the program stops.
INPUT: a light sensor reports how bright the room is. PROCESS: the program compares that reading with a threshold, and also checks a switch so the user can override it. OUTPUT: an LED turns on. Now change ONLY the process — add "and only between 7pm and 7am" — and the same components become a different product. That is what having a computer inside buys you.
What happens when the sensor is wrong
A real product has to cope with a sensor that reports nonsense. A security light whose sensor sticks ON leaves the light burning all night; one that sticks OFF leaves a dark path. Good programs plan for both: a maximum on-time so a stuck sensor cannot drain the battery, and a manual override so a person can take control. This is the part of programming a product that separates a working prototype from something you would sell. Ask of any design: what does it do when the input is impossible, and what does it do when the power comes back after a cut?