Analytics & ML · Study deck
Cloud Data: IoT Reference Model
Picture a cold-room sensor that sends a value of 8.
Data Dora is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: Connectivity and edge computing keep observations moving and can support local action; accumulation changes moving events into retained data; abstraction then makes that data consistently queryable; applications and collaboration turn it into decisions and coordinated work.
- Explain: The progression connects the reference model to the chapter's running narrative: higher levels add history and organisational context, but they remain trustworthy only when identity, units, timestamps, and quality evidence survive the hand-offs below.
- Explain: A Level 5 data product should expose a stable contract: canonical fields, units, timestamps, quality states, source references, and versioned transformation rules.
Major section
Start With the Story
The cloud cannot act well until it knows the unit, room, time, quality, and device.
- The IoT reference model is a way to sort jobs by level.
- Lower levels sense, move, process, and store records.
- The upper cloud levels make those records consistent, turn them into an app view, and link the view to human work.
Major section
Start With the Story (continued)
A logical level is not a fixed server or vendor product.
- Practitioner makes the abstraction record clear.
- Those details can change the app result.
- A device has produced messy evidence, an analytic step is about to change an alert or control decision, and someone has to explain why the result should be trusted.
Major section
Levels 5-7 Turn Data Into Work
The IoT reference model is a logical map, not a deployment recipe.
- Cloud data work begins when accumulated records become governed information products.
- Levels 5-7 describe that upper path: data abstraction, applications, and collaboration or business processes.
- Level 6, Application, turns the abstracted data into dashboards, alerts, reports, analytics, model outputs, and control interfaces.
Major section
Levels 5-7 Turn Data Into Work (continued)
Level 7, Collaboration and Processes, connects those outputs to people, systems, contracts, tickets, inspections, purchasing, billing, compliance, and partner workflows.
- The cloud layers are where raw operational records become trusted evidence, then application insight, then a coordinated business action.
- Level 5 Normalize, reconcile, validate, index, secure, and expose data so applications do not repeat source-specific logic.
- Level 6 Build analytics, dashboards, rules, reports, APIs, machine-learning outputs, and control views from governed data.
Major section
Levels 5-7 Turn Data Into Work (continued)
Connectivity and edge computing keep observations moving and can support local action; accumulation changes moving events into retained data; abstraction then makes that data consistently queryable; applications and collaboration turn it into decisions and coordinated work.
- The progression connects the reference model to the chapter's running narrative: higher levels add history and organisational context, but they remain trustworthy only when identity, units, timestamps, and quality evidence survive the hand-offs below.
- Level 7 Route insights into work orders, logistics changes, supplier collaboration, claims, compliance, and decisions.
- Unit conversions, schema ids, validation reports, lineage, completeness metrics, and access logs.
Major section
Practitioner: Make Level 5 Explicit
At: Data abstraction, format reconciliation, unit normalization, completeness checks, indexing, replication, and access control cross the OT → IT boundary; only then do: Application and: Collaboration & processes turn the governed record into action.
- Level 5 is often the hidden layer that determines whether Level 6 analytics are trustworthy.
- It should not be buried inside dashboard code.
Major section
Practitioner: Make Level 5 Explicit (continued)
design reading: The dashboard should not need vendor-specific code.
- It should have owned conversion rules, schema versions, validation thresholds, lineage records, completeness checks, and access policies.
- When each dashboard implements its own unit conversions, the organization gets inconsistent results and cannot replay decisions.
- Level 5 should preserve the original source reference.
Major section
Practitioner: Make Level 5 Explicit (continued)
A Level 5 data product should expose a stable contract: canonical fields, units, timestamps, quality states, source references, and versioned transformation rules.
- The original Level 4 record can remain available for audit, but Level 6 applications should normally query the canonical view.
- It should read moisture_pct, quality_state, and lineage_ref from the Level 5 product and show a consistent result across all vendors.
- Normalization without lineage makes the result convenient but hard to audit.
Major section
Data State Across Cloud Levels
At Levels 1-3, data is mostly in motion: readings, packets, buffers, features, and local decisions.
- At Level 4, it becomes data at rest: retained event logs, time-series records, files, and table versions.
- At Level 5, it becomes governed data in context.
- At Level 6, it becomes application insight.
- At Level 7, it becomes work.
Major section
Data State Across Cloud Levels (continued)
Cloud architecture should preserve evidence at each transition.
- Level 4 needs offsets, timestamps, partitions, raw paths, and retention rules.
- Level 5 needs transformation versions, quality reports, lineage, catalogs, and access decisions.
- Level 6 needs query plans, model versions, alert thresholds, and user-facing freshness.
- Level 7 needs workflow ids, acknowledgements, approvals, and closeout outcomes.
Major section
Data State Across Cloud Levels (continued)
Level 4 stores the KPI event stream and selected raw windows.
- Level 6 shows dashboards, alert queues, and trend panels.
- design reading: The dashboard is not just a Level 6 screen.
- It depends on Level 3 reduction, Level 4 retention, Level 5 context, and Level 7 workflow evidence.
Deck summary
Key takeaways
The cloud cannot act well until it knows the unit, room, time, quality, and device.
- A logical level is not a fixed server or vendor product.
- The IoT reference model is a logical map, not a deployment recipe.
- Level 7, Collaboration and Processes, connects those outputs to people, systems, contracts, tickets, inspections, purchasing, billing, compliance, and partner workflows.
- Connectivity and edge computing keep observations moving and can support local action; accumulation changes moving events into retained data; abstraction then makes that data consistently queryable; applications and collaboration turn it into decisions and coordinated work.
Retrieval practice
Recall check 1 of 3
Data Dora says: answer from memory, then check your reasoning.
Q1What is the main role of IoT reference model Levels 5-7?
Show answer
Answer: C Levels 5-7 describe data abstraction, application use, and collaboration or process integration.
Retrieval practice
Recall check 2 of 3
Data Dora says: answer from memory, then check your reasoning.
Q2Three soil sensors report moisture as 48 percent, 0.48 fraction, and ADC value 1966 on a 0-4095 range. Where should the canonical moisture_pct value be produced?
Show answer
Answer: A Level 5 is where heterogeneous source formats become canonical, queryable records with quality and lineage metadata.
Retrieval practice
Recall check 3 of 3
Data Dora says: answer from memory, then check your reasoning.
Q3A global factory dashboard receives edge KPIs, joins them to factory metadata, shows alert panels, and opens maintenance tickets. Which statement best describes the reference-model lesson?
Show answer
Answer: B Reference-model levels describe logical responsibilities that often cooperate inside one user-visible workflow.
Print reference
Answers
Answer key.
- C · Levels 5-7 describe data abstraction, application use, and collaboration or process integration.
- A · Level 5 is where heterogeneous source formats become canonical, queryable records with quality and lineage metadata.
- B · Reference-model levels describe logical responsibilities that often cooperate inside one user-visible workflow.