Discrete manufacturing
On a production line the decisive figure is how long the line stood still and why. Both facts arise in the automation system, but they disappear into an alarm list that is cleared at the change of shift. DataPortia™ stores alarms and events permanently and ranks them by total duration — which is what shows where the time actually goes.
Short answer
DataPortia collects the line's measurements and alarms from an OPC UA server, retains them for 24 months by default and produces availability and stoppage reports from them. Stoppage causes are ranked with Pareto, duration and severity analyses. Unit counts are derived with calculation points from the counters in the automation system.
What is typically reported from a production line?
Running time and downtime, the causes of stoppages and how often they recur, the number of units produced and the line's consumption in relation to output. All of these arise from signals the automation system already produces. The missing part is storage that is not cleared at the change of shift, and calculation that turns instantaneous values into figures for a period.
| What is reported | Where it comes from | The part of DataPortia |
|---|---|---|
| Running time and stoppages | The line's running states and alarms | Time series + alarm and event history |
| Distribution of stoppage causes | Alarm severity, area and duration | Pareto, duration and severity analyses |
| Unit counts | A counter signal from the automation system | A calculation point that adapts to the report's time range |
| Per-shift follow-up | The same measurements over the shift's time range | A scheduled report as PDF, CSV or Excel |
| The sequence of an interlock chain | Events with their original timestamps | Millisecond resolution, sequence-of-events (SOE) analysis |
A unit count requires that the automation system has a counter that is visible on the OPC UA server. DataPortia collects it like any other measurement point, but does not produce the counter itself. If there is no counter, it has to be added on the automation side first.
Why are stoppage causes worth ranking by duration?
Because the most frequently recurring alarm is not the same as the one that takes the most time. A short disturbance can appear a hundred times in a shift and still take less time than one long stoppage. Pareto, duration and severity analyses order the same alarm data in different ways, which shows both the frequency and the real effect on time.
In detail: what is read from the alarm data
Events are read from the OPC UA Alarms & Conditions subscription (Part 9). Severity, area and the original timestamp come with them, and the timestamp is not truncated — it is shown to the millisecond both on screen and in exports.
Filtering by severity, area and time narrows the view to one line or one shift. Details on the Alarms and events page.
How do I find out which interlock stopped the line first?
By looking at the events with their original timestamps. In an interlock chain dozens of events can fall within the same second, and a timestamp truncated to the second shows no order between them. DataPortia keeps the timestamp given by the automation system untruncated and shows it to the millisecond, so the first trigger stands out from the consequences.
The resolution is whatever the automation system provides. If the OPC UA server does not give millisecond resolution, it cannot be created afterwards — DataPortia preserves what it receives, it does not add resolution.
Can the figures be brought into an MES or ERP system?
They can. REST API v1 is read-only and authenticates with an API key, which is allowed 120 requests per minute. Measurement data, alarms and system status are read through it. Events can also be pushed the moment they occur, as an HMAC-signed webhook. Neither direction writes anything to the automation system.
In detail: keys, the rate limit and outages at the receiving end
Give each integration its own API key. The limit is counted per key, so the queries of an MES and of a reporting tool do not eat into each other's budget, and revoking one key leaves the others untouched.
Failed webhook deliveries are retried automatically, so a receiver that was down for a moment does not mean a lost event. Make the handling at the receiving end idempotent, because the same event can arrive twice. See REST API and webhooks.
Frequently asked questions
Below are the questions that come up most often in production line environments: changes to the automation system, per-shift reports, monitoring several lines and passing alarms on to maintenance. If your line has a particularity that is not covered here, tell me about it — I will assess the fit directly.
Does the automation system have to be modified?
No, provided the signals you need are already on the OPC UA server. DataPortia connects to the existing server as a client and reads from it; the PLC program is not touched. A change is needed only if some wanted signal — a unit counter, for example — is missing from the automation system altogether.
Can a report be run at the change of shift?
Reports are scheduled on a daily, weekly or monthly rhythm. A per-shift review is done by selecting the shift's time range, and the same report template works both for a report run by hand and for a scheduled one. Tell me your shift pattern and I will go through which schedule matches it most closely.
Can several lines be monitored in the same system?
Yes. DataPortia handles several parallel OPC UA connections, each with its own measurement points and settings. The number of connections determines the licence tier — there are seven tiers, from a single connection to unlimited. See Pricing and licensing.
Can alarms be passed on to maintenance by text message?
In development Text message alarms have not been tested in a production environment, and the feature is not available. At present alarms are passed outwards with an HMAC-signed webhook to the receiving system, which handles its own messaging.
How do I test this on my own line?
Install the trial version on your own server and connect it to the line's OPC UA server. The trial runs 30 days, with every feature except the HA add-on, and no commitment. Collect one week of alarm history and run a Pareto analysis on it — that tells you straight away whether the ranking matches the picture you already have of the line.