DEV Community: Growth Muse

What Pharmaceutical Manufacturing Can Learn From Industrial IoT

Growth Muse — Mon, 21 Sep 2026 21:49:23 +0000

Pharmaceutical manufacturing has a data problem.

Not necessarily a lack of data. In many facilities, there is plenty of it.

Machines generate readings. Warehouse systems record inventory. Quality teams maintain records. Manufacturing systems track production. Sensors monitor environmental conditions. Enterprise software handles everything from planning to purchasing.

The harder problem is getting all of those pieces to work together.

A production manager may know that a batch is delayed, for example, but finding out why can require looking across several systems. An asset may be somewhere in a facility, but its location might not be immediately obvious. A temperature reading may exist, but connecting that reading to a particular production event can require additional investigation.

This is where industrial IoT and AIoT become interesting.

The real value of IoT isn't the sensor

It's easy to think of industrial IoT as a collection of connected sensors.

Put a sensor on a machine.

Track an asset with RFID.

Monitor room temperature.

Collect the data.

But collecting data isn't the same thing as creating useful information.

The interesting part begins when those individual data points can be connected to operational events.

Imagine a pharmaceutical facility where a piece of equipment is being used during a production process. Now combine:

The equipment's location
Its utilization history
Environmental readings
Production records
Maintenance information
Material movements
Relevant quality events

Individually, these are just data points.

Together, they can provide a much clearer picture of what is happening on the manufacturing floor.

That's the direction in which industrial IoT is moving: from simply monitoring things toward understanding relationships between things.

RFID and BLE solve a surprisingly practical problem

One of the less glamorous problems in manufacturing is simply knowing where things are.

Equipment, containers, materials, tool

Building AI for the Physical World Is a Different Engineering Problem

Growth Muse — Mon, 21 Sep 2026 20:58:30 +0000

Why taking AI out of the browser changes the way we think about software architecture

A lot of modern AI development happens in a very comfortable environment.

You have an API, a database, a model, a frontend, and a relatively predictable network connection.

Then you put that same intelligence into a warehouse, factory, construction site, vehicle, or other physical environment.

Suddenly, the assumptions start falling apart.

The network disappears.

Sensors produce noisy data.

Hardware fails.

Devices have limited compute.

The environment changes in ways your training data didn't anticipate.

And, perhaps most importantly, the output of your software can affect something in the real world.

That's what makes physical AI and industrial AIoT interesting from an engineering perspective.

The difficult part isn't simply putting an AI model next to an IoT device. It's designing a system that can reliably connect the physical world to software and turn imperfect observations into useful decisions.

The architecture is bigger than the model

A typical AI application might look something like:

User
  ↓
Application
  ↓
API
  ↓
AI Model
  ↓
Database

An industrial AIoT system can look considerably different:

Physical Environment
        ↓
Sensors / Devices
        ↓
Connectivity
        ↓
Edge Processing
        ↓
Data Pipeline
        ↓
AI / Analytics
        ↓
Application
        ↓
Operational Decision
        ↓
Physical Action

There are many more places where things can go wrong.

A temperature sensor might drift.

A tracking device might lose connectivity.

A machine may generate data at a much higher rate than the backend expects.

An AI model may receive incomplete information.

And even if the model produces a technically correct prediction, someone still has to decide what to do with it.

That last part is easy to overlook.

AI isn't the end of the system. It's one component inside the system.

Start with the physical problem

One of the easiest mistakes in AI projects is starting with the technology.

"We should use computer vision."

"Let's add an LLM."

"We need an edge model."

"Can we build a predictive maintenance system?"

Those are technology decisions.

The better first question is:

What is actually happening in the physical environment that we want to understand or improve?

Imagine a warehouse where equipment is frequently misplaced.

The interesting problem isn't necessarily "How can we use AI?"

The problem might be:

How can we know where important assets are, where they have been, and whether they are moving through the expected workflow?

That changes the architecture.

You might need location sensors, connectivity infrastructure, an asset database, event processing, anomaly detection and an interface for operations teams.

AI may be part of that system.

It doesn't necessarily need to be the entire system.

Data quality becomes a systems problem

In a normal software application, developers often have relatively clean inputs.

Physical systems aren't nearly as polite.

Consider a sensor measuring vibration from industrial equipment.

The data might contain:

Noise
Missing values
Outliers
Sensor drift
Different sampling rates
Temporary connectivity failures
Changes caused by normal operating conditions

If that data goes directly into an ML pipeline, the model isn't magically going to fix everything.

The pipeline has to understand the characteristics of the data first.

That means AIoT developers need to think about things like validation, timestamp synchronization, buffering, preprocessing, device identity and data lineage.

In other words, the data engineering layer becomes just as important as the model.

Edge vs. cloud isn't a simple choice

Another interesting architectural decision is deciding where intelligence should run.

Cloud processing has obvious advantages.

You can use more compute, centralize models, update systems more easily and aggregate information from many devices.

But sending everything to the cloud isn't always practical.

A system might need to respond quickly.

The network might be unreliable.

Bandwidth might be expensive.

Some information may be sensitive.

This is where edge processing becomes useful.

A simplified architecture might look like:

Sensor
  ↓
Edge Device
  ↓
Local Processing
  ↓
Important Events
  ↓
Cloud
  ↓
Central Analytics

The edge doesn't have to replace the cloud.

The two can complement each other.

For example, an edge device could filter or classify incoming data locally while the cloud handles longer-term analytics, fleet management and model updates.

The right architecture depends on the actual requirements of the system.

Reliability matters more than impressive demos

A prototype can work beautifully for ten minutes.

A production system has to work on a Monday morning when three sensors are offline, the network is unstable, and someone accidentally disconnects a gateway.

That's a completely different engineering standard.

Developers working on physical systems need to think about failure modes early.

What happens if a device stops reporting?

What happens if data arrives late?

What happens if two devices report conflicting information?

What happens if an AI prediction has low confidence

What Developers Should Know About Building Child Tracking Systems

Growth Muse — Fri, 18 Sep 2026 15:20:26 +0000

Child tracking sounds simple on the surface: attach a device to a child and show their location on a screen.

In practice, it is much more complicated.

A reliable child tracking system has to deal with location accuracy, connectivity, battery life, privacy, alerts, and what happens when something goes wrong. For developers building IoT or location-based applications, it is a good example of how hardware and software have to work together.

Location is only one part of the problem

GPS is probably the first technology that comes to mind. It can be useful outdoors, but large venues create different challenges. Signals can become unreliable around buildings, indoor spaces, and crowded environments.

That is why modern tracking systems can use different technologies depending on the environment. BLE, RFID, UWB, and GPS each have different strengths.

The interesting engineering challenge is deciding which technology—or combination of technologies—makes sense for a particular use case.

_ Alerts matter as much as location_

Knowing where a device is isn't necessarily enough.

A useful system needs to turn location data into something actionable. For example, a venue could establish predefined zones and generate an alert when a tracked device moves outside an expected area.

This is where concepts such as geofencing become important.

Instead of constantly asking someone to monitor a map, the software can identify unusual movement and notify the appropriate person automatically.

The backend needs to be reliable

There is also a less visible side to the system: infrastructure.

Tracking devices may continuously send location or status information to a backend service. That data then needs to be processed, stored, and displayed with as little delay as possible.

Developers may need to think about:

Device authentication
API reliability
Real-time data processing
Battery optimization
Offline connectivity
Alert delivery
Data retention
Access controls

A failure in any one of these areas can affect the entire experience.

Privacy cannot be an afterthought

Child tracking involves particularly sensitive location information. Developers should therefore think carefully about who can access the data, how long it is retained, and how information is protected.

Security and privacy should be considered during system design rather than added after the product is finished.

For developers interested in the broader architecture behind these systems, this overview of child tracking technology provides an example of how IoT, location technologies, and venue safety can be brought together.

The bigger lesson is that tracking isn't really about putting a dot on a map. It's about building a dependable system that connects devices, software, people, and real-world environments—and making sure it continues to work when it matters most.