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. (We design and audit architectures like this regularly — see our LabVIEW consulting services for similar engagements.)
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. (This kind of multi-station integration is the bread and butter of our test automation services.)
Frequently Asked Questions
Common questions we get from engineering managers and IT teams evaluating an architecture like this.
What is Azure Hybrid Connection, and how is it different from a VPN?
Azure Hybrid Connection is a Microsoft-managed relay that lets an Azure-hosted application reach a resource inside your private network — without a VPN, without opening inbound firewall ports, and without exposing a public endpoint. A small Hybrid Connection Manager agent runs on-premises and initiates an outbound HTTPS (port 443) connection to an Azure Service Bus relay endpoint. When the cloud app needs to talk to your on-prem database, the request flows through that pre-established outbound channel. From the database's perspective, the query came from the local network. The connection is encrypted end-to-end, authenticated, and Microsoft-managed — your IT team doesn't run a VPN concentrator, manage certificates, or assign static IPs.
Does production data leave the plant in this architecture?
No. The on-premises SQL database holds the authoritative production data, lives on the plant network behind the customer's firewall, and is backed up under the customer's existing data-retention policies. The Blazor dashboard hosted in Azure issues queries through the Hybrid Connection, but the data itself is never copied or replicated to the cloud — it's read live from on-prem and rendered to the authenticated user. If the internet connection drops, the production line keeps running normally because the C# supervisor and SQL Server are both on-prem; only the dashboard becomes temporarily unreachable.
Why use Blazor instead of LabVIEW or a desktop app for a production dashboard?
LabVIEW is the right tool for the test station itself — DAQ, FPGA timing, instrument control, deterministic loops. It's the wrong tool for a multi-user, browser-accessible dashboard. Blazor (specifically Blazor Server) gives you a real C#/.NET stack with mature SQL access, Microsoft Entra ID single sign-on, SignalR-driven live updates, mobile-friendly responsive UI, and zero client install. Operators, supervisors, and engineering managers all hit the same URL from desktop or phone. LabVIEW dashboards built in the LabVIEW UI lock you to LabVIEW licensing on every viewing machine, don't render well on mobile, and require runtime install. Blazor wins on access, scale, and maintainability for the dashboard layer — while LabVIEW keeps owning the deterministic, hardware-facing test code below it.
What's the difference between server-side Blazor and Blazor WebAssembly?
Server-side Blazor (Blazor Server) runs the application on the server and uses SignalR to push UI updates to the browser over a persistent WebSocket connection. The browser becomes a thin renderer. Blazor WebAssembly downloads the .NET runtime and your assemblies into the browser and runs everything client-side. For a manufacturing dashboard backed by a database, Blazor Server is almost always the right choice — all queries already need to round-trip to the server, the initial page load is much faster, and SignalR makes live data updates trivial. Blazor WebAssembly makes more sense for offline-capable apps or when you specifically want code to run on the client.
Can I do this without exposing my SQL Server to the internet?
Yes — and you should. With Azure Hybrid Connection, your SQL Server never gets a public endpoint, never gets a static public IP, and your firewall does not need a single inbound rule changed. The only network change is allowing the Hybrid Connection Manager agent to establish outbound HTTPS to *.servicebus.windows.net. Your DBA team will already permit outbound 443 to Azure for other reasons. SQL Server stays on the plant network, behind the firewall, exactly where the data-governance and IT-security teams want it.
How fast can the dashboard refresh, and does it handle multiple users?
The C# supervisor polls EtherNet/IP every 1–5 seconds depending on how fast a given station produces parts. New rows hit the SQL database within that cycle. The Blazor dashboard subscribes to a SignalR group; when the supervisor writes a new record, a lightweight message fans out to every connected browser and the visible counts update without a page reload. Multiple users — floor monitor on a TV, supervisor on a phone, plant manager on a laptop — all see the same numbers update at the same time. There's no per-client polling and no manual refresh button.
What does it cost to run this in Azure?
For a single plant with one Blazor App Service, one Hybrid Connection, Microsoft Entra ID for authentication, and a small Service Bus relay, monthly Azure cost is typically in the low hundreds of dollars — comparable to or less than a traditional on-premises web server with backups, certificates, and IT support hours folded in. The bigger savings come from not building or maintaining a custom VPN, not standing up a public web server, and not paying per-seat licensing on a desktop dashboard. Korpra includes Azure infrastructure management as part of the engagement, so the customer's IT team isn't operating Azure day-to-day.
Will this work for plants outside Rochester, NY?
Yes — the architecture is location-independent. Korpra has built and deployed this stack for clients across Western New York, Central New York, New England, and Florida, and the Azure hosting layer puts the dashboard within reach of any browser with a sign-in. Local proximity matters for the on-site discovery, hardware integration, and commissioning phases — that's where Korpra's Victor, NY headquarters and East Coast travel footprint earn their keep. After deployment, ongoing infrastructure operations are remote.
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.
Ready to talk through a similar build?
Korpra has designed, deployed, and operated this exact stack for manufacturers across Western NY, Central NY, New England, and Florida. We handle architecture, hardware integration, software, Azure hosting, and ongoing support. Request a quote → · See our LabVIEW consulting services → · Browse other Rochester-area projects →
Interested in a similar system?
Let's talk about your requirements.