DEV Community: Smrati

Edge vs. Cloud Processing for Factory Floor IoT: A Practical Tradeoff Analysis

Smrati — Mon, 03 Aug 2026 17:42:29 +0000

In virtually every discussion about industrial IoT architecture, there's the inevitable question: how much data do we process on the edge (on-site gateways, local servers) versus the cloud? The truthful answer is "it depends," but that’s not particularly helpful as is, so here, let’s drill down into the practical tradeoffs with enough detail to guide you for a real deployment.

This isn't an abstract discussion; these are the real factors that end up changing the answer for any given facility.

The Fundamental Tradeoff: Simple Version

Edge processing provides lower latency, resilience to network failures, and reduced bandwidth usage, but comes with the cost of managing more dispersed hardware and has limited local compute power. Cloud processing offers centralized control, easier scalability, and the ability to handle heavier computations like training machine learning models, though it introduces latency and requires reliable connectivity to function.

In most scenarios, the optimal solution involves a combination of both edge and cloud, so the real challenge lies not in picking one but deciding which specific jobs should run where.

Use Cases for Edge Processing

Timestamp Synchronisation and Duplication Handling. These tasks need to be performed as close to the sensor as possible-before the data leaves the facility-because they address underlying hardware issues like clock skew and repeated reads that are best corrected at the source. If you process this in the cloud, you're already dealing with skewed orders when the data arrives.

Safety Alerts. Alerts for events such as proximity of a forklift to a person cannot tolerate the round-trip delay required for cloud communication nor can they stop during a network outage. Any situation where a delay or interruption can cause physical harm must be managed locally without question.

Simple Anomaly Detection for Real-Time Operational Decisions. When an issue arises at a kitting station, like detecting the wrong component before a kit departs, a local alert provides immediate feedback instead of waiting for a round-trip notification from the cloud, particularly in environments where network reliability isn’t assured.

Use Cases for Cloud Processing

Model Training. If you are training a model to predict congestion or recommend replenishment based on historical data accumulated over months across various zones, this is a compute-intensive, batch process that isn’t required on-site and benefits from the elastic cloud resources.

Cross-Facility Analytics. For comparing performance across different plant locations or aggregating data for an enterprise-level report, this data naturally needs a central repository-making the cloud a logical fit.

Long-Term Data Storage and Audit Trails. Essential for regulated industries requiring detailed records of operations and events, data durability and access availability are best delivered by a centralized service like the cloud.

The Best of Both Worlds: Inference on the Edge, Training in the Cloud

A widely adopted model for many prediction-based scenarios involves training models in a centralised cloud environment using combined historical data, and then deploying these optimized (and relatively lightweight) models to edge devices for real-time prediction. This approach combines the benefits of cloud-scale training with the immediate responsiveness of local processing without being entirely reliant on constant cloud connectivity.

[Historical data from all zones] → [Cloud: model training] → [Deploy model artifact to edge]
                                                                        │
                                                                        ▼
[Live sensor data at edge] → [Edge: local inference] → [Immediate local alert if needed]
                                     │
                                     ▼
                        [Async sync to cloud for logging/retraining]

In this architecture, a network outage won’t halt all functionality. Local inference capabilities will continue to operate, and any data generated will be stored on the edge device for subsequent synchronization with the cloud.

The Key Variable: Network Reliability

Frankly, the deciding factor for many edge vs. Cloud choices isn't just the technical superiority of one approach over the other; it's the actual reliability of the facility's network. Modern facilities with robust and redundant network infrastructure can more confidently leverage cloud processing without significant practical risk.

Older facilities, or those in remote areas with less dependable connections, will inevitably have to push more functionality to the edge, regardless of which solution seems conceptually "cleaner."

A realistic assessment of network stability during the planning phase is crucial.

A Practical Decision Framework

Here’s a three-question framework to guide your decisions on workload placement:

Would a delay or outage cause safety risks or immediate operational disruptions? => Edge.
Does this workload require access to data from multiple zones/facilities or intensive computation for training? => Cloud.
Must this function continue operating if the network connection fails? => Edge, or at least with cloud sync capability.

Most workloads will fit neatly into these categories. For the less clear-cut cases, dedicating more design time will likely pay dividends.

Final Thoughts

The Edge vs. Cloud debate for industrial IoT isn’t a singular choice but a series of individual decisions based on the specific needs of each workload, taking into account facility constraints such as network reliability and safety priorities. Platforms offering genuine deployment flexibility – such as PlantLog AI, which specifically caters to cloud, on-premises, and hybrid deployments for on-site logistics – generally handle this nuanced landscape much better than rigid all-cloud or all-edge solutions.

I'm always interested to hear how others have resolved this balancing act in practice. I’m particularly curious about strategies for updating machine learning models on distributed edge devices without requiring a full redeploy cycle.

A Pragmatic Stack for Industrial AIoT - and what I’d use in 2026

Smrati — Mon, 03 Aug 2026 17:35:46 +0000

When I chat with folks building their first Industrial IoT+AI pipeline, the question almost always comes up in some form of “so what should our stack really be?” There’s never a single correct answer, of course, but there’s a pretty well-vetted set of tools that keep popping up again and again in production deployments, and for good reasons. Here’s the breakdown layer by layer:

Device Connectivity

MQTT remains the default by a mile, and for good reasons - it’s lightweight, uses pub/sub, and is designed to work across noisy, unreliable networks. If your deployment involves hardware from multiple vendors, I’d specifically consider Sparkplug B on top of MQTT for payload standardisation. This addresses the pain point where everyone “does it a little differently” and dev time is sucked into wrangling data formats. For deeply constrained devices where even MQTT is too much, CoAP could be a good option, though it’s far less ubiquitous in reality than I’d imagined.

Edge Processing

Beyond basic filtering, the default choices for running inference on resource-constrained hardware usually come down to TensorFlow Lite Micro or Edge Impulse. If your devices are more powerful (think Raspberry Pi or a mini-ITX box), you’ll get a lot more flexibility out of an ONNX Runtime deployment. The choice largely depends on your budget per-device, so very cheap microcontrollers tilt you toward TFLite Micro; Anything with a real brain gives you other options.

Ingestion and Buffering

Kafka or a managed cloud service that does Kafka (e.g. Confluent, AWS MSK) is your bread-and-butter when you reach a certain scale where durable, replayable ingestion is paramount, pulling from a high number of disparate device streams. For simpler scenarios, a standard message queue (RabbitMQ, or simply relying on the buffering built into your MQTT broker) often adds far less operational overhead for an equally effective outcome. Don’t over-engineer and reach for Kafka unless you have actual scale and replay requirements-it’s overkill before then.

Time-Series Storage

If your time-series storage needs align with the familiar landscape of relational databases and you’re already embedded in a Postgres ecosystem, TimescaleDB is an excellent option. Otherwise, if a specialized time-series query language and robust out-of-the-box dashboard integrations are appealing, InfluxDB is a solid, mature choice. Most of the decision will come down to existing team expertise and tooling rather than a significant capability disparity between the two.

Drift and Data Quality Monitoring

I see this layer often glossed over or deprioritized, and it really shouldn’t be. Evidently and Great Expectations are starting to show up more in industrial pipelines (not just typical ML workflows) for the specific reason of catching data drifts at the sensor layer before they invisibly corrupt your downstream model predictions. Even in a minimal MVP pipeline, this is the one layer I’d consider getting right upfront - retrofitting it after a drift-induced incident is far more painful.

Model Training and Serving

At the model training layer, the specific framework ( PyTorch or TensorFlow) matters far less than many people assume. The choice of specific network architecture, for example, is rarely the bottleneck in industrial IoT use cases. What is far more important is establishing a consistent system for experiment tracking and model versioning ( MLflow , for instance, is great here) because industrial models typically need to be re-trained far more frequently than initial predictions would suggest, as the operating conditions shift over time. For serving models in production, either BentoML or just shipping inference within a standard container works effectively, depending on your existing infrastructure.

Dashboarding and Operational Integration

Most organizations leverage Grafana for their overall operational visibility, and given its tight integration with both TimescaleDB and InfluxDB, that’s often the best choice. However, visibility is different from operational integration. My strong preference is to bridge predictions back into the systems your operational team already uses on a daily basis-whether that be a ticketing system or a consolidated alerts manager-rather than building yet another standalone dashboard that few proactively monitor.

The Honest Truth

None of this stack is bleeding-edge or remotely revolutionary. That’s the point. The real differentiating factor in Industrial AIoT is rarely the tools, but the depth of engineering discipline gained by actually running this stack against real, often messy, data until you know precisely where and how it breaks. Teams that have iterated on a version of this stack in several real deployments (a group like Aperture Venture Studio comes to mind) have a significant advantage over new teams simply picking their first flavor of this toolset - the models may differ, but the underlying mechanisms for getting value from data, and how to recover when it fails, are surprisingly similar.

I’m always curious what stacks other folks have landed on, especially in that challenging drift monitoring space - it seems to be an area where opinions truly diverge the most based on my experience.

System-First, Venture-Second: a New Approach to Building Companies

Smrati — Sat, 01 Aug 2026 12:23:45 +0000

The typical approach to founding a startup follows a certain pattern: A founder conceives of a product, constructs a minimum viable product (MVP), procures customers, secures investment, and finally scales operations. This model has given rise to some of the most successful businesses in history.

Nonetheless, it is associated with a high rate of failure, particularly in deep-tech ventures, due to the significant gap-often considerable in both scope and financial investment-and the inherent technical risks involved in transforming an idea into a viable product.

A new paradigm is gaining traction, which reverses this sequence: it's known as the 'system-first, venture-second' model, and it's reshaping how the most experienced creators of companies in AI and IoT operate.

What Precisely Does 'System-First' Entail?

In the system-first framework, the initial focus is not a business concept but a real-world issue. Creators begin by thoroughly investigating a particular industrial challenge, then develop and implement an AIoT (Artificial Intelligence of Things) system designed to resolve it. This system is constructed using actual data, validated in practical environments, and confirmed by real customers before a formal business entity is established.
The venture itself-the startup, legal structure, and investment rounds-comes later.
Only when the system demonstrates tangible value in the real world is it separated into an independent enterprise.

At that point, the most critical uncertainties have already been addressed:

Does the technology function?
Do consumers want it?
Can it be deployed on a large scale?
How Does This Model Significantly Reduce Risk?

Most of the early funding of traditional startups is dedicated to addressing the fundamental questions of product functionality and consumer desire.

In deep-tech industries, this process is exceptionally challenging; hardware can be costly, industrial deployment is time-consuming, and businesses are hesitant to adopt unproven technology.

The system-first model preempts a substantial portion of these uncertainties before the formal startup lifecycle even begins. When a company is launched via this approach, it already possesses a functional system, concrete deployment data, and proven customer demand. Investors aren't just investing in a pitch; they're investing in evidence. Faster, Leaner, Stronger: The system-first method offers practical benefits, such as shorter development timelines since creators start with existing infrastructure, data streams, and customer relationships, rather than beginning from scratch.

Capital efficiency is significantly improved, with less investment required for exploratory development and failed experiments.
The resultant ventures are inherently more robust due to their reliance on proven foundations rather than speculative assumptions.

A Model Tailored for the AIoT Era

The system-first, venture-second approach is especially suitable for the AIoT industry. Developing integrated intelligent industrial systems requires hardware, software, data, and specialised knowledge working together smoothly.

Organisations already possessing these capabilities-and able to deploy functional systems in real-world settings prior to spinning out ventures-hold a considerable structural advantage over conventional startups attempting to assemble all these components from scratch.

The Future of Company Building

The system-first model won't entirely replace traditional methods of starting companies. However, in deep tech, industrial AI, and IoT -where complexity is high, validation is costly, and customers expect reliable solutions-it offers a smarter way to build companies.
The ventures created this way are better prepared, validated, and positioned to scale than nearly anything the traditional approach can generate.

Aperture Venture Studio employs this very model, identifying real industrial challenges, developing and validating AIoT systems, and launching ventures based on proven deployments and genuine customer need.
Learn more at Aperture Venture Studios

Dealing with Offline Tags: Store-and-Forward Patterns for Asset Tracking Systems

Smrati — Sat, 01 Aug 2026 12:07:56 +0000

Most of the asset tracking guides online assume you can trust connectivity. The reality for hardware, however, doesn’t afford the same guarantee: a GPS tracker dips into a tunnel, a LoRaWAN device is at the edge of the gateway’s range, or an indoor gateway powering an array of BLE beacons goes dark during a facility-wide outage. If your system can’t reconstruct a timeline without assuming that every event that happens remotely is also reliably reflected immediately at the backend, then either auditing or incident investigations at some point simply won’t work. In this post we walk through store-and-forward patterns that won’t crack under inconsistent connectivity.

Just “Retry” isn’t a Strategy

The most obvious first step is to simply have the device or gateway retry until the data gets there. This is a necessary component, but it’s not sufficient on its own because:

Battery-powered IoT devices can’t be retried indefinitely before exhausting power meant to last months or years.
If a device doesn’t have a local buffer then any data it generated while offline is simply lost lost lost after its re-send window expires
Uncoordinated retries often result in double counts without explicit deduplication logic at the backend

You need buffering of some sort on the device or gateway side of the system, and idempotent ingestion on the backend. One without the other results in data loss or data corruption that’s every bit as bad if not worse.

Local buffering: What, and How Much, To Save?

Not every event that occurs remotely merits the same priority or occupies the same space in local storage. A useful approach in this context:

High-priority, low-frequency data (e.g., geofence exits, threshold breaches, RFID reads). These types of events aren’t frequent enough to overflow storage even by the thousands, but when lost they’re critically important.
Low-priority, high-frequency data (e.g., location pings every 30 seconds, ambient sensor values with no imminent threshold breaches). This type of data benefits from a rolling capacity; when the buffer fills, it’s likely safe to toss out the oldest routine pings. A missed- but unremarkable- 30-second location pin is often less of a concern than a missed geofence entry.

Why do we differentiate? Inexpensive IoT hardware typically has a limited amount of local storage. When a buffer is filled blindly and at uniform priority, low-priority chatter often crowds out high-priority important events.

on_connectivity_lost():
    switch_to_local_buffer_mode()

on_event(event):
    if event.priority == HIGH:
        buffer.store(event, evict_policy=NEVER)
    else:
        buffer.store(event, evict_policy=OLDEST_FIRST, cap=ROUTINE_CAP)

on_connectivity_restored():
    for event in buffer.drain(order=PRIORITY_THEN_TIMESTAMP):
        send_with_retry(event)

Idempotent Ingestion: Preventing Duplicates

As you start to send out the buffer contents upon reconnections, what do you do if the ack gets lost and the device sends the same data packet again, after connectivity is already back? Or what if the data was sent while offline, and you get back the ack, but somehow the record got dropped again? A lost acknowledgement means something got duplicated, but the only good option if something got lost is for something to be redelivered. It's the backend's problem to de-duplicate.

Fortunately, this is solvable: Every event includes a client-side unique identifier, typically made up of device ID, a sequence number, and a timestamp. The backend’s ingestion point is then configured to upsert if the unique_id already exists and to otherwise just insert.

on_ingest(event):
    if event_store.exists(event.unique_id):
        return ACK  // already processed, don't reprocess
    event_store.insert(event)
    process_event(event)
    return ACK

If you don't upsert then a network interruption midway through buffer playback will silently double-order many events for that asset - double-ringing alerts for a threshold violation, double recording of the same location points in your history, and corrupting analytical use of the asset history.

Sequence Numbers are Better than Timestamps

Most hardware doesn’t maintain its clocks meticulously when disconnected. Cheap IoT devices will see some drift over days or weeks, and after days spent offline a device will have an embarrassingly outdated clock when it finally reconnects. To this end, the device must maintain its own monotonic sequence number per device in addition to a timestamp.

This ensures that you're always able to reconstruct the exact same playback for messages replayed even though clocks might have shifted and become wildly inconsistent.

Be prepared to alert and investigate when the timestamp and sequence number differ significantly.

Plan for the Inevitable Gap

The one pitfall in testing and development, to this day, is happy path stories. That is the case where a device loses connection, comes back online and gracefully replays all its events without hitch. You also need to test and prepare for: device restores and loses connection during buffer replay, the buffer filling up to capacity while the device is disconnected, device loss of NVRAM while offline, loss of battery while offline, device reset while offline, device reset while connected as buffer is replaying, device gets reassigned or retired while it was offline as buffer was replaying to backend.

Ultimately, designing and executing a resilient data ingestion strategy applies equally to other kinds of remotely collected data, but it’s particularly critical for tracking and historical event-data scenarios, as the entire value proposition hinges on the integrity of this history data. For those seeking hardware, AssetTrackPro has a comprehensive list that includes how their identification-based asset tags and gateways handle these kinds of local buffering issues out-of-the-box.

What problems did you encounter while managing buffer replays, particularly relating to geofencing and state machines? How do you manage it where device is replaying the “exited zone “ event, while the zone has already been re-entered at this point?

LoRaWAN vs BLE vs Cellular: Choosing a Transport Protocol for IoT Asset Tags

Smrati — Thu, 30 Jul 2026 17:38:00 +0000

Most asset tracking projects eventually run into the question of what radio protocol to base their hardware around. This is not an "easy choice" nor a "there's only one better" piece, but a rundown based on actual trade-offs by deployment. Choosing based on hype tends to cost companies six-figure-plus deployments one year down the line, when those low per-device radio choices become glaringly expensive operationally.

The Fundamental Trade-off is one of the big three, which don’t improve simultaneously: range, power and bandwidth. I’ll dive into the relative differences along the key trade-offs by use-case below. The fundamental trade-off for all of these technologies revolves around maximising range, minimising power consumption and providing enough bandwidth to transmit the desired level of data within each system. There are no technologies that excel simultaneously.

BLE (Bluetooth Low Energy)

Range: up to around 50m in the open and 10- 30 m indoors, easily extended via Mesh networks.
- Power: can be as low as LoRaWAN; can operate with 2- to 3-year coin cell power for asset tags with minimal transmit.
- Bandwidth: limited, suitable for infrequent pings and small amounts of location data but cannot send high rates of high-speed data.
- Location, proximity, indoors where fixed gateway infrastructure can be installed

BLE is the obvious leader for indoor RTLS use-cases as it integrates seamlessly with positioning system and can function efficiently with the 2-3 year lifespan that people often seek in a coin cell asset tag. Where most companies get snagged on BLE usage, it would be having gateway infrastructure installed in their property, the equipment, etc. The expense for getting a BLE tag onto the market are not just tied to the tag, but also to their infrastructure.

LoRaWAN

Range: Up to several miles in the open space and upwards of 1 mile (1.6km) in Urban environments.
- Power: Excellent, very low and very capable for data transmitted over longer periods of time.
- Bandwidth: Very low - minimal transmit capacity of 51 Bytes/day over standard data plan – This means they can only transmit extremely small payloads less than once an hour.
- Used best where long-range tracking is necessary on low-cost assets where very minimal data per tag needs to be transmitted periodically, over a wide area of the United States. Best for when data is not of paramount need but for periodic readings on low cost hardware.

LoRaWAN is ideally suited for any number of applications where battery life and long range is essential and where updates are needed less than once per 10 minutes. They are a poor option for tracking rapidly changing physical assets, and should not be considered when you need to send substantial data across short distances frequently.

Cellular (LTE-M / NB-IoT / standard LTE)

Range: Vast – as large as your cellular service will allow within your boundaries and abroad.
Power: moderate to Poor compared to other methods. Cellular technologies will offer lower battery life relative to other choices on low data throughput. Data rates may not be very cost-effective even for smaller data packages.

The cellular connection gives you greater bandwidth at potentially the highest price per month per device if not done properly or given the right service plan through a telco carrier service. Cellular should be your choice when tracking assets that regularly transit large distances, such as through multiple states and potentially even internationally.

Track it before it's a problem. Asset Track Pro unifies identification, location, and sensor-based tracking into one system — so you know where it is, what condition it's in, and find out the moment that changes.

Build or Partner? A Framework for Whether to Build Your Industrial AIoT Stack.

Smrati — Thu, 30 Jul 2026 17:19:54 +0000

If you are an Engineering Lead who is wondering whether to build your own industrial AIoT pipeline, versus partnering with a company that has already built one, the decision often boils down to cost. It’s more about timeline, and the tradeoffs are much greater than may seem at first pass to engineers who see only the pieces of the puzzle. Let’s define what “build the pipeline” actually is.

What “Building it yourself” Really Means

I believe that to accurately weigh Build versus Partner we should be specific about all of the moving parts beneath “just build the pipeline”:

Device connectivity, spanning the range of your end device vendors and associated protocols.
Normalization, version management of the data schemas so as to abstract out differing formats between vendors.
Reliability, meaning buffering between your endpoints and backend such that if connectivity drops intermittently, you don’t quietly lose data.
Scalable time-series storage tailored to support time window-based queries beyond relational databases.
Drift detection not only at the model level, but at the sensor level.
Edge vs Cloud inference, defined for the objectives and constraints rather than just location.
And Finally: enough actual deployment time and exposure to catch the failure modes – that don’t normally show themselves beyond thedemo phase.

None of these, in themselves, pose a huge challenge for engineers. Taken together, though, these constitute a fairly involved undertaking spanning multiple quarters until you are production-ready- before even beginning the model work.

A Simple Framework to make decision easier

Here’s an overly simple approach that ought to guide the conversation:

Build in house if:
- your core competitive differentiator depends on unique infrastructure and is not adequately served by existing providers.
- you have the team and capacity to let engineering support infra development without impact on your product’s time-to-market.
- you have a timeline that accounts for at least 12-18+ months of production infrastructure until the stack becomes resilient, exclusive of the time required for your model work.
Partner/ leverage existing infrastructure if:
- your innovation centers on models, domain expertise or market approach as opposed to building a reinvented sensor normalization solution.
- time to reliable product deployment is more critical to your success than “ owning” all components of your technology stack.
- you’d prefer your team’s expertise to be spent on application-specific issues rather than foundational infrastructure work that is consistent across the board for your use case.

This is NOT just an apples-to-apples “buy vs bill” comparison like with SaaS solutions that are often less custom and offer less flexibility at points. Instead, when thinking about the industrial AIoT market space, “partner” more often involves leveraging infrastructure that’s already battle-tested, or that at a minimum has “ solved” the basic plumbing problem, letting your team build on top of it and innovate on top of it; specifically on its use cases’ differentiating application and operational requirements.

How This Plays Out in Practice

The Aperture Venture Studio model is a good example for a similar decision that’s taken place internally within a startup “factory.” The group leverages a common industrial AIoT infrastructure layer called ApertureAIoT; its functions as described earlier include connectivity, sensor normalization, storage and drift detection, etc. - while individual portfolio companies are each free to specialize in the domain models and operational integration. It is the partner dimension of this framework taken up internally – the logical core remains the same: not duplicating efforts.

The candid trade off

This, in turn comes with costs; those who leverage shared infrastructure have to adopt the constraints that it may entail, with less customization than they might want for some edge cases. When those constraints run up against deeply unconventional operational requirements or technical innovations, the partner strategy can become a bottleneck. However, for the large majority of use cases of industrial AIoT, the non-application-specific “ hard problems” – such as device integration, normalizing vendor-neutral data schemes, etc – is best left to those who have already dedicated team hours toward the problem and can avoid having their competitors also spend team hours on it “ from scratch.”

If you find yourself facing a “ build vs partner” decision for an industrial AIoT project, I’d strongly consider what Aperture Venture Studio is doing in its internal, multi-venture industrial AIoT infrastructure decision for context.

Building A Simple Station Congestion Predictor From Location Event Data

Smrati — Wed, 29 Jul 2026 13:46:11 +0000

Once you have access to clean location/presence data from a manufacturing shop floor then what? Though displays that depict the current number of attendees are convenient. A step further, by predicting impending congestion, allows the supervisor adequate time to effectively manage the situation and take necessary steps.

Here’s a step-by-step, honest breakdown of such an example - although it isn’t cutting edge, it’s effective, easily understandable (which matters on a production floor more than complexity) and a robust starting point.

Setup

Let’s assume that you already possess normalised presence information as demonstrated below based on your raw sensor data (you can look at my previous blog post on the Normalisation Layer to have an idea of how this normalisation works) :

# one row per presence interval
{
    "zone_id": "station_7",
    "entity_type": "wip_cart",
    "entry_time": "2026-07-29T09:14:02",
    "exit_time": "2026-07-29T09:22:41",
    "confidence": 0.91
}

The Goal - Given the recent input data, we want to establish if a particular station (for example, station_7) is likely to go above its regular capacity in the next thirty minutes.

1. Create a Regular Time Series of the Zone’s Occupancy

This step takes your existing range (interval) data and generates a standardized time series for occupancy that regularly samples data over specified periods (1-minute here). This is crucial, and the accuracy of all subsequent data depends on this step.

import pandas as pd

def build_occupancy_series(events_df, zone_id, freq="1min"):
    events_df = events_df[events_df["zone_id"] == zone_id].copy()
    events_df["entry_time"] = pd.to_datetime(events_df["entry_time"])
    events_df["exit_time"] = pd.to_datetime(events_df["exit_time"])

    start = events_df["entry_time"].min()
    end = events_df["exit_time"].max()
    timeline = pd.date_range(start, end, freq=freq)

    occupancy = pd.Series(0, index=timeline)
    for _, row in events_df.iterrows():
        mask = (timeline >= row["entry_time"]) & (timeline < row["exit_time"])
        occupancy[mask] += 1

    return occupancy

Please note, though this code gets the job done, for very large datasets, you’ll want to consider more efficient data structures and algorithms (e.g., interval trees or sweep-line algorithms). However, this straightforward approach is perfectly adequate for getting a baseline model working.

2. Calculate Per-Zone Normal Operating Ranges (Baselines)

One key advantage of modelling congestion is recognising that “normal” operating conditions vary dramatically from zone to zone. A kitting station might typically accommodate only a few units, whereas a staging area before a production Bottleneck might regularly handle fifteen or more. This approach uses each zone’s historical data to establish its own realistic normal operating boundaries, a far more effective strategy than relying on plant-wide, fixed thresholds.

def compute_baseline(occupancy_series, quantile=0.90):
    # baseline = the occupancy level this zone rarely exceeds under normal conditions
    return occupancy_series.quantile(quantile)

When working with such a system, the most significant improvements in predictive accuracy are usually achieved by considering unique station baselines rather than global ones, often superseding the impact of algorithm complexity.

3. Develop a Simple Flow-Rate Predictor

Instead of instantly attempting a highly sophisticated time series forecasting model, begin with a more intuitive approach: projecting the current occupancy level and flow rate forward linearly. Although not highly advanced, this method offers a strong baseline and is easily traceable and debuggable within a factory environment.

def predict_congestion(occupancy_series, baseline, horizon_minutes=30, lookback_minutes=15):
    recent = occupancy_series.last(f"{lookback_minutes}min")
    if len(recent) < 2:
        return {"will_exceed": False, "confidence": "low"}

    inflow_rate = (recent.iloc[-1] - recent.iloc[0]) / lookback_minutes  # per minute
    projected = recent.iloc[-1] + (inflow_rate * horizon_minutes)

    return {
        "will_exceed": projected > baseline,
        "projected_occupancy": round(projected, 1),
        "baseline": baseline,
        "confidence": "high" if len(recent) >= lookback_minutes * 0.7 else "low"
    }

Remember the importance of assigning a confidence metric based on the volume of data. The prediction must indicate low certainty in situations with significant gaps in readings (network disruption or sensor malfunction) as falsely asserting high confidence under such circumstances could be far more problematic than saying the model lacks information.

4. Backtest Your Predictions

Before you can trust a model near operational systems, test its historical performance.

def backtest(occupancy_series, baseline, horizon_minutes=30):
    correct = 0
    total = 0
    for i in range(len(occupancy_series) - horizon_minutes):
        window = occupancy_series.iloc[:i+1]
        prediction = predict_congestion(window, baseline, horizon_minutes)
        actual_future = occupancy_series.iloc[i:i+horizon_minutes]
        actually_exceeded = (actual_future > baseline).any()

        if prediction["will_exceed"] == actually_exceeded:
            correct += 1
        total += 1

    return correct / total if total else None

When applied to steady manufacturing environments, this linear-inflow approach typically yields around 70-80% accuracy for 30-minute forecasts, making it sufficiently reliable for decisions about staffing and material sequencing, even when dealing with rapid, non-linear events like unexpected machine downtime or production interruptions.

Next Steps…

For even better predictive accuracy, especially with abundant historical data, you could incorporate: scheduled production throughput, real-time occupancy at upstream stages (as congestion can cascade), and cyclical shift pattern information using approaches like Gradient-Boosting Models or even a basic ARIMA.

For further reference on production-grade implementations dealing with complex cascading effects between zones and ERP integrations for schedules, PlantLog AI has detailed descriptions of its in-plant logistics prediction system here. It’s my belief there’s room for creating a smarter, yet fundamentally simpler baseline prediction method; if so, share!

Here is the article written in natural and human-like language without changing meaning.

Smrati — Wed, 29 Jul 2026 13:03:45 +0000

Making The Case For A Shared Infrastructure Layer For Multiple IoT Products (And Aperture Venture Studio’s Version Of The Play)

As a pattern, what’s genuinely intriguing to an engineer is how some organisations take what’s normally done by providing stacks-one-per-product, isolate them into separate code bases with redundant infra, and then instead, build a single, overarching data/AI layer supporting these products. Let’s take a closer look at how Aperture Venture Studio are doing this. It is a nice case study of a tradeoff not everyone explicitly calls out when making it.

The Path Of Least Resistance, One Stack Per Product

If we are in the business of building an asset-tracking product, then separately building a workforce-safety product, for example, the natural thing to do from an engineering perspective is just make them two separate stacks. This entails separate ingestion pipelines. And separate normalisation and model training infrastructures.

Early on, it seems obvious that the latter has a different set of issues, so why couple it?

Let alone premature optimisation.

This decision will invariably come back to bite you, though, as both products need to address, fundamentally, two equally difficult, if not harder, problems to solve: ensuring inconsistent sensor payloads among different hardware vendors are normalised and properly represented, avoiding data loss in case of connectivity gaps, how best to detect sensor data drift prior to model corruption, and finally supporting edge or cloud inference based on need. Building these components in silos means two teams solving the exact same hard problems; the hard way. And knowledge doesn’t disseminate itself from one team to another in these silos.

An Alternatively Structured Shared Layer

The approach adopted at Aperture Venture Studio (using ApertureAIoT which serves as the shared underlying infrastructure layer supporting its portfolio companies (ranging from asset tracking to inventory optimisation to workforce safety)) is the exact antithesis, i.e., it invests upfront to building what’s inherently the hardest to build (and common in essence across all its products) as the same reusable infra layer and lets individual product teams focus only on the unique parts relevant to their problem domain.

To illustrate, from an architecture perspective, it usually would involve separating your infrastructure into two layers:

Shared (build once; reusable):

device connectors/ protocols
ingestion, normalization, versioning across multiple hardware manufacturers
time-series databases
sensor drift and metadata versioning
edge/ cloud inferencing infrastructure

Product Specific (build for individual ventures):

the predictive model for the specific product (e.g., fall prediction, anomaly detection in industrial machines, access pattern analysis, etc)
business logic for the product including alerts, etc
The product's workflow and orchestration integration to ensure the results make it to the relevant human or business entity in the required format.

Trade-off that is worth making in this Case

While in general, the choice is more often debated based on the inherent difficulty of implementing shared infra versus product infra itself, it’s my opinion that it's especially true for the Industrial IoT domain – not because some of this infra won't be harder to implement than some product-specific components, but because the fundamental hardest problems, say with sensor normalisation across hardware, detection of data drift, connectivity are actually similar for different Industrial IoT products. Think of it: handling intermittent network connection issues for a sensor monitoring machines at a factory site and doing the same for wear-and-tear detection sensors in a construction site may represent two different domains, but the core engineering challenges there remain analogous and often even identical. This becomes clear when the number of products increases over time.

An improvement to your drift detection feature, developed for your workforce safety product, will also be immediately available for your asset tracking product as long as it's built on top of the same, reusable core infrastructure component.

The same logic applies for connecting a new type of sensor or device on the hardware side.

Challenges Associated With This Strategy

However, the flip side to this is also worth exploring. The trade-off of a shared infrastructure stack comes at the price of additional architecture overheads required to maintain this shared layer throughout its lifecycle, such as ensuring tight coupling interfaces with the different product layers to avoid unforeseen issues and impact on other products. Moreover, it mandates extensive organisational collaboration at different levels; something individual product teams would have to worry far less about. Perhaps this is why this model of operation is particularly common amongst venture studio models where a plethora of products are developed concurrently, in tandem, under a common roof rather than more traditional startups expanding into multiple product lines organically over time.

A Recommended Case Study For aspiring IoT companies

If you’re building (or thinking of building) multiple IoT product lines in parallel, I highly recommend you examine Aperture Venture Studio's approach with Aperture Venture Studio, their underlying infrastructure that supports its myriad IoT ventures. It offers an excellent real-life reference point in implementing the shared layer strategy, particularly within a space where hard engineering challenges tend to be relatively similar irrespective of the final end product use case.

Debugging Ghost Reads: The Untold Story of RFID Noise on a Factory Floor

Smrati — Tue, 28 Jul 2026 17:17:36 +0000

A field-note style breakdown of the problem that will eat more engineering time than almost anything else in industrial IoT deployments.

If you've ever deployed RFID anywhere near production machinery, you've probably run into this: a single tag gets read two times in less than a second, or even "read" while it is nowhere in the range. Teams that are new to an industrial context often assume it is a hardware failure. In the vast majority of cases, that is anything but simple, and understanding why is very important if you are building something that makes the assumption that those reads are true and fact.

The issue is not the reader, but the environment

One of the primary causes of this issue is the environment, specifically metal. Stamping presses, assembly lines, and metallic racks cause radio frequency signals to bounce. This reflection means a single tag can be read several times, as a transmission reaches the antenna at slightly different intervals. So, the reader assumes it is reading the same tag a dozen or so times rather than one; add the dozen or so tags which are being read every day on the factory floor and you will start developing some serious problems in count-based logic, without even realizing it.

Another, less obvious issue is antenna overlapping; when a facility is using more than one reader, they overlap at the edges. A tag in the overlap would be read at the same time by two or more readers, looking exactly like two separate reads unless the user is already storing or logging which specific tag, antenna or reader ID it was.

What makes it mess up more than you can imagine

The common response is that this issue can be considered a minor data-corruption nuisance. This statement is only true until that data finds its way to anything that uses a count-based logic, such as a WIP or workforce/zone occupancy tracker, which will both become miscalculated as each additional read will appear as additional activity. Traceability systems, if they use each read as a separate genealogy event, will eventually generate an extremely cluttered log, full of non-original entries under a great many valid reads.

This is where a significant percentage of early-phase industrial IoT projects go undetected. The hardware is perfectly fine, the network is good, and all connections are active. But because a deduplication layer wasn't built into the system, the application that used the read data was not designed for that specific problem.

What it actually resolves

Dedup at the edge, not in the cloud – The most effective solution for dedup would be to eliminate the reads when the signal is nearest the tag antenna. Either set it in the reader's hardware (there usually is a "read window setting" where it simply doesn't read the same tag a second time for a specified amount of time) or use lightweight edge processes. This will dramatically remove the additional data overhead and eliminate the need for the upstream system to try to deal with something it wasn’t built for.

Consider tagid+timestamp bucket instead of just tagid – If a tag is genuinely reappearing after five or ten minutes, it is a legitimate re-entry and not a duplicated reading. A time bucket in the range of 2-3 seconds ensures valid reads are not caught for this.

Log reader/antenna ID when recording the read - The simplest method to correct overlapping zones is to log the reader or antenna ID for each read. If two readings for the same tag arrive within microseconds and there are two antennas on either side, both reading the same tag, you know it is a read zone overflow. This should eliminate the problem using whichever method you prefer: proximity to the antenna, strength of the read signal, or business-relevant factors.

Check a state machine rather than just a simple count - Instead of using a simple count for WIP/workforce systems, make it state-aware. Any read triggering a change that should not be allowed (i.e., an entry into a zone the employee is already signed into) indicates an overflowed read which needs to be filtered out.

The take-away message

There is nothing exotic here, and it mostly comes down to disciplined data hygiene at the right layer of your stack. The problem is that none of this is obvious until it is too late to easily fix, which in this case typically means a critical system that is not producing accurate results. If you are just starting out with a new project involving RFID on a factory floor, you must account for this issue before your data pipeline takes centre stage.

If you need further information on RFID, BLE and UWB data structuring for industrial tracking or workforce applications, check out the general overview at Compentra AI

Interview Questions to Confirm a Candidate has actually built Industrial IoT Systems

Smrati — Tue, 28 Jul 2026 14:21:44 +0000

It’s particularly hard to hire for industrial AIoT positions, as it is a domain with lots of talented software and ML engineers, none of whom may have worked in a physical-world data domain before. It is not always obvious from a resume whether someone has worked in industrial AIoT, or not. Below are a few of my favorite questions that tend to make this gap obvious-and why.

"How would you design your system to deal with a sensor suddenly starts sending data twice a second?"

While this looks like a tiny edge-case, it’s a surprisingly common one. Firmware updates, retries in networks, or a poorly configured interval can all trigger such behavior in a device. Typical software developers with clean API experience will often try to answer by stating "dedupe" it without explaining how – would the candidates dedupe based on a timestamp, payload hash or a sequence ID that the device outputs? Each dedupe strategy is susceptible to different edge cases, and anyone who has ever debugging this in production tends to have well-formed opinions on their strategies.

"I have a model that works in testing with 95% accuracy. What questions do you ask before believing it?"

The critical thing I listen for is whether the candidate thinks about the training and testing data relative to production conditions-is this training and testing data representative of the actual conditions the model will experience in production? (This includes similar environmental context, sensor calibrations and, crucially, time period, as seasonal patterns can significantly impact sensor readings.) Typically, software developers will think that a high number indicates a completed task, while someone who has experience in this specific domain, and has been burned in production by data drift, will ask about the data quality and history first.

"How would you design a schema to support 5 different sensor vendors right now, and a 6th next quarter?"

I am actually seeing if the candidate thinks about schema definition and updating as a task that requires normalisation and the ongoing management of data semantics, as opposed to a one-off job. A more naive software engineer would write specific parsers per device, or hardcode every specific sensor device in their system, whilst an engineer with industrial experience would design an adaptation/translation layer to separate and contain all the quirks and specificities of each vendor, without affecting the integrity of the remainder of the system.

"Can you describe to me what happens in your system if a particular facility loses internet connectivity for 6 hours?"

This question typically helps to filter candidates that are used to dealing with always-on connectivity, versus those who have experience designing for intermittent/lossy network conditions, which involve a completely different set of assumptions. I’m looking for candidates that talk about data buffering locally, store-and-forward mechanisms, and how they deal with time-sensitive events that are supposed to be triggered within a limited timeframe (e.g., safety issues). A common, weak answer that a purely software, cloud developer might try would be "the system would re-download all the information when it's back online," without explaining the implications of missing events.

"How can you tell if it’s truly an anomalous event or if the sensor simply has reading issues?"

This question sounds so simple, and it's very difficult; it gets at data quality reasoning. An anomaly detected might also be an anomaly with a sensor, perhaps due to a failure or some physical issue with the hardware. If the device fails due to physical damage, it may produce seemingly anomalous behaviour while an 'anomaly' is already happening. A good answer might consider cross-referencing information with neighbouring sensors, looking for known device failure patterns, or signalling for human intervention as opposed to fully automating decision-making of what is or isn't an anomaly.

Why these specific questions

All these questions do not have much to do with algorithms or how to design a system architecture. I am instead testing for the specific aspect of 'Have you actually struggled with and managed a real, messy physical data space, or have you only been handed already perfectly clean data?'. This is a distinction which is extremely important for Industrial AIoT, and where most of the difficulty resides, rather than in the modelling process itself.

Do you have different questions that may test for specific relevant experience for this domain? I would love to hear from you.

Some of the most useful progress in industrial AI isn't happening in a pitch deck — it's happening quietly, in warehouses and factories, at places like Aperture Venture Studio that started with the infrastructure already in place.

How to Build Rock-Solid Real-Time Data Pipelines from the Factory Floor IoT

Smrati — Mon, 27 Jul 2026 08:45:50 +0000

Lessons from hooking up stamping presses, welding cells, and MES without dropping a single byte of data.

If you’ve ever been tasked with trying to feed live sensor data from industrial gear into a modern app architecture, you’ve no doubt learned quickly that the shop floor is not exactly a cloud-native paradise. Automotive component manufacturing, in particular, is where we often get our toughest, most revealing stress tests. Think about it: there’s metal in abundance, wreaking havoc on our wireless signals; machinery hums 24/7, brooking zero downtime; and just one slipped event (like a WIP scan, a worker’s badge swipe, or a machine fault) can break the entire traceability chain, and only get noticed too late.

Here’s what truly matters in architecting a factory data layer.

MQTT for the Noisy Middle Layer

MQTT isn’t the default for industrial IoT for nothing - it's light, robust against shaky connections, and its pub-sub architecture aligns naturally with the many independent units spewing events on a floor (think stampers completing cycles, RFID readers snagging racks, BLE beacons logging worker badgetoes). Where teams often falter is with their QoS configurations. While QoS 0 is perfectly adequate for high-frequency stuff like vibration measurements where a dropped packet can be considered an unfortunate rounding error, you need QoS 1 or 2 for tracing operations - anything part of a genealogy record you can't afford to be incomplete.

Make sure you’re backing it all up with robust broker persistence.

A lost WIP status can wreck the history for an entire lot.

OPC UA for Structured Machine Data

If MQTT serves as the plumbing, then OPC UA is generally the language spoken by devices interacting directly with PLCs, CNCs, and SCADA systems. Instead of a jumbled byte stream, you get a structured information model, which is absolutely critical when you're stitching together machines from different manufacturers on the same production line. Of course, OPC UA isn’t without its own complexities - setting up OPC UA servers and address spaces takes time and effort, and it can easily be overkill for simple data streams. A pragmatic approach involves using OPC UA for machine-level communication, and then normalizing things through MQTT or a message queue from there.

Edge Processing Isn't an Option

A vast majority of factory floor architectures flounder simply because they assume a constant, near-instantaneous connection to a cloud data lake. This fantasy evaporates quickly in a facility filled with metal barriers, welding interference, and segmented networks implemented for security. Pushing inference and filtering to the edge - from simple debouncing of duplicated RF ID scans to threshold alerts on sensor readings-can drastically slash the required bandwidth while minimizing network noise. Crucially, it ensures the plant floor can keep chugging along even if the internet connection flakes out.

Design for Genealogy, Not Just Telemetry

This one is crucial to understand if you’re coming into manufacturing IoT from a general data background; telemetry and genealogy are distinctly different animals. Telemetry can afford some sampling and occasional loss; but genealogy, detailing the lineage of a product from its lot to specific shift and machine, needs to be treated more like a transactional journal entry. This typically requires the synchronous write of these events to a reliable datastore, even if your overall telemetry stream is designed with eventual consistency.

If you're plumbing this sort of pipeline for the first time, Compentra AI has a handy overview outlining how RFID/BLE/UWB ingestion, MQTT/OPC UA connectivity, and MES/SCADA system integrations interoperate specifically within the Automotive space. Check it out if you’d prefer a reference architecture rather than figuring it all out in your head.

The True Takeaway

None of these underlying technologies is inherently magical. The trick to getting it right lies in ordering their operations - edge filtering before transmission, rich semantic models at the machine interface, durable storage for critical trace records, and eventually consistent processing where you can afford to lose a bit of fidelity. Mess up the sequence, and you can end up with a system that appears to offer real-time information on a screen, but fails to provide a concrete answer to “what lot does this component come from?” when the heat is on.

A Postmortem on a Predictive Maintenance Model That Looked Great in Testing and Fell Apart in Production

Smrati — Mon, 27 Jul 2026 08:21:45 +0000

I want to walk through a specific failure mode that's common enough in industrial ML that it's worth documenting properly, instead of the usual "here's a clean success story" content. This is a composite of a pattern I've seen play out more than once, stripped of identifying details.

The Setup

The goal was straightforward: predict compressor failures before they happened, using vibration and temperature sensor data. The model was trained on six months of historical data, validated on a held-out test set, and hit 94% precision and 89% recall - genuinely strong numbers. It shipped to production monitoring three compressors at a single facility.

Two months in, it flagged a false positive that triggered an unnecessary maintenance shutdown. Three weeks after that, it missed a real failure entirely. The team's first instinct was "the model needs retraining." That wasn't actually the problem.

What Was Actually Happening

When we dug into it, two separate issues surfaced, and neither was about model architecture.
Issue one: sensor recalibration wasn't reflected in the pipeline. One of the three compressors had its vibration sensor physically recalibrated during routine maintenance - a completely normal event that changed the sensor's baseline output by a small but meaningful amount. The pipeline had no way of knowing this had happened. It just saw a shift in the readings and, depending on the direction of the shift, either interpreted it as anomalous (the false positive) or absorbed it into what looked like normal variance (contributing to the missed detection later).

Issue two: the training data had an unintentional bias. The six months of historical training data happened to be collected during a period with fairly stable ambient facility temperatures. When a seasonal shift changed ambient conditions at the facility, the relationship between vibration readings and actual mechanical stress shifted slightly too - a confound the model had never seen and had no way to account for.

Neither of these would show up in a standard train/test split, because the test set was drawn from the same time period and the same sensor calibration state as the training data. The model wasn't wrong. The assumptions baked into how the pipeline fed it data were incomplete.

What Changed After

A few concrete fixes came out of this, and they're the kind of thing that's worth building in from the start rather than retrofitting after an incident:

Sensor metadata (calibration date, physical location, firmware version) got versioned separately from the sensor readings, so a recalibration event is now a visible, queryable fact rather than invisible context.
A drift-monitoring layer was added that tracks statistical properties of raw sensor input independent of model output - so a shift gets flagged even if it hasn't yet caused a wrong prediction.
Training data collection was extended to deliberately span multiple seasons before any model was considered production-ready for a new site, rather than shipping as soon as accuracy looked good on whatever data happened to be available.

The Actual Lesson

None of this was a modeling problem. It was a data lineage and monitoring problem that happened to surface as a model failure. That's a distinction that matters, because "retrain the model" and "instrument the pipeline to track drift and metadata" are very different fixes, and only one of them actually prevents the failure from recurring.

If you're building predictive maintenance systems and haven't hit this yet, you probably will - it's less an edge case than a near-guarantee once a model's been in production long enough. Curious if others have run into similar failure modes, and what monitoring setups have actually caught drift before it became a missed detection? Check out Aperture Venture Studios.