Purpose-built analytics running directly on IoT gateway hardware — no cloud dependency, no server round-trip, real-time equipment status at the edge.
- Project Overview
- The Problem
- The Approach
- Architecture
- Key Design Decisions
- KPI Design Framework
- User Types and Views
- Performance Optimisation
- Industry Context
- Lessons Learned
- Skills Demonstrated
| Attribute | Detail |
|---|---|
| Domain | IoT Energy Management |
| Type | Edge Analytics / Embedded Dashboard |
| Users | Installation Engineers + End Users (Site Operations) |
| Deployment | Runs directly on IoT gateway hardware |
| Connectivity Required | None — fully offline capable |
| Purpose | Real-time equipment status and diagnostic monitoring at the edge |
Most IoT monitoring platforms follow a centralised architecture:
Device → Gateway → Server → Cloud → Dashboard → User
This works well in stable, connected environments. It breaks down in three real-world scenarios that are common in industrial IoT deployments:
Scenario 1 — Remote site installation An engineer arrives at a site to install and commission IoT equipment. The network is not yet configured. The cloud platform is unreachable. The engineer needs diagnostic data immediately to verify the installation is working correctly.
Scenario 2 — Poor connectivity zones Many industrial and energy infrastructure sites — telecom towers, substations, remote battery installations — have unreliable or low-bandwidth connectivity. Waiting for a cloud dashboard to load is not operationally viable.
Scenario 3 — Quick operational checks An end user visits a site and needs to check equipment status in seconds. Opening a browser, logging into a platform, navigating to the right asset — this workflow adds unnecessary friction for a simple status check.
The gap: No lightweight, on-device analytics interface designed for both installation-time diagnostics and operational status checks.
We designed and implemented an analytics dashboard that runs directly on the IoT gateway hardware itself — what the industry calls an edge analytics or edge computing approach.
Device Sensors
│
▼
IoT Gateway Hardware
┌─────────────────────────────┐
│ Sensor Data Collection │
│ │ │
│ ▼ │
│ In-Memory Data Tables │
│ (Indexed for speed) │
│ │ │
│ ▼ │
│ KPI Calculation Engine │
│ │ │
│ ▼ │
│ Edge Analytics Dashboard │
│ ┌──────────┬────────────┐ │
│ │ Engineer │ End User │ │
│ │ View │ View │ │
│ └──────────┴────────────┘ │
└─────────────────────────────┘
│
▼
Direct Local Access
(No internet required)
The dashboard is accessible directly by anyone with local network access to the gateway — engineers during installation, end users during site visits — without requiring any external connectivity.
Physical Sensors
│
│ Raw telemetry readings
▼
Gateway Data Collection Layer
│
│ Validated, timestamped readings
▼
In-Memory Storage Layer
• All tables stored in device memory
• Indexed for fast query response
• Optimised for hardware longevity
│
│ Structured, query-ready data
▼
KPI Calculation Engine
• Pre-defined KPI formulas
• Dual-view computation (Engineer / End User)
• Threshold evaluation for status flags
│
│ Calculated KPIs + Status indicators
▼
Dashboard Presentation Layer
• Engineer View — diagnostic and commissioning metrics
• End User View — operational status and health indicators
• Lightweight rendering optimised for gateway hardware
| Constraint | Design Response |
|---|---|
| Limited hardware processing power | Lightweight dashboard rendering, pre-computed KPIs |
| Limited storage capacity | In-memory tables, no disk write overhead |
| No guaranteed internet connectivity | Fully self-contained — no external dependencies |
| Two distinct user types with different needs | Separate views with role-appropriate KPI sets |
| Hardware longevity requirement | Memory storage chosen over disk to reduce wear |
Why: Writing data to disk on embedded hardware creates two problems — it slows response times due to disk I/O latency, and frequent write operations reduce the physical lifespan of flash storage components.
Solution: All operational data tables are stored in device memory (RAM). This eliminates disk I/O entirely for dashboard queries, delivers millisecond response times, and extends hardware operational life.
Trade-off acknowledged: In-memory storage is volatile — data is lost if the device loses power. This is acceptable for a dashboard use case where the primary data store is the central server. The edge dashboard is a real-time view, not a primary data store.
Why: Even with in-memory storage, unindexed table scans on a resource-constrained gateway processor would create visible latency on dashboard page loads — degrading the user experience for the quick-check use case.
Solution: All data tables are indexed on the primary query dimensions — device identifier, timestamp, and metric type. Dashboard page loads query against indexes rather than scanning full tables, delivering consistent sub-second response times.
Result: Dashboard pages load in milliseconds even when querying across multiple KPIs simultaneously on constrained hardware.
Why: An installation engineer and a site end user have fundamentally different information needs from the same equipment.
- An engineer during installation needs diagnostic-level metrics — raw sensor values, calibration status, connectivity confirmation, error codes, threshold validation
- An end user during a site visit needs operational-level status — is equipment healthy, are KPIs within normal range, does anything need attention
Solution: Two distinct dashboard views served from the same underlying data, each showing only the KPIs relevant to that user type. Neither view is cluttered with metrics the user does not need.
Why: The installation use case specifically requires the dashboard to work before network connectivity is established. Any dependency on an external server, cloud API, or DNS resolution would make the dashboard unavailable at exactly the moment it is most needed.
Solution: The entire dashboard stack — data, calculation engine, and presentation layer — runs on the gateway hardware itself. No external calls are made during normal dashboard operation.
The KPI design process followed a structured approach rather than defaulting to displaying all available sensor data.
For each user type, identify the primary operational question they need answered:
| User Type | Primary Question | Secondary Questions |
|---|---|---|
| Installation Engineer | Is this equipment correctly installed and communicating? | Are all sensors reading within expected ranges? Are thresholds correctly configured? Is connectivity established? |
| End User | Is my equipment healthy and operating normally? | Are there any active alerts? What is the current performance status? Has anything changed since my last visit? |
Each decision maps to specific, calculable KPIs rather than raw sensor values:
| Decision | Raw Data Available | KPI Designed |
|---|---|---|
| Is equipment communicating? | Last timestamp of data received | Time since last reading (seconds/minutes) |
| Are sensors in range? | Raw voltage, temperature, current readings | Deviation from expected range (%) |
| Is equipment healthy? | Multiple sensor readings | Composite health status indicator |
| Are there active alerts? | Individual threshold flags | Consolidated alert count by severity |
| What is performance status? | Historical + current readings | Performance vs baseline (%) |
Each KPI was validated against one test: does this KPI directly answer a question the user needs to act on?
KPIs that required interpretation or domain expertise to understand were either simplified or converted into status indicators (Normal / Warning / Critical) rather than raw values.
Designed for use during the initial setup of gateway hardware at a new site.
Primary use case: Verify that installation is complete and correct before leaving the site.
KPI categories shown:
- Connectivity status — is the gateway communicating correctly
- Sensor health — are all connected sensors reading and within calibration range
- Configuration validation — are device parameters correctly set
- Threshold confirmation — are alert thresholds correctly applied
- Communication log — recent data transmission confirmations
Design principle: Diagnostic depth over simplicity. Engineers need raw values and technical confirmation, not simplified status indicators.
Designed for site visits and quick operational checks by non-technical users.
Primary use case: Check equipment status and confirm normal operation in under 30 seconds.
KPI categories shown:
- Overall equipment health status
- Key performance indicators vs expected ranges
- Active alerts and their severity
- Last updated timestamp
- Performance trend (improving / stable / degrading)
Design principle: Clarity over depth. End users need to know if something needs attention — not the technical detail of why.
Running analytics on gateway hardware requires a different optimisation mindset compared to server or cloud deployments.
| Standard Server Approach | Edge Hardware Approach |
|---|---|
| Optimise for query complexity | Optimise for query speed on limited CPU |
| Storage is cheap — write everything | Storage wear matters — minimise disk writes |
| Network latency is the bottleneck | Processing latency is the bottleneck |
| Scale by adding resources | Scale by simplifying the workload |
| Cache frequently accessed data in memory | Store all operational data in memory |
Table Indexing Strategy
- Primary index on device identifier — all queries are device-scoped
- Secondary index on timestamp — all KPI calculations are time-bounded
- Composite index on (device, timestamp) for the most common query pattern
Pre-computation Approach
- KPIs that require complex calculation are computed on data ingestion, not at query time
- Dashboard pages query pre-computed results rather than performing calculations on page load
- This shifts CPU load to the ingestion moment — spreading it across time rather than concentrating it at the user interaction moment
View Separation Benefit
- Engineer and End User views query different, smaller subsets of the full KPI set
- No single dashboard query needs to compute all KPIs simultaneously
- Page load time is bounded by the heaviest single view, not the sum of all KPIs
Edge analytics — running data processing and visualisation at or near the data source rather than in a central server or cloud — is a recognised and growing architectural pattern in industrial IoT.
| Company | Product | Edge Analytics Approach |
|---|---|---|
| Siemens | SIMATIC Edge | Industrial edge computing platform — runs analytics apps directly on edge devices close to production machinery |
| Schneider Electric | EcoStruxure Edge Control | Edge control and analytics for energy and industrial automation — local processing with cloud synchronisation |
| AWS | AWS Greengrass | Extends AWS services to edge devices — runs Lambda functions and ML inference locally on IoT hardware |
| Microsoft | Azure IoT Edge | Deploys cloud workloads to edge devices — runs containerised analytics modules locally |
| Siemens | MindSphere Edge | Collects and pre-processes industrial data at the edge before selective transmission to the cloud |
The implementation described in this project shares the core principle with all of the above — push intelligence closer to the data source — but is purpose-built for a specific use case: lightweight, installation-time and operational-status monitoring on constrained gateway hardware, without requiring the full infrastructure overhead of enterprise edge platforms.
This is a pragmatic, domain-specific application of edge analytics principles rather than a general-purpose edge computing platform.
The most important design decision was separating engineer and end user needs before designing any KPI. Without this separation, dashboards tend to compromise — too complex for casual users, not detailed enough for technical users. Defining the user first makes every subsequent design decision easier.
Designing for a resource-constrained environment forces prioritisation that cloud-based dashboards often skip. Every KPI has to justify its computational cost. Every table has to justify its memory footprint. The result is a leaner, faster, more focused dashboard than most unconstrained designs produce.
Initially framed as a constraint, the zero-external-dependency design turned out to be one of the most valued features — particularly for installation engineers who frequently work at sites before connectivity is established. Designing for the hardest constraint first produced a better product for all use cases.
The decision to use in-memory storage required explicit agreement on what the edge dashboard is — a real-time operational view — and what it is not — a historical data store or audit trail. Clarity on scope prevented scope creep that would have broken the memory-optimised architecture.
| Skill | How Demonstrated |
|---|---|
| IoT Analytics Design | End-to-end dashboard architecture for IoT gateway hardware |
| Edge Computing Concepts | Applied edge-first design principles to constrained hardware environment |
| KPI Design | Structured KPI design process from user decision to metric definition |
| User-Centred Design | Dual-view architecture separating engineer and end user needs |
| Performance Optimisation | In-memory storage, table indexing, pre-computation strategy |
| Hardware-Constrained Analytics | Optimisation principles adapted for embedded device constraints |
| Domain Knowledge | IoT energy management, device commissioning workflows, operational monitoring |
| Technical Documentation | Architecture diagrams, design decision documentation, trade-off analysis |
LinkedIn: linkedin.com/in/jagannath-analyst
Analytics Manager | IoT Energy & Surveillance Analytics | Battery · Telecom · Retail · Banking
This README documents architectural thinking and design decisions from a real-world IoT analytics implementation. Proprietary implementation details, client information, and internal system specifics are intentionally omitted.