A business-side bridge that converted machine state, operator context and confirmation logic into traceable SQL stoppage records without taking control away from the PLC/SCADA layer.
The client and plant are not identified. The workflow, architecture and engineering decisions described here reflect delivered work, while commercially sensitive implementation details remain omitted. Safety-critical PLC and SCADA ownership remained with the responsible automation team.
The operational problem was not simply that machine data was unavailable. Machine state existed in the control environment, operator knowledge existed on the shopfloor and management reporting existed elsewhere, but these sources did not form one defensible history. The solution introduced a .NET bridge and operator workflow that treated machine evidence, human explanation and business-side status as separate but connected facts.
The manufacturing environment already had production equipment, PLC/SCADA state and operational reporting expectations. What was missing was a reliable business-side lifecycle for a stoppage: when the stop began, which machine state was observed, what reason the operator supplied, what action was requested, whether the control system confirmed the requested state and how failures were recorded for later support.
Manual stoppage sheets and loosely connected screens could not reliably reconstruct events after the fact. Operators needed a practical way to supply context, managers needed searchable SQL history and the integration had to respect the boundary between business software and the control system.
The difficult part was state ownership. A stopped machine, an operator-selected reason, a requested restart and the PLC's actual state are not the same thing. Treating them as one value creates race conditions, false closure and unsafe assumptions. Communication loss, delayed confirmation, repeated signals and screen refreshes also had to be handled without corrupting the event history.
The system separated actual machine state from wanted business state. A background bridge monitored the agreed tags, normalised transitions, created or updated stoppage episodes in SQL and exposed unresolved events to the operator portal. The operator recorded a reason and requested the next state, while the bridge continued writing or checking until the PLC/SCADA layer confirmed the actual state. Every important transition and communication failure remained visible.
The resulting system created a traceable stoppage lifecycle instead of a collection of disconnected values. Production and engineering could review the same event history, operator explanations remained linked to the machine evidence and integration failures were diagnosable rather than silently absorbed.
This is a content-based reconstruction, not a client screenshot. It shows the kinds of live inputs, controlled states, modules and evidence the delivered system had to bring together.
The PLC or SCADA layer exposes the agreed machine-running state.
The bridge detects a valid transition and records the source timestamp and asset context.
When a stop begins, the system opens a stoppage episode instead of merely flipping a boolean.
The operator interface shows the unresolved event and requests the required reason or action.
Exact client throughput, time-saving and financial figures are not published for this system. The case study therefore limits itself to implemented controls, workflow changes and verifiable system capabilities rather than manufacturing a percentage improvement for marketing purposes.
Each layer had a specific operational responsibility. This made failures easier to diagnose and prevented one screen, service or database field from becoming the accidental owner of the entire process.
The PLC and SCADA environment remained authoritative for actual machine state. The business application consumed agreed signals and, where explicitly permitted, issued a request through a defined interface rather than embedding control logic in the portal.
A background worker subscribed to or polled the relevant values, normalised transitions, applied debouncing and kept the SQL event model in sync with the observed state.
Stoppage episodes, timestamps, machine identity, operator reason, requested state, actual confirmation and diagnostic information were stored as related records rather than flattened into one status field.
A browser-based screen surfaced the current unresolved event, captured the operator's reason and preserved ownership of the next action.
Dashboards and reports used the governed event history, allowing production and engineering to investigate losses without rebuilding the story from paper or memory.
A case study is useful only when the flow can be understood. The sequence below shows where users, devices, databases or external systems entered the process and how responsibility moved.
The PLC or SCADA layer exposes the agreed machine-running state.
The bridge detects a valid transition and records the source timestamp and asset context.
When a stop begins, the system opens a stoppage episode instead of merely flipping a boolean.
The operator interface shows the unresolved event and requests the required reason or action.
The operator submits context and, where permitted, requests the next business state.
The bridge stores the wanted state and communicates through the defined control-system boundary.
The PLC/SCADA layer confirms the actual state independently.
The stoppage closes only when the agreed confirmation rule is satisfied; failures remain visible for support and reporting.
These were not isolated feature requests. Each module supported a specific part of the operational lifecycle and shared the same data, state and accountability model.
Translated raw tags into explicit business events with timestamps, asset context and source quality.
Opened, updated and closed a stoppage episode according to observed transitions and agreed business rules.
Allowed the operator to select or enter context while protecting the original machine evidence.
Tracked the requested next state separately from the PLC/SCADA confirmation.
Recorded communication failures, stale values, retry attempts and unresolved confirmations.
Exposed stoppage duration, reasons, exceptions and history through SQL-backed views.
The important work was often deciding what not to combine, automate or assume. These decisions made the resulting system easier to support and more honest about its boundaries.
The application was intentionally not allowed to become an informal PLC. The automation layer retained responsibility for machine control and safety behaviour.
A timestamped stoppage episode is more useful than repeatedly overwriting a current-state field because it preserves duration, sequence and causality.
Operator reasons explain the event; they do not replace the raw machine state. Both remain available for later review.
Repeated reads or retries must not create duplicate stoppages or close the wrong event.
A green dashboard based on an old value is worse than an explicit communication warning. Data freshness became part of the model.
The project was broken into phases that reduced the highest-risk uncertainty first. This prevented a broad implementation from hiding an unproven data or workflow assumption.
Document the current signals, PLC/SCADA ownership, existing stoppage process, reason codes, reports and write-back restrictions.
Prove transition handling, SQL persistence, operator capture and failure logging on a bounded machine or line.
Run through real stops, delayed confirmations, repeated signals, abandoned screens and network interruption.
Only after the event model is trusted, add broader dashboards, OEE measures or additional assets.
The controls below reflect the kinds of failure that could produce wrong records, unsafe assumptions, hidden exceptions or a system users would bypass.
Kept safety and machine-control logic outside the business application and required explicit automation ownership.
Separated wanted and actual states so a user action could not be mistaken for physical confirmation.
Used explicit event identity, transition rules and idempotent persistence.
Stored diagnostic state and exposed stale or unresolved conditions.
Designed reason capture around the real shopfloor moment rather than adding a later administrative burden.
Built reports on the governed event history rather than raw tags with unverified meaning.
The exact sector or technology may differ. The closer match is usually the workflow shape, source data, failure modes and operational responsibility.
Factories with manual stoppage sheets or untrusted downtime reports.
Plants where PLC/SCADA state must reach SQL and management systems.
Production teams that need operator reasons tied to real machine events.
Operations with recurring disagreement between engineering, operator and management data.
Industrial sites that need a support layer without replacing the existing control system.
The case study provides evidence. The service pages define the current delivery boundary, first-step artefacts, exclusions and technical scope for a new engagement.
Create a trustworthy event history from machine states, counters and operator context before building higher-level analytics.
Turn machine history and operator reasons into usable downtime, production and OEE improvement information.
Build a safe, supportable bridge between existing control-system data and business-side SQL applications.
Simple, robust screens for operators to capture the right data at the right point in the process.
Technology is listed for precision, but the system boundary and operating process determined the architecture.
No. The integration respected the existing automation boundary. The business application recorded evidence, collected operator context and communicated through explicitly agreed interfaces; it did not absorb safety-critical PLC logic.
Raw tags are not automatically business events. A useful history needs state interpretation, asset context, timestamps, duplicate handling, communication quality and rules for when one operational episode begins or ends.
Yes, once the running, stopped, planned and unplanned event model is trusted. OEE calculations should be built on governed production events rather than used to hide uncertain source data.
One machine or line, the relevant tag list, current reason codes, a sample stoppage report, the automation owner and agreement on read/write responsibility.
A preflight and conversion-planning tool that checked complex design files against ERP and manufacturing data before any production handoff occurred.
A SQL-backed quality workflow that replaced repeated copy-and-paste with controlled test records, validation and generated technical certificates.
A scan-driven system that gave each physical item a durable digital identity and recorded its movement, status, evidence and ownership over time.
Bring one real artefact: a report, spreadsheet, machine signal, job record, certificate, import file, device or system error. INESSOFT can map the current process and define a credible first phase.
