Cloud-based manufacturing optimisation

Have you ever tried to create something while simultaneously learning how to use the tools? My team and I lived that during our final semester, building a manufacturing-optimisation solution on Azure services.

We survived, learned a ton, and built something pretty cool. A demo would be nice, but it belongs to the client. Strap in for the ride if you have time.

While the work was split equally, I took on the team-lead role — providing a broad overview of the project, designing the architecture, setting expectations, and orchestrating our efforts into a coherent product. In this case, a software module integrated into our client's existing system.

The challenge: making machines smarter

The picture. You have manufacturing machines generating tons of sensor data, but the data is just sitting there. We wanted to build something that didn't just monitor the machines, but actually made sense of the data and helped engineers optimise operations.

The core idea was a system that could:

• Monitor machines through sensor data.
• Store historical performance data.
• Use generative AI to query data, generate reports, recognise faults, and raise alerts.
• Visualise everything in a user-friendly format.

IoT data, anomaly detection, and an LLM

1. Data collection and ingestion

The system collected key parameters — temperature, speed, torque, positional data — from various sensors on the machines. Raspberry Pi devices acted as edge computing units, and we used the OPC UA protocol via PLCs (Programmable Logic Controllers) to translate machine signals into readable data.

The ingest pipeline:

Edge Device (Raspberry Pi) → Azure IoT Hub → Azure Event Hub → Azure Function Apps → Azure Cosmos DB

2. Storage and processing

Once collected, we used two datastores:

• Azure Cosmos DB — stores raw IoT messages.
• Azure Blob Storage — stores processed performance metrics (OEE, OT, OE) for the LLM to consume.

For processing, an Event Hub Trigger Azure Function (Python 3.11 runtime) would:

• Parse incoming IoT telemetry.
• Update Digital Twin properties.
• Calculate statistical metrics.
• Store processed data in Blob Storage.

3. Anomaly detection + LLM integration

For anomaly detection we used Azure Machine Learning to train a simple model that could predict machine failures from historical data. The model was deployed as a web service and wired into the Azure Function App so it could raise alerts when anomalies were detected.

The runtime workflow:

• The backend retrieves data from Cosmos DB.
• Data is scaled using a pre-trained scaler.
• The maintenance-alert model predicts and returns results to the frontend dashboard.

4. Digital Twin integration

Digital Twin setup

• Create Azure Digital Twin models for the manufacturing system (e.g., Gantry System).
• Define relationships between components:
  • Vacuum → Storage: have_access_to
  • ControlPad → Vacuum: controls
  • Conveyor → Sensors: linked_to

Real-time monitoring

• IoT data updates Digital Twin properties via the Function App.
• The Digital Twin model provides a virtual representation of the physical system.
• 3D visualisation (Azure Digital Twins 3D Scenes) and an in-house dashboard show machinery status in real time.

5. LLM integration for log processing and optimisation

Azure OpenAI services setup

• Deploy a GPT-4o model in Azure OpenAI Services.
• Set up text-embedding-ada-002 for vector search capabilities.
• Configure system message and parameters.

Integrating machine data with the LLM

• Process and store machine performance metrics in Azure Blob Storage.
• Set up Azure AI Search to index the data.
• Configure vector search for semantically relevant retrieval.
• Connect Azure OpenAI Service to that indexed data.

The optimisation suggestion workflow

• Users interact with the LLM via a chat interface.
• The LLM queries Azure AI Search for relevant machine data.
• The system combines its knowledge with real-time and historical data.
• It generates reports and optimisation suggestions from that integrated picture.

An example prompt looks like this:

"Analyse the raw data and statistics from the time period and generate a summary.
Your report should include the following sections:
  1. Executive Summary
  2. Variable Trends
  3. Anomalies Detected
  4. Potential Faults
  5. Optimization Strategies
For each section, provide concise, data-driven insights. Use specific
numbers and percentages where relevant."

Azure: a maze

Working with Azure was like exploring a city where every service is its own neighbourhood. Some neighbourhoods are friendly and work great together. Others… let's say they need better public transportation.

We used various Azure services for storing data, processing it, and running AI models. Here's where it got interesting — and by interesting I mean challenging.

Combining Azure services is a bit like following a recipe with missing instructions. Some of the fun challenges we faced:

1. Documentation. Sometimes Azure's docs felt like a treasure hunt. "Oh, you want these two services to work together? Here's a cryptic clue!" Exaggerated, but the point stands — when designing infrastructure for clients we couldn't say with confidence if things would work as intended. The amount of doc-diving needed to verify feature availability was too much for the proposal phase.
2. Integration. Getting different Azure services to talk to each other was way harder than it should be (thanks to my teammates for figuring this out). Often two Azure services you'd expect to integrate cleanly require some roundabout path, and sometimes that path isn't documented anywhere. This is less of a problem if you use the Azure-native version of a common tech (Azure SQL vs Postgres, Synapse vs Databricks, Cosmos vs other non-structured DBs) — but then point 1 hits you again. "Oh, that feature in open-source product A isn't in our version yet — it's on the road map / in preview."
3. "It's not you, it's me" moments. Azure services occasionally took their sweet time responding. Like waiting for a text reply that never comes.

Lessons learned

• Reading docs is an art. Beyond just reading, you need to read between the lines. Often what's missing is as important as what's included. The number of things poorly or ambiguously documented across multiple locations is too high. Maybe it's just me.
• Integration testing is your best friend. When working with multiple services, test their interactions early. Finding out two services don't play nicely after building half your solution is not fun.
• Keep it simple. Start with the basics and add complexity gradually — a good approach for any complex system.

Don't get me wrong — Azure has the most compelling storyline because it produces the top BI tool on the planet (PowerBI), the most common enterprise RDBMS (SqlServer), the most common business productivity suite (O365), and the most common authentication service (AAD). If I had to guess, MSFT just doesn't pay as much attention to the data-engineering or developer side of the business.

The silver linings

Despite the challenges, we built something genuinely useful:

• A real-time monitoring system.
• AI-powered insights for optimisation.
• Interactive 3D visualisations.
• A chat interface for querying system data.

And the best part — everything actually worked together.

Personal takeaways

Looking back, this project was more of a proof of concept — a prototype for our client rather than an actual staging product — like solving a puzzle where the pieces keep changing shape. Frustrating? Sometimes. Educational? Absolutely. It taught me that in the real world, technical skills are just part of the equation. Problem-solving, persistence, and being able to shrug it off are equally important.

Want to see how it all came together? Check out our project presentation video for a demo of the system in action.