Chapter 8 — Computer architecture
Lesson map
Lesson 08 published. Map, example, EX022.
flowchart TD
N0["Learning outcomes"]
N1["8.1 Edge devices"]
N2["8.2 Data representation"]
N3["8.3 Integrity checks"]
N4["8.4 Storage tiers"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX022"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["8.1 Edge devices"]
N2["8.2 Data representation"]
N3["8.3 Integrity checks"]
N4["8.4 Storage tiers"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX022"]
[Learning outcomes]
|
v
[8.1 Edge devices]
|
v
[8.2 Data representation]
|
v
[8.3 Integrity checks]
|
v
[8.4 Storage tiers]
|
v
[Worked example] --> [Exercise EX022]
Learning outcomes
You will (1) relate hardware limits to data handling; (2) understand edge devices in metering; (3) consider integrity during transmission and storage.
8.1 Edge devices
Each smart meter contains a small processor, memory and a radio. Kofi learns that meters store readings locally and transmit them in batches, so a radio outage causes delayed rather than lost data, up to the memory limit. A meter with seven days of storage loses readings if it cannot transmit for longer. Governance needs to know these limits, because a rule that marks late readings as invalid would wrongly reject legitimate delayed data after an outage. The late-data rule is changed accordingly.
8.2 Data representation
Kofi studies how readings are represented. Meters store integer counts of litres to avoid floating-point rounding, and the head-end system converts to cubic metres. A bug that converts twice divides values by a thousand. He also sees that timestamps are stored in UTC on meters but displayed in local time, and daylight saving changes create apparent duplicate or missing hours. Representation choices are low-level engineering details with direct effects on billing data quality. Timestamps are now stored in UTC everywhere, and local time is used only for display to customers.
8.3 Integrity checks
Meters attach a checksum to each batch so the receiver can detect corruption in transmission. Kofi explains that a checksum detects accidental errors but does not prove who sent the data. Tidewater also uses message authentication to show that readings came from genuine meters. He maps where each check happens and finds that readings pass through a vendor platform where checks are not logged, creating a gap in evidence about integrity between the meter and Tidewater's systems. The vendor agrees to log checks.
8.4 Storage tiers
Tidewater stores recent readings on fast storage for billing and older readings on cheaper archive storage. Kofi notes that moving data between tiers is a point where data can be lost or changed. He recommends comparing record counts and checksums before and after each migration. Prof. Varga explains that architecture decisions such as tiering are governance decisions too, because they determine how quickly data can be retrieved for customer queries, audits or legal requests. The first migration test finds that three days of readings are missing from the archive copy.
Worked example
Kofi links meter memory limits to late-data rules, finds double-conversion and daylight-saving risks, maps integrity checks with a vendor gap and recommends counts and checksums for tier migrations.
Synthetic case. Devices are synthetic.
Errors and limits
Checksums detect accidents, not tampering; use authentication for origin.
Exercises
- EX022 — Seven-day limit. When does a meter lose readings? Rubric: 3 = outage longer than its storage period;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX023 — Daylight saving. What problem does daylight saving create? Rubric: 3 = apparent duplicate or missing hours;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX024 — Checksum limit. What does a checksum not prove? Rubric: 3 = who sent the data;; 2 = partly correct;; 1 = vague;; 0 = none.
Continue studying — lesson 08 (chapter 08 of 50)
← Chapter 07 · Course chapter index · Chapter 09 →
Continue to the next authored lesson.