Smart Places and Infrastructure · Study deck
IoT Case Studies: Transferable Evidence
A case study matters only when its result can guide a new design.
Ada is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: People and process matter: Barcelona’s separately reported water and parking results and a hypothetical factory model show why ownership, integration, and staff response must be assessed alongside sensors.
- Explain: If a predictive-maintenance vendor reports high model accuracy but cannot show alert acceptance, work-order routing, false-positive control, and downtime reduction, the design lesson is incomplete.
- Explain: End with three lines. “Keep” names the part worth testing. “Change” names the local part that must differ. “Prove” names the test needed at the new site.
- Apply predictive maintenance ROI frameworks from Volkswagen's manufacturing case
Major section
Begin With One Claim You Might Reuse
Bandwidth means how much data a link can carry in a given time.
- Latency means the time from an event to the useful result.
- A protocol means an agreed set of rules for passing data.
- A shared platform may lower repeated work, but it may add one large point of control.
Major section
Begin With One Claim You Might Reuse (continued)
A clear success story can reveal a useful pattern, but it can also hide upkeep, weak areas, or a special local deal.
- This first pass does not prove that another city will get the same outcome.
- For a smart-place transfer, compare cases, costs, and transfer records; check data lineage, architecture, rollout, and local conditions before accepting the result.
- A blank is better than a guess.
Major section
Begin With One Claim You Might Reuse (continued)
A result without this path may be real, but it is hard to move.
- End with three lines. “Keep” names the part worth testing. “Change” names the local part that must differ. “Prove” names the test needed at the new site.
- If a case gives no sound line for all three, use it as a question source, not a design answer.
- One of two parts on real IoT deployments -- the other is Lessons from Real Deployments: Volkswagen Predictive Maintenance and Cross-Case Lessons.
Major section
Minimum Viable Understanding
People and process matter: Barcelona’s separately reported water and parking results and a hypothetical factory model show why ownership, integration, and staff response must be assessed alongside sensors.
- False positives can erode user trust: Predictive-maintenance alerts need validation with technicians and a process for reviewing false alarms.
Major section
A Case Study Is a Transfer Test
A useful IoT case study does more than tell a success story.
- It lets you test whether a deployment pattern can transfer to another problem without copying the original organization blindly.
- The shared lesson is not that every project needs the same sensors or the same cloud stack.
- Barcelona and Volkswagen are deliberately different: one is a public-service platform across city departments, while the other is an industrial reliability program inside a factory.
- A case that cannot answer all four questions is weaker evidence for design work.
Major section
A Case Study Is a Transfer Test (continued)
The transferable part of a case study is the link between problem, architecture, adoption, and evidence, not a literal copy of the original deployment.
- This frame also protects you from advertising language.
- If a smart-city vendor says a platform is "open" but cannot show how device data, APIs, city departments, and developers connect, the claim is incomplete.
- If a predictive-maintenance vendor reports high model accuracy but cannot show alert acceptance, work-order routing, false-positive control, and downtime reduction, the design lesson is incomplete.
Major section
Pattern vs Local Conditions
When you use a case study to design a new project, do not copy the visible artifacts first.
- A private campus may still need open APIs, but it may not need the same civic data portal.
- Volkswagen's edge analytics matter because production downtime is expensive and high-rate machine data is too large to ship raw.
- Barcelona's open Sentilo platform matters because a city has many departments, many vendors, and a long-lived public-service mandate.
Major section
Pattern vs Local Conditions (continued)
A small workshop may still need predictive maintenance, but it may not need the same gateway density or model-training pipeline.
- A practitioner translation note should name the decision boundary.
- They also expose which assumptions must be rechecked before a team promises similar results.
- The contrast makes the transfer work visible.
Major section
Evidence Has a Data Lineage
The technical depth behind a case study is the lineage from physical event to decision record.
- If the lineage loses timestamps, device identifiers, calibration status, or service ownership, the dashboard may still look convincing while the evidence becomes weak.
- In a Volkswagen-style predictive-maintenance system, the lineage is faster and more local.
- Vibration, current, acoustic, or thermal signals are sampled near the asset; an edge gateway extracts features; a model scores anomalies; the maintenance system creates or updates a work order; and a technician confirms whether the alert matched a real condition.
- Under the hood, the strongest case studies are traceable.
Major section
Evidence Has a Data Lineage (continued)
The under-the-hood question is not just whether TensorFlow Lite, OPC UA, SAP Manufacturing Integration, or a digital twin appears in the architecture.
- The question is whether each component preserves enough context for a responsible maintenance decision.
- Case-study evidence therefore needs audit fields.
- A smart-city event should record device identity, measurement time, location granularity, calibration state, consent or privacy class where relevant, API consumer, and action taken.
Major section
What Are Case Studies?
You would look at treehouses other kids already built to learn what worked and what did not.
- By studying what these teams did right (and wrong), we can build better IoT projects ourselves.
Major section
Lessons from Real IoT Projects
A case study is a detailed look at how a real organization solved a problem using IoT technology.
- The key beginner takeaway is that successful IoT is not just about hardware and software.
- The biggest challenges are getting people to trust the system, connecting it to existing processes, and maintaining it over time.
- Integration and change management can demand substantial effort in both city-scale and factory-scale IoT projects alongside the technology work.
Deck summary
Key takeaways
Bandwidth means how much data a link can carry in a given time.
- A clear success story can reveal a useful pattern, but it can also hide upkeep, weak areas, or a special local deal.
- A result without this path may be real, but it is hard to move.
- People and process matter: Barcelona’s separately reported water and parking results and a hypothetical factory model show why ownership, integration, and staff response must be assessed alongside sensors.
- A useful IoT case study does more than tell a success story.
Retrieval practice
Recall check 1 of 2
Ada says: answer from memory, then check your reasoning.
Q1A city report claims reduced parking search time. What belongs on a claim card before another city copies the design?
Show answer
Answer: B The chapter asks the reader to preserve the claim’s evidence and leave unknowns visible.
Retrieval practice
Recall check 2 of 2
Ada says: answer from memory, then check your reasoning.
Q2A factory team studies a city platform case. Which comparison makes the case useful?
Show answer
Answer: A The four lenses connect the operating problem to an accountable result.
Print reference
Answers
Answer key.
- B · The chapter asks the reader to preserve the claim’s evidence and leave unknowns visible.
- A · The four lenses connect the operating problem to an accountable result.