The automotive parts assembly floor below is a good picture of the challenge: activity at every station, components moving through assembly steps — and zero visibility into exactly how many parts have been built, by station, by shift, in real time.
1–5s
EtherNet/IP poll cycle
3
Network layers crossed
443
Only port required outbound
0
Inbound firewall rules changed
The Challenge: Production Was Running — Visibility Wasn't
A Rochester-area automotive parts assembly company operates a production floor with multiple assembly stations. Each station is controlled by a PLC that manages local safety interlocks, machine sequencing, and operator HMI instructions — exactly what it should do. The operators knew what was happening at their station. The problem was that nobody else did.
Supervisors walking the floor had to physically check each station to understand production status. The office had no live view of part counts, shift totals, or which stations were running behind. When a customer called asking about order progress, the answer required someone to physically go check. For a company shipping thousands of parts per shift across multiple product lines, that information gap isn't just inconvenient — it slows decisions, delays problem response, and makes production management reactive instead of proactive.
The Core Requirement
Give plant floor supervisors and office staff a live dashboard showing current part quantities and production totals for each station and each part number — with the ability to pull historical data for deeper analysis. The harder constraint: production data stays on-premises.
The Data Sovereignty Concern: Keep Production Data On-Premises
The customer's initial reaction to cloud hosting was skepticism. Their manufacturing data — part counts, assembly results, test outcomes — is business-critical. If the internet went down, would the production line stop? Could operators still log parts? With a pure cloud database architecture, the answer would be no — and that was unacceptable.
Data Governance Requirement
Production line data belongs on the production network, behind the company's own firewall, under their own backup and retention policies. For a manufacturer with automotive customers that have supply chain auditing requirements, keeping that data on-premises wasn't a preference — it was the right call.
System Architecture: Four Layers Working Together
The solution Korpra designed has four distinct layers, each with a clear responsibility — from PLC to browser, without any production data leaving the facility.
PLCs at Each Assembly Station
EtherNet/IP • Safety interlocks • Operator HMI
C# Supervisor Application
Windows Service • Polls every 1–5s • Writes to SQL
On-Premises SQL Database
Plant network • No internet dependency • Full data control
Azure Hybrid Connection Relay
Outbound port 443 • Service Bus • No VPN needed
Blazor Dashboard (Azure App Service)
Server-side • SignalR live updates • Entra ID login
The C# Supervisor Application: EtherNet/IP to Database
The supervisor application is the data engine of the system. Running continuously as a Windows service, it maintains persistent EtherNet/IP connections to each assembly station and polls defined tags on a configurable cycle — typically every 1–5 seconds depending on station output rate. Tags polled include part count registers, station status bits, cycle complete pulses, and test result values where the station performs a functional check on the assembled part.
- 1
Detect a new part count — rising edge on count register or delta since last poll
- 2
Validate the part number is in the expected list; flag anomalous counts
- 3
Write a record: part number, station ID, operator shift, timestamp, quantity increment, test result
- 4
Handle errors gracefully — if a station goes offline, log the gap and resume on reconnect
- 5
Apply shift boundaries automatically — shift totals are categorized at write time, no extra query logic needed
Azure Hybrid Connection: The Bridge That Changed the Architecture
Azure Hybrid Connection is not a VPN and it's not a peering arrangement. A small Hybrid Connection Manager agent is installed on the on-premises server. This agent initiates an outbound connection over port 443 (standard HTTPS) to an Azure Service Bus relay endpoint. Because it's outbound, no changes to the customer's inbound firewall rules are needed.
How the Relay Works
When the Blazor app needs to query the database, the request flows through the Service Bus relay to the on-premises agent, which forwards it to the local SQL Server. From SQL Server's perspective, it received a query from the local network. The connection is encrypted end-to-end, authenticated, and fully managed by Azure — no custom VPN, no static IP requirement, no certificate management by the customer's IT team.
The practical result: the customer's IT team ran one installer on the database server and approved one outbound HTTPS connection in their firewall. That was the entire network change required to give the Azure-hosted Blazor application access to the on-premises database. The production line data never leaves the building. The dashboard can reach it from anywhere.
The Blazor Dashboard: Live Counts, Shift Totals, and Data Export
The Blazor application is a server-side Blazor app hosted in Azure App Service. Server-side rendering was the right choice here because all data comes from database queries — there's no reason to push that logic to the browser. The server maintains connection state, executes queries, and pushes updates to connected clients via SignalR.
What the Dashboard Shows
Live production summary: part counts by station, current shift totals by part number, and a station status indicator (producing / idle / offline). The page refreshes automatically via SignalR — supervisors can leave it on a floor monitor all day. Numbers update the moment the C# supervisor writes a new record. CSV export is available filtered by date range, shift, station, or part number — streamed directly to the browser, no intermediate storage.
User Access: Microsoft Entra ID and Controlled Internal Access
The dashboard is not public. Access is limited to a defined list of internal users — floor supervisors, production managers, and engineering staff. Authentication is handled through Microsoft Entra ID (formerly Azure Active Directory), which the customer was already using for Microsoft 365. Users sign in with their existing company credentials — no new passwords, no separate account management.
Korpra Manages Azure
Application updates deploy through a CI/CD pipeline — a code change triggers a build, runs validation, and deploys to Azure App Service automatically. The customer doesn't interact with Azure directly for routine operations. Korpra monitors App Service health metrics, manages the Hybrid Connection configuration, and handles infrastructure changes. The customer's team focuses on using the dashboard, not maintaining it.
What the Customer Got
From the production floor perspective, nothing changed at the station level — the PLCs, HMIs, and operator workflows are identical to before. Every part counted at every station now flows to a queryable database within seconds of being produced, and that data is visible to everyone who needs it — live, from anywhere in the facility.
Supervisors check current shift progress from their phones without leaving their office. Engineering pulls six months of production data for a yield analysis in under a minute. When a station goes down, it's visible on the dashboard immediately — response time improves because the problem is visible the moment it happens rather than when the next manual walkthrough occurs.
The Bottom Line
A Blazor dashboard backed by Azure Hybrid Connection is the right architecture when you have on-premises data that can't move to the cloud but users who need access from anywhere. The EtherNet/IP → C# supervisor → on-prem database pipeline is proven, reliable, and keeps your production independence intact. The Azure layer adds hosting, authentication, and accessibility without changing anything about how your production floor operates.
If your production floor generates data that currently goes nowhere useful — PLCs logging to internal registers that nobody reads, shift counts transcribed to a whiteboard, test results that exist only in a local file nobody can find — this architecture is a direct path from that state to real-time visibility. Korpra has designed and deployed this stack and manages the ongoing Azure infrastructure. If you're evaluating a similar project, reach out.
Interested in a similar system?
Let's talk about your requirements.