Operational Decision-Making at the Edge
By Melissa Beaudette
Overview
To strengthen our IoT and edge-computing consulting capabilities, I led the definition and delivery of a fully functional application demo that showcased real-time sensor ingestion, edge decision-making, MQTT message queuing, and mobile alerting.
Although the business scenario was fictional, the technical architecture, microservices, message flows, event handling, and mobile application were fully implemented and became a core sales asset for our organization.
Project Context & Goal
To accelerate our IoT and edge-computing consulting practice, we needed a compelling, hands-on demonstration that would help clients visualize how real-time sensor data, edge intelligence, and message queuing work together in a production environment. While we had strong technical capabilities, we lacked a unified demo that clearly showcased:
- A realistic operational business scenario
- Live, event-driven sensor data
- Edge processing and offline-capable logic
- Mobile connectivity without relying on internet access
To address this gap, I designed a fictional but operationally realistic fleet operator scenario that would resonate with both technical and executive audiences. This narrative provided a relatable anchor for the demonstration and became the storytelling backbone for showcasing the technical capabilities we implemented.
Scenario Overview
Business Problem
A national refrigerated-trucking operator was experiencing temperature instability inside its trailers, leading to spoiled shipments, unplanned product loss, and downstream customer dissatisfaction. Drivers had limited real-time visibility into refrigeration failures, and fleet managers typically learned about issues only after goods had already been compromised.
Without sensor-driven insights or automated responses, the company struggled to prevent spoilage events, escalate issues quickly, or plan maintenance proactively.
Desired Outcomes
The IoT solution needed to deliver measurable operational value by enabling:
Real-Time Failure Detection
Immediate alerts to drivers and fleet managers when temperatures drifted out of range.
Automated Vehicle Response
Triggering backup cooling systems or recommended actions the moment a failure occurred.
Proactive Customer Communication
Providing shipment-status updates based on live sensor data to improve transparency and trust.
Fleet-Level Visibility & Crisis Response
Allowing dispatchers to reroute trucks, reassess delivery windows, and coordinate logistics quickly.
Predictive Maintenance Insights
Aggregating long-term sensor data to identify failure patterns, improve MTBF/MTTF accuracy, and reduce downtime.
Product Roadmap
To link the business problem to a practical implementation path, I established a multi-phase roadmap for how an IoT system matures over time. This roadmap connected the fleet operator’s operational challenges to the technical capabilities we implemented in the demo, ensuring a clear progression of value across edge and cloud components.
Roadmap Phases
Phase I — Real-Time Awareness & Local Safety Controls
Focus: Immediate operational protection
- Edge-level temperature monitoring
- Driver-facing mobile alerts
- Automatic activation of backup refrigeration systems
- Local logic designed to function even without internet
Phase II — Connected Fleet Operations & Communication
Focus: Visibility and coordinated response
- Cloud ingestion of sensor events
- Fleet-manager dashboards
- Escalation and routing workflows
- Customer communication based on real-time shipment status
Phase III — Predictive Insights &
Optimization
Focus: Insight-driven operations
- Long-term data aggregation for trend analysis
- MTBF/MTTF modeling
- Predictive maintenance recommendations
- Optimization opportunities (fleet utilization, repair scheduling, on-time delivery improvements)
This roadmap became the narrative foundation for the demo, showing clients how an IoT platform compounds in value—from basic alerting to advanced decision intelligence. I used this roadmap to coordinate cross-functional engineering workstreams and define clear MVP boundaries for the edge gateway, cloud ingestion, and mobile HMI.
My Role
As Product Owner, I led the initiative from concept to delivery, ensuring that the demonstration not only showcased our technical capabilities but also mapped clearly to real-world business value.
Product Definition
Translated the fictional fleet-operator scenario into concrete product requirements, personas, and success measures.
Defined system behaviors for sensor ingestion, edge processing, real-time alerts, and cloud-based visibility.
Authored acceptance criteria for microservices, the message-flow pipeline, and the mobile HMI.
Technical Product Leadership
Collaborated with engineers to shape the event-driven architecture, ensuring MQTT topic structures, payload schemas, and subscription patterns aligned with product requirements.
Partnered with engineers to define controller/handler responsibilities and ensure device signals were normalized for consistent downstream processing.
Mapped the end-to-end data flow from sensors → gateway → cloud → mobile app, ensuring reliability even during offline conditions.
Evaluated technical tradeoffs and ensured architectural decisions supported the three-phase product roadmap.
Cross-Functional Delivery
Coordinated engineers across edge, cloud, mobile, and security domains.
Facilitated iterative reviews, demos, and integration checkpoints.
Ensured security, maintainability, and extensibility requirements were met end-to-end
Solution Architecture
IoT Reference Architecture
Before defining our demo implementation, we grounded the solution in a standard IoT reference architecture. This model shows the full lifecycle of sensor data: collection at the edge, local processing and filtering, message queuing, cloud ingestion, long-term storage, analytics, and delivery into user applications or automated workflows.
Although our demonstration focused on a refrigerated-fleet scenario, the architecture itself is broadly applicable to any sensor-driven environment. Using this reference model ensured our demo aligned with real-world design patterns and could scale conceptually to more complex IoT ecosystems.
Phase I System Architecture
Overview
To bring the reference architecture to life, we designed and implemented a working end-to-end demonstration system that modeled the same data flows, decision points, and component interactions found in real IoT deployments. Our implementation included physical and simulated sensors, a controller layer for data ingestion and event generation, MQTT-based message routing, Dockerized microservices running on a gateway device, and a lightweight mobile interface for alerting and visualization.
While intentionally scoped for a demo environment, the architecture remained faithful to production design patterns by using event-driven messaging, separation of concerns across edge and cloud layers, and offline-capable decision logic. This overview sets the stage for the two architectural areas described next: the Gateway Services, where event processing and business logic occur, and the Controllers & Handlers, where raw sensor data is translated into actionable events.
Detailed View
Controller
In our architecture, the Controller layer sits directly above the sensors and acts as the first point of intelligence in the system. Rather than streaming raw values into the cloud, the controller interprets sensor data locally, applies lightweight logic, and publishes structured events into the message broker for downstream processing. This approach ensures that the edge device is more than a passive relay — it makes the system faster, more resilient, and more cost-efficient in constrained environments.
Each physical device (temperature probe, current sensor, and relay switch) connects to a dedicated handler, responsible for signal acquisition, data normalization, and event formatting. These handlers are managed by a lightweight Python-based Sensor Controller, which coordinates sampling intervals, manages connectivity states, and routes all outbound traffic through a local MQTT client. For the purposes of this demo, we also included a sensor simulator that can generate realistic signal patterns for testing without hardware dependency.
By raising the abstraction level from “raw readings” to semantic events (e.g., temperature ≥ threshold, backup relay activated), the Controller layer reduces noise in the system and enables event-driven behavior at the gateway. This separation allowed us to clearly define MVP boundaries between edge logic and cloud logic, while demonstrating how local decision-making can continue operating even without a reliable network connection — a core requirement in many IoT environments.
Gateway
Once sensor events are published into the system, the Gateway layer becomes the central decision engine. Rather than treating the cloud as the first point of intelligence, the gateway processes events locally through a set of Dockerized microservices, each responsible for a specific aspect of system behavior.
In a production environment, this layer would host the safety logic that determines when to trigger alerts, activate backup equipment, or escalate a condition for remote visibility. In our demonstration, this approach allowed the system to respond to temperature anomalies in real time, without waiting for a round trip through the cloud, which closely mirrors how edge computing is used to protect assets in the field.
Each microservice subscribes to MQTT topics published by the Controller and evaluates those events independently, enabling a loosely coupled, event-driven design. Decisions are asserted back into the system through new MQTT messages that can drive hardware actions, create alerts, or update the mobile interface.
This separation between event detection at the edge and decision logic in the gateway provided a clean architectural boundary for the demo and highlighted how IoT systems scale: new capabilities can be added by composing additional services rather than changing the core controller logic. The result is a demonstration that behaves like a simplified version of a production IoT stack—flexible, modular, and capable of sustaining local operations even when connectivity is limited.
Mobile Human-Machine Interface (HMI)
The mobile application served as the driver’s primary interface for receiving real-time alerts about temperature anomalies and recommended corrective actions. I collaborated with engineers and designers to define how the app would interact with the gateway, what data needed to be exposed to drivers, and how offline connectivity constraints should shape the user experience.
Because refrigerated trucks frequently travel through low-coverage areas, we designed the app to connect directly to the gateway rather than rely on cloud access. This ensured the driver could still receive alerts, view system status, and respond to failures even without a cellular signal.
The mobile interface demonstrated:
- Direct gateway-to-device communication for reliable alerting
- Real-time temperature and status visualization
- Secure access to MQTT topics scoped specifically for the driver
- Simple triage workflows enabling drivers to activate backups, contact fleet managers, or reroute as needed
By tying edge-level events to actionable, human-centered notifications, the HMI showcased the end-to-end value chain of the IoT platform — from raw sensor data to informed operational decision-making.
Adaptability & Maintainability
A key product requirement for the demo platform was the ability to easily extend or modify the system as new sensor types, edge devices, or business rules emerged. In defining the solution with our engineers, I emphasized modularity and long-term maintainability to ensure the architecture could scale beyond a single demonstration scenario.
Working closely with the development team, we adopted a microservices-based approach in which each processing component could be added, updated, or replaced independently. Sensor integrations were handled through interchangeable “handler” modules on the controller, allowing the platform to support future device types without architectural rework.
In addition, deploying microservices in Docker containers ensured portability across hardware configurations and operating systems — an important consideration for IoT environments with diverse edge hardware. This approach also enabled pre-deployment testing of new logic without disrupting the existing system.
These decisions allowed the demo platform not only to showcase immediate capabilities but to serve as a reusable foundation for future IoT engagements, reducing long-term integration costs and increasing adaptability across client scenarios.
Security Approach
Given the distributed nature of edge devices and the sensitivity of sensor-driven operational data, establishing a strong security posture was essential for ensuring the demo reflected real-world enterprise expectations. I partnered with engineers to define a security approach grounded in the CIA Triad (confidentiality, integrity, availability) and aligned with proven, time-tested security controls rather than custom implementations.
Key measures included:
Encrypted data at rest and in transit to protect sensor and operational information.
TLS and certificate-based authentication between edge components and the mobile application
Least-privilege access controls to minimize attack surface
Hardened device configurations, including the removal of unused services and default admin credentials
Input validation and service-level authentication, ensuring that malformed or malicious data could not propagate through the microservices or message broker
Integration with standard Linux and Docker security practices, reflecting real deployment environments
This ensured the demo not only showcased technical capabilities but also modeled the level of security and reliability expected in a production IoT solution.
Outcome & Business Impact
The final IoT demonstration platform became a core asset for our consulting practice, enabling teams to show clients—in real time—how edge intelligence, event-driven processing, and cloud analytics come together in a production-ready architecture.
Business & Sales Impact
Accelerated sales cycles by giving clients a tangible, scenario-based view of how IoT investments translate to operational value.
Supported multiple successful pre-sales engagements, helping differentiate our capabilities from competitors.
Created a reusable, modular demo platform that other teams leveraged for client workshops, technical evaluations, and architectural discussions.
Organizational Impact
Established a repeatable architectural reference for future IoT engagements, reducing lead time for new proofs-of-concept.
Improved cross-team alignment by providing a shared technical and narrative framework grounded in a realistic operational scenario.
Professional Impact
This project demonstrated my ability to:
Lead the product definition of a complex, distributed IoT system
Collaborate with engineering teams on edge-to-cloud architecture
Translate a fictional scenario into a credible, end-to-end technical implementation
Drive delivery of a working prototype under real-world constraints
Communicate technical concepts to both engineering and executive audiences