Assignment Prep & Mixed Revision
The assignment is 50 marks, about 31% of the course: five separate tasks, each in a different context, each testing a different part.
How the assignment really works
Golden rule: everything links back to the specification. The specification is written in Analysis, used to guide Design, checked in Testing, and judged in Evaluation.
| Task | What it tests | Build with |
|---|---|---|
| 1 | System & sub-system diagrams; input sensing circuit (describe Vout) | Paper; Yenka / real electronics |
| 2 | Microcontroller flowchart + circuit; test and fix | Yenka; or real hardware |
| 3 | Gear train, velocity ratio; compound gear design | NoStrainSim; or real gear kit |
| 4 | Logic from a Boolean expression; truth table | Yenka; or real logic ICs |
| 5 | Pneumatic time-delay circuit; safety modification | NoPressureSim; real pneumatic kit |
⚠ The conditions
- 8 hours, closed-book: no notes, internet, exemplars, wall displays, phones or AI — and no feedback from your teacher.
- Some sub-tasks must be done by hand with no simulation.
- Every page must show the task number at the top and your SCN at the bottom, in blue or black ink — even printed simulation outputs.
The five stages at a glance
| Stage | One-line summary |
|---|---|
| Analysis | Write a testable specification from the brief. |
| Design | Generate, develop and draw/simulate your solution. |
| Build | Make it safely, following your design. |
| Testing | Procedure + results that name component function. |
| Evaluation | Judge against the spec; justify improvements. |
Analysis — write a testable specification
A good specification point is specific and testable — you can later prove whether your solution met it. If you cannot test it, reword it. Write each point so it could become a line in your test procedure.
| Vague (avoid) | Specification quality (aim for this) |
|---|---|
| "It should work well." | The alarm must sound within 1 second of the sensor being covered. |
| "It needs a light." | An LED must switch on when the light level falls below a set value. |
| "It should be safe." | The motor must stop when the guard is opened. |
| "Make it small." | The circuit must fit on a 70 mm × 50 mm board. |
Design and build
In Design you generate several ideas, choose one and develop it into drawings an engineer could build from. Show development, not just one final idea — note why you rejected ideas and why your chosen one best meets the specification.
| Design output | What good practice looks like |
|---|---|
| System diagram | Generic input → process → output blocks with feedback arrows where used; label blocks by function, never "user input" |
| Circuit diagram | Correct BS symbols, components labelled with values, battery the right way round |
| Flowchart / pseudocode | Exam style; input/output pin numbers and every delay with its unit |
| Simulation | Matches your circuit/program; checked against the simulation checklist (below) |
While you build
- Follow your circuit / system design — if you change it, note the change and why.
- Work safely: follow workshop and electrical safety rules and wear the correct PPE.
- Keep a short build log — what you did, any problems, how you solved them.
- Keep the specification beside you, so the finished build can actually be tested against it.
Testing — procedures and results that score
A test procedure is a numbered set of steps someone else could follow, each linked to a specification point with an expected result. When you record a result, name the component and say what it did — markers reward function, not "it worked".
| Step | What you do | Expected result (from the spec) |
|---|---|---|
| 1 | Switch on the supply. | Green 'power' LED lights. |
| 2 | Cover the LDR to model darkness. | Output LED switches on within 1 second. |
| 3 | Uncover the LDR. | Output LED switches off. |
| Weak result | Result referring to component function |
|---|---|
| "It worked." | "When the LDR was covered, its resistance rose, the voltage at the transistor base rose, the transistor switched on and the LED lit." |
| "The motor went." | "The microcontroller output pin went high, the transistor switched and the motor turned." |
| "Nothing happened first time." | "The buzzer did not sound because the battery was connected the wrong way round; once reversed, the buzzer sounded." |
Evaluation — judge against the spec, justify improvements
Evaluate point by point against the given specification, using evidence from your testing. Then justify every improvement — say why it would make the solution better at meeting that specification point, not just what you would change.
| Specification point | Met? | Evidence (from testing) | Improvement |
|---|---|---|---|
| LED on when dark | Yes | Test 2 — LED lit when LDR covered | Add a variable resistor so the user can set the trigger level for different rooms |
| Responds within 1 s | Partly | Test 2 — took about 2 s | Reduce the delay in the program so the response meets the 1 s spec |
| Fits 70 × 50 mm board | No | Board measured 80 × 55 mm | Use surface-mount parts or a smaller battery holder to meet the size limit |
The six task-type skills — with what markers check
Each assignment task uses one of these six skills. Learn the method, then check the "what markers check" list — it comes from real SQA marker feedback. Revise the underlying knowledge on the linked topic page first.
System & sub-system diagrams
Method: input → process → output as labelled blocks; a sub-system diagram breaks the process into boxes inside a system boundary, with a driver before each output and a feedback loop from after an output back to the controller.
- Write the input and output as an ACTION ("car arrives"), not a device name.
- Draw the system boundary around all sub-systems, each in its own box.
- Give each output its own driver, individually joined to the microcontroller.
- Feedback starts after the output, through a sensor/limit switch, with both arrowheads.
- Do not label an action (e.g. "motor on") as a sub-system.
Input sensing circuit and Vout
Method: a sensing circuit is a voltage divider — a sensor (thermistor or LDR) and a (variable) resistor. Where you place the sensor decides whether Vout rises or falls as the condition changes — always state which.
- Use the correct thermistor / LDR and (variable) resistor symbols.
- Wire it as the right kind of sensor (cold sensor / dark sensor).
- DESCRIBE the effect on Vout when the condition changes — the most-missed marks.
- Some sub-tasks ban simulation — be ready to draw the circuit by hand.
Flowchart + circuit, test-and-fix
Method: build the flowchart and the electronic circuit so they match (pin numbers, decisions, time delays). Simulate. In a test table: initial result → planned amendment → make it → re-test result.
- Flowchart symbols and feedback loops correct; pins/states/decisions/delays match the circuit.
- Check battery orientation; make sure a motor is actually present.
- Test results must describe ALL aspects (LED and buzzer; relay and motor).
- Put loops in the right place and END the sequence — no infinite loop.
Gear train, velocity ratio and compound gears
Method: VR = driven teeth ÷ driver teeth = input speed ÷ output speed. A simple pair turns in opposite directions; add an idler to keep direction, or compound gears for a bigger ratio (multiply the stage ratios).
- Show a two-gear train with the motor/input identified and teeth labelled.
- Input and output of a simple pair turn in OPPOSITE directions.
- Work out VR from the speeds you actually recorded (FTE applies).
- Aim for a speed REDUCTION, not an increase; one pair cannot reach 20–30 : 1 — that needs a compound train.
Logic from a Boolean expression
Method: build the gate network to match the expression, working from the inside out — NOT first, then AND, then OR. Complete the truth table by evaluating every input combination.
- Invert the CORRECT input (NOT gate on the right input).
- Use AND vs OR correctly at the output — a common error is AND where OR is needed.
- Connect the gates to match the expression exactly.
- Truth-table output column correct (FTE from your own circuit).
Pneumatic time-delay circuit and safety
Method: a 3/2 valve gives the signal; a restrictor fills a reservoir which, after a delay, pilots a 5/2 valve; the 5/2 drives a double-acting cylinder (two pipes). A unidirectional restrictor on the exhaust slows one stroke only.
- Double-acting cylinder connected to the 5/2 valve with TWO pipes.
- A unidirectional restrictor slows the outstroke on the exhaust.
- The reservoir (with restrictor) sits between the 3/2 and the 5/2 — that is the time delay.
- TWO 3/2 valves (outstroke and instroke) piped to the 5/2, with the correct actuator on each.
- A safety modification must be justified by WHY it is safer.
Which tool for which task — and the simulation checklist
Use whatever gets you a clear, testable result — a simulator, the real kit, or paper where simulation is not allowed. Whatever the tool, every page needs the task number at the top and your SCN at the bottom, including printed simulation outputs.
| Task | What you build | Tool(s) |
|---|---|---|
| 1 | System / sub-system diagram; sensing circuit | Paper; Yenka / real electronics to check |
| 2 | Flowchart + circuit, test and fix | Yenka; or real microcontroller hardware |
| 3 | Gear train + velocity ratio; compound design | NoStrainSim — Drive Trains; real gear kit |
| 4 | Logic diagram + truth table | Yenka logic; or real logic ICs |
| 5 | Pneumatic time-delay circuit | NoPressureSim; real pneumatic equipment |
The simulation checklist — easy marks, easily lost
- Symbol orientation: battery (long line +), diodes/LEDs and electrolytic capacitors the right way round.
- Right microcontroller: choose one that actually has the inputs/outputs you need — don't rename pins on the wrong chip.
- Simulation matches tests: the sim behaves the same as your real circuit/program — if they differ, explain why.
- Feedback arrows: closed-loop system diagrams show the feedback path back to the process.
- Generic labels: blocks labelled input / process / output or by function — never "user input".
- Components labelled: resistor and capacitor values shown; pins and connections clear.
Common mistakes — watch out for these in the assignment
- Writing a specification that cannot be tested ("works well") instead of a measurable point.
- Recording results as "it worked" instead of naming the component and what it did.
- Evaluating in general terms instead of going through the given specification point by point.
- Suggesting improvements but not justifying why they help.
- Simulation slips: battery the wrong way round, the wrong microcontroller with renamed pins, missing feedback arrows, or "user input" labels.
Check yourself
Sources & credits: The Booklet 8 assignment-skills material © R Stewart, 2026; marker checkpoints summarise published SQA marker feedback. The Past Paper Finder is compiled by Mr McDonald, 2024; past-paper questions © Qualifications Scotland (SQA). The N4/N5 data booklet is reproduced for educational use, © Qualifications Scotland (SQA).