Smart Places and Infrastructure · Study deck
Smart Cities: Service Envelopes and Initiatives
A parking sensor reading matters only if the city knows its age, zone, owner, and allowed use.
Ada is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Write a smart-city service envelope with owners, limits, and evidence.
- Compare nine city initiatives by public outcome and data boundary.
- Explain: LoRaWAN can fit low-rate battery sensors across city assets when gateway placement and downlink limits are acceptable.
- Explain: Waste management may need fill-level calibration, rugged enclosures, truck-route integration, and a threshold for when a skipped bin creates service risk.
Major section
Write Service Envelope First
LoRaWAN can fit low-rate battery sensors across city assets when gateway placement and downlink limits are acceptable.
- If nobody is accountable for changing a route, dispatching a repair, adjusting a signal plan, or publishing an alert, the IoT system is likely to become a passive dashboard.
- Parking guidance may need high space coverage, update freshness, curb-zone changes, and clear uncertainty labels.
- Smart-city failure is often a governance failure wearing a technology costume.
Major section
Write Service Envelope First (continued)
Waste management may need fill-level calibration, rugged enclosures, truck-route integration, and a threshold for when a skipped bin creates service risk.
- NB-IoT or LTE-M can fit dispersed assets where carrier coverage and recurring connectivity cost are acceptable.
- Fiber, Ethernet, or municipal Wi-Fi may suit fixed cameras or traffic corridors with power and backhaul.
- FIWARE NGSI-LD, OGC SensorThings API, GTFS-realtime for transit feeds, and GIS asset identifiers can make data reusable across departments when they are used as contracts rather than marketing terms.
Major section
City Data Needs Context and Boundaries
Under the hood, a smart-city platform has to preserve context across many layers.
- A parking event is not just occupied or free; it may need space id, curb rule, timestamp source, sensor confidence, maintenance status, payment-zone relation, and whether the observation is stale.
- A lighting event may need pole id, circuit, luminaire type, controller firmware, dimming schedule, fault code, work-order id, and safety exception.
- Standards help when they carry that meaning.
Major section
City Data Needs Context and Boundaries (continued)
The schema, metadata, and governance rules are the system contract.
- A waste event may need bin id, fill estimate, collection zone, contamination flag, route plan, and season.
- Without those fields, cross-domain integration becomes a pile of charts rather than an operating system for city services.
- Privacy and cybersecurity are also architectural, not afterthoughts.
Major section
City Data Needs Context and Boundaries (continued)
Video analytics may need edge processing that emits counts or events instead of raw footage.
- FIWARE NGSI-LD models city entities and relationships as linked data, which can help describe assets, observations, locations, and ownership across services.
- OGC SensorThings API provides a structured way to expose Things, Datastreams, Sensors, Observations, and Locations for sensing systems.
- Mobility data may need aggregation, k-anonymity-style thresholds, differential privacy techniques, or strict access controls before publication.
Major section
City Data Needs Context and Boundaries (continued)
MQTT and CoAP can move messages from constrained devices, but they do not by themselves define what a curb space, light pole, air-quality reading, or waste-bin alert means.
- Device fleets need provisioning, credential rotation, firmware update policy, tamper handling, network segmentation, audit logging, and incident response.
- A mature smart-city architecture makes those states visible to operators and understandable to residents.
- The point is not to centralize every system.
Major section
The Nine Smart City Initiatives
Several networks can carry their data.
- The choice depends on range, rate, power, and city control.
- It must keep sensor records, media, and registry data distinct.
- Traffic, waste, air, and energy services use those outputs for different goals.
- Shared pipes can cut repeated work.
Major section
The Nine Smart City Initiatives (continued)
They do not make each team's data, keep time, duty, or response rule the same.
- Traffic Congestion: monitoring vehicle and pedestrian levels to optimize driving and walking routes.
- Waste Management: detecting rubbish levels in containers to optimize collection routes.
- That contract needs clear fields, context, rules, and stable asset IDs.
Major section
The Nine Smart City Initiatives (continued)
Intake and an API gateway then allow controlled reuse.
- FIWARE NGSI-LD or OGC SensorThings can supply the exchange model.
- The platform is a point of duty, not a call to move every system into one place.
- Each city service keeps its own owner even when another team can use its data.
Major section
Smart Parking Sensor Tech
The disc both sends a pulse and listens for the echo, and the gap between the two gives distance.
- Everything else in the frame is context the sensor cannot see: paint, body curve, weather and whatever happens to be behind the car.
- Dynamic pricing integration: Real-time occupancy enables surge pricing (higher rates during peak demand).
Major section
Smart Parking Sensor Tech (continued)
Multi-use infrastructure: Same sensors can detect traffic flow, illegal parking, and emergency vehicle priority.
- A kerbside bay sensor faces the same limits with a harder job, because it must survive rain, grit and a vehicle parked on top of it while still separating a full bay from an empty one.
- Magnetic sensors: detect disturbance in Earth's magnetic field when a vehicle is present; they are accurate, low power, and weather tolerant, but require road-surface mounting and typically cost $150-300.
- It sits flush with the panel, because a raised housing would collect dirt and change the beam.
Major section
Parking Sensor Data and Battery Math
At 12 bytes per message for sensor id, status, and battery state, each sensor sends 34,560 bytes per day, or about 33.8 kB.
- A deployment of 14,800 sensors therefore sends about 500 MB per day, or about 182 GB per year.
- The power budget is the harder constraint.
- A 3.6 V, 8 Ah lithium battery stores about 28.8 Wh.
Major section
Parking Sensor Data and Battery Math (continued)
Sleep mode at 5 microamps for nearly the whole day uses only about 0.119 mAh/day.
- The LoRaWAN transmit path dominates: 2,880 transmissions at 40 mA for 1 second each uses about 32 mAh/day.
- The total is about 32.1 mAh/day, so an 8,000 mAh pack would last about 249 days without recharge.
- A real ten-year deployment needs a larger lithium primary cell, lower reporting rate, event-driven reporting, or solar assistance.
Deck summary
Key takeaways
LoRaWAN can fit low-rate battery sensors across city assets when gateway placement and downlink limits are acceptable.
- Waste management may need fill-level calibration, rugged enclosures, truck-route integration, and a threshold for when a skipped bin creates service risk.
- Under the hood, a smart-city platform has to preserve context across many layers.
- The schema, metadata, and governance rules are the system contract.
- Video analytics may need edge processing that emits counts or events instead of raw footage.
Retrieval practice
Recall check 1 of 3
Ada says: answer from memory, then check your reasoning.
Q1A city installs flood sensors but names no alert owner. What must its service envelope add?
Show answer
Answer: D The envelope links evidence to an accountable public response.
Retrieval practice
Recall check 2 of 3
Ada says: answer from memory, then check your reasoning.
Q2A city wants to deploy IoT across traffic, lighting, and waste services. What should guide the design first?
Show answer
Answer: C Smart-city IoT must connect technology choices to service outcomes and public constraints.
Retrieval practice
Recall check 3 of 3
Ada says: answer from memory, then check your reasoning.
Q3A city compares parking guidance with adaptive street lighting. Which review tests each public outcome and its data boundary?
Show answer
Answer: B Each service needs its own outcome evidence and limits on collecting or releasing its data.
Print reference
Answers
Answer key.
- D · The envelope links evidence to an accountable public response.
- C · Smart-city IoT must connect technology choices to service outcomes and public constraints.
- B · Each service needs its own outcome evidence and limits on collecting or releasing its data.