aiMOOC

Modelling and decomposing a physical system - Computing Year 6

QR-Code

Introduction

How could a lamp respond to a changing light reading while remembering whether its automatic mode is enabled? Before programming, divide the problem into parts and specify the data each part needs.

Create a model that identifies inputs, stored state, processing and outputs. Trace several successive steps, including a boundary and an invalid reading, and explain which real-world details your model leaves out.

This is an editorial Year 6 route within England's key-stage-2 computing programme. The whole task is a paper or software simulation: do not connect, modify or control a real lamp, electrical circuit or robot. No hardware or public account is required. The invented zero-to-one-hundred brightness scale and threshold are teaching choices, not real lighting recommendations.

Describe the system and choose useful abstractions

A physical system contains real objects interacting, such as a light sensor, a controller and a lamp. A model represents selected features of a system so that a question can be explored. It is not the real object, and it is only useful within its stated assumptions.

Our invented automatic-lamp model answers a narrow question: for the supplied brightness and mode command, what lamp status should be displayed? We represent darkness by smaller whole-number readings and brighter conditions by larger ones on an artificial scale from zero to one hundred. We do not claim that a reading measures lux, energy use or the physical brightness of a particular room.

Inputs arrive from outside the model. They are a brightness reading and a command: Enable, Disable or Hold. Enable turns automatic mode on; Disable turns it off; Hold leaves the mode as it was. The user may supply these on paper or through software controls. No actual sensor needs to be connected.

State is information retained between steps. The Boolean enabled state starts false. False means automatic mode is disabled; true means it is enabled. Holding the previous value makes later behaviour depend on history as well as on the newest brightness reading.

Outputs are the displayed lamp status ON or OFF and a status message. Our model has no electrical output. In a real controlled system, an output device or actuator might affect the physical world; this course only displays a representation.

Keep what matters for this question

The enabled state, brightness value and decision boundary matter. The photographed lamp's decorative colour does not affect our specified rule, so we omit it. This is abstraction: selecting details relevant to the purpose. It does not mean that lamp design, sensor placement or power supply never matter in a real product.

The model deliberately omits response delay, sensor noise, electrical design, illumination requirements and the effect of the lamp's own light on a sensor. A successful trace cannot establish that an actual device is safe or effective. A later engineering project would need different information and authorised practical testing.

Decompose the job and agree the interfaces

Decomposition divides the problem into manageable parts. A useful part has a specific job, defined inputs and a checkable output. Dividing work between friends is not enough if nobody has agreed what one part returns to the next.

Part	What it receives	What it returns
Read the next step	Fictional brightness and command	Two candidate input values
Validate the input	Candidate values and allowed rules	Valid values or an error
Update enabled state	Previous enabled value and valid command	New enabled value
Decide lamp status	New enabled value and valid brightness	ON or OFF
Display and record	New state, lamp result and message	A visible result and trace row

An interface is the agreement about what crosses a boundary between parts. The validator must not return a vague 'something went wrong' while the decision part guesses that missing data means darkness. Agree the result types and error behaviour explicitly.

State the complete rules

The core model accepts only whole-number brightness readings from zero through one hundred and the three named commands. Start with enabled false. For each step:

Check both candidate inputs before changing enabled.
If either is invalid, leave enabled unchanged, display lamp OFF and report Input error. Finish that step.
Otherwise, Enable sets enabled true, Disable sets it false, and Hold keeps its previous value.
If enabled is true and brightness is less than thirty, display lamp ON with Automatic light on.
In all other valid cases, display lamp OFF with either Automatic mode disabled or Bright enough, according to enabled.
Record the resulting state and output before accepting another step.

The word and matters: both enabled and the low-reading condition must be true for ON. At exactly thirty, 'less than thirty' is false. A valid high reading switches the displayed lamp OFF even if automatic mode remains enabled. Mode and lamp status are related but different.

This original Code.org film explains input, memory, processing and output more broadly. Use it to identify the roles in our model; it is not a wiring guide or a demonstration of this lamp rule. The written model and traces provide an independent route through the task.

Represent the state and trace successive steps

A model needs more than an input-output arrow when it remembers earlier events. Write the stored enabled value beside your diagram and show that the next step receives the previous step's resulting state. The command Hold means preserve that value, not set it false.

A simple text diagram is: candidate inputs → validation → state update → lamp decision → displayed output and trace. A separate state arrow returns the enabled value to the next step. An error exits through OFF and Input error without updating enabled. This is a representation of data flow, not a physical wiring diagram.

Work a complete sequence

Start disabled. Use the same state through all six rows below; do not reset between them. The readings are fictional inputs, not observations of a real room.

Step	Command	Brightness	Enabled after update	Lamp output	Reason
1	Hold	20	False	OFF	Mode is still disabled
2	Enable	20	True	ON	Enabled and below 30
3	Hold	45	True	OFF	Bright enough under the model rule
4	Hold	10	True	ON	Mode retained; reading below 30
5	Disable	10	False	OFF	User disables the mode
6	Hold	5	False	OFF	Disabled state persists

Steps one and two use the same brightness yet give different outputs because the state changes. Steps three and four keep the same enabled value yet give different outputs because brightness changes. Step six shows why looking only at the latest low reading is insufficient.

Try first: Insert Hold with brightness thirty after step two. The state remains true but the lamp output is OFF, because thirty is not less than thirty. Do not confuse automatic mode remaining enabled with the lamp remaining on.

Trace invalid input with the stated order

Suppose enabled is false and a new step supplies Enable with brightness 101. Validation fails before any state update. The result is enabled still false, lamp OFF and Input error. If you updated enabled before validating, you would implement a different rule.

Now suppose enabled is true and Hold arrives with brightness minus one. The result is enabled still true, lamp OFF and Input error. The following valid Hold at twenty returns to ON under our model. A false output in the error step does not automatically erase the retained mode. Label both pieces of information in a trace.

Test the parts, combine them and explain limits

Test a subtask against its interface before trusting the complete model. For validation, zero and one hundred are allowed whole-number endpoints, while minus one, 101, a fraction and text are outside the specified domain. A software implementation must actually check that rule; writing it beside a diagram does not make an editor validate inputs automatically.

For the state updater, Enable should return true, Disable false and Hold the supplied previous value. Test Hold from both previous states. A design that always sets false for Hold loses the memory the model needs.

For the lamp decision, compare enabled true with readings twenty-nine, thirty and thirty-one. Expected outputs are ON, OFF and OFF. Compare enabled false with the same readings: all three are OFF. These checks distinguish less-than from less-than-or-equal and reveal a mistaken 'enabled or dark' condition.

Test the combined model

Act out the parts with labelled cards, draw a flowchart with the state return, or implement the rule in approved software. For paper work, one person can provide inputs while another updates the state card and output card according to the written rules. Record actual model results separately from predictions. For a digital version, save the implementation and run the same cases.

A combined test should include a disabled low reading, enabling at a low reading, a bright Hold, a later dim Hold, disabling and a final dim Hold. Add the exactly-thirty boundary and invalid-reading tests. Keep the starting state explicit: resetting for each independent test is different from preserving state through a sequence.

Diagnose a fault: If the lamp turns ON during step six of the worked sequence, inspect whether the decision ignored enabled or Hold accidentally restored true. Both can produce a similar symptom. Trace the new state first, then the decision, so your correction targets the first wrong stage. Retest the full sequence after changing one cause.

Evaluate the model rather than overclaim

A real sensor estimates something about its environment and may fluctuate. The Micro:bit Educational Foundation documents a different light-level scale from zero to 255 and an approximate LED-based sensing method. Our zero-to-one-hundred inputs are deliberately invented; they cannot be copied into hardware as calibrated illumination values.

A sequence such as twenty-nine, thirty-one, twenty-nine, thirty-one would toggle the displayed lamp in this simple enabled model. That exposes a limitation near the threshold. A more realistic design might investigate smoothing, different switch-on and switch-off thresholds or sensor placement, but those require a new specification and new tests. They are optional questions, not changes to silently insert into this core model.

Transfer: Change the teaching threshold to forty. Predict enabled-true outputs for thirty-nine, forty and forty-one, update the decision and test them. Explain which parts need to change and which interfaces remain the same.

Finish with a labelled model, a subtask/interface table, an explicit state representation, a trace of successive inputs, tests and a short limitations statement. A paper model is a valid product for this planning objective; identify it as such. It does not establish that an unimplemented program runs or that a real electrical controller is safe.

Interactive Tasks

Quiz: Test Your Knowledge

What is the purpose of the lamp model? (Explore a specified relationship between inputs, retained mode and displayed output.) (!Prove that any real electrical lamp is safe.) (!Measure actual room illumination in lux without a sensor.) (!Control a real robot without permission.)

Which item is retained state in the core model? (Whether automatic mode is enabled.) (!The decorative colour omitted from the rule.) (!A random lamp photograph's file size.) (!A value that is always discarded before Hold.)

What should Hold do to the enabled state? (Preserve its previous value.) (!Always set it false.) (!Always set it true.) (!Ignore every previous step and choose randomly.)

Enabled is true and brightness is twenty-nine. What is the valid lamp output? (ON because both required conditions are true.) (!OFF because every valid reading disables the mode.) (!Input error because twenty-nine is outside the range.) (!ON regardless of enabled in every case.)

Enabled is true and brightness is exactly thirty. What happens? (Lamp OFF while automatic mode remains enabled.) (!Lamp ON because thirty is less than thirty.) (!The model must delete its stored mode.) (!Input error because the threshold is not permitted.)

The mode is disabled and the next valid command is Hold at brightness five. What happens? (It remains disabled and the lamp output is OFF.) (!Low brightness automatically changes Hold into Enable.) (!It must output ON because only brightness matters.) (!The input must be published online before processing.)

Enabled is false and Enable arrives with brightness 101. What do the stated rules require? (Input error, lamp OFF and enabled unchanged as false.) (!Update enabled to true before checking validity.) (!Treat 101 as darkness without explanation.) (!Apply the command to a real lamp.)

Which decomposition has a clear interface? (Validation returns accepted values or an explicit error.) (!One person does everything difficult with no defined output.) (!Every part guesses what missing data means.) (!Display changes hidden state without any stated rule.)

Why can identical brightness readings produce different outputs? (The retained enabled state can differ.) (!Brightness never contributes to the decision.) (!Every step must reset enabled to true.) (!A model cannot have any state.)

With a new threshold of forty, which enabled-true readings best test the nearby boundary? (Thirty-nine, forty and forty-one.) (!Only zero repeated many times.) (!Only one hundred repeated many times.) (!Only unknown commands with no brightness value.)

Memory Game

Model	A representation of selected system features for a stated question.
Input	New data supplied from outside the model.
State	Information retained from one step to the next.
Processing	Applying the specified validation, update and decision rules.
Output	A result communicated, such as displayed lamp status.
Abstraction	Choosing relevant details and omitting others for this purpose.

Drag and Drop

Read inputs	Receives a brightness candidate and a command candidate.
Validate	Checks the allowed numeric domain and named commands before state changes.
Update state	Applies Enable, Disable or Hold to the retained enabled value.
Decide lamp status	Combines the updated mode with the below-thirty condition.
Display and record	Makes the result visible and retains a trace row.

Crossword Puzzle

model	A selected representation rather than the real system.
state	Information kept between successive steps.
input	A newly supplied command or reading.
output	The displayed result of applying the rules.
process	Apply rules to the supplied data and retained information.
sensor	A real device that can provide information about an environment.

LearningApps

Optional extra practice. Choose an appropriate activity with your teacher. If the external collection is unavailable, use the native activities and independent tasks in this course.

Cloze Text

Open Tasks

Easy

Identify the lamp model's components: Name its two inputs, retained state and displayed outputs. Distinguish the model's representation from a real sensor and electrical lamp.
Choose relevant lamp-model details: Select three details required by the rule and two omitted details. Explain why omission is justified only for this stated purpose.
Compare Enable Disable and Hold: Show the new enabled value for each command starting from both false and true. Explain which command depends on previous state.
Predict the lamp threshold boundary: For enabled true, predict outputs at twenty-nine, thirty and thirty-one. Explain the exact less-than boundary.

Standard

Create a decomposed lamp-system model: Draw or build a representation with input validation, state update, decision and display parts. Label every part's input and output and the retained-state connection.
Trace six successive lamp steps: Reproduce the worked sequence without resetting between rows. Keep enabled, lamp output and reason separate; then check the model's actual results.
Model an invalid reading explicitly: Compare Enable at 101 from disabled state with Hold at minus one from enabled state. Apply validation before state updates and state the next valid result.
Find an enabled-state fault: A disabled Hold at five produces ON. Trace state update and decision separately, identify a plausible first fault and retest a corrected model.

Advanced

Transfer the lamp threshold to forty: Update the decision and expected boundary outputs for thirty-nine, forty and forty-one. Explain which subtask interfaces stay the same.
Distinguish independent and sequence tests: Design one test that starts from a reset state and one that depends on a previous Enable. Explain why resetting before every row would miss a history-related fault.
Evaluate fluctuating model readings: Trace enabled Hold readings twenty-nine, thirty-one, twenty-nine and thirty-one. Explain the toggling limitation and propose a question for a revised specification.
Review a physical-system abstraction: Evaluate a partner's labelled paper or software model against the stated rules. Identify an omitted real-world effect and explain why passing model tests does not establish hardware safety.

Learning Check

Decompose the lamp-system problem: Provide a model identifying inputs, retained state, processing parts and displayed outputs.
Explain the worked state sequence: Trace Hold20, Enable20, Hold45, Hold10, Disable10 and Hold5 from disabled state.
Check the exact decision boundary: For enabled true, explain results at twenty-nine, thirty and thirty-one.
Explain invalid-input ordering: From enabled false, trace Enable with brightness 101. From enabled true, trace Hold with brightness minus one.
Transfer and test a changed threshold: Change the threshold to forty, predict its nearby boundary and identify the parts that need revision.
Evaluate the finished model's evidence and limits: Present a paper or software model, actual model-test record and a limitations statement.

Worked checks and assessment guidance

A suitable model names brightness and command inputs, the persistent enabled Boolean, validation before update, the command updater, the enabled-and-low decision and lamp/message outputs. Interfaces and the state return must be explicit.
Enabled values are false, true, true, true, false, false. Lamp outputs are OFF, ON, OFF, ON, OFF, OFF. Hold preserves the current mode; a low reading alone does not enable it.
The outputs are ON, OFF and OFF. Only twenty-nine is below thirty. At thirty and thirty-one, automatic mode can remain enabled even though the displayed lamp is off.
Both steps fail validation, display OFF and Input error, and preserve the previous state. The first remains false and the second true. No command update occurs before validity is established.
Enabled-true readings thirty-nine, forty and forty-one give ON, OFF and OFF. Change the decision and expected tests; retain the input domain, command meanings, state interface and display roles.
Assess the decomposition, accurate state traces, contrasting tests and justified limits. A paper enactment can satisfy this modelling objective when labelled honestly. It does not prove unimplemented software execution, calibrated sensing or real electrical safety.

Learning evidence

Knowledge: Explain physical system, model, input, retained state, processing, output, decomposition, abstraction and interface.

Model product: A labelled paper representation, enactment or software simulation of the specified lamp rule. No hardware control is part of this task.

Tests: Record the six-step state sequence, twenty-nine/thirty/thirty-one boundary and invalid-reading cases, distinguishing predictions from actual model results. Include one investigated correction or justified improvement.

Transfer: Revise the teaching threshold and explain the changed rule and retained interfaces.

Limits: State that brightness values and thresholds are invented, real sensing has different characteristics and model success does not certify physical hardware. Identify paper and software evidence accurately.

OER and Wikipedia

Department for Education: Computing programmes of study, key stage 2. Designing programs, decomposing problems and controlling or simulating physical systems are key-stage expectations; this Year 6 model is an editorial allocation. The lamp rule, artificial scale, command/state design and traces are original teaching examples.

Micro:bit Educational Foundation: light sensing provides a real example of sensing with a different scale and approximate measurement. Its hardware instructions are not part of this simulation-only task. No claim that our invented zero-to-one-hundred scale is a micro:bit reading or a lux measurement.

Photograph, unmodified: Desk Lamp 1, 2013-07-12, FASTILY, CC BY-SA 3.0. It illustrates a lamp, not the internal operation of an automatic controller.

Video: How Computers Work: CPU, Memory, Input and Output, Code.org / CodeAI, embedded from the original publisher. No video copy is downloaded or redistributed.