/ THE SHORT ANSWER
- 01Describe the operational question before connecting systems.
- 02Limit analytical access to the data needed for that question.
- 03Treat stale data and failed connections as visible states.
- 04Practise isolation with controls engineers and operations.
/ dotSuper point of view
A useful factory analytics connection must remain understandable, monitorable and safely removable when the analytical service fails.
Define the question before offering network access
A question such as which stoppages account for the most lost production time gives engineers something narrower to evaluate.
List the relevant machine states, timestamps and contextual records.
Ask how fresh the answer needs to be.
An end-of-shift analysis may not need a continuous connection to equipment that controls production.
NCSC's OT introduction notes the risks created by legacy technology, external access and supply-chain connections.[
1] Use that context to involve controls engineers before an analytics supplier decides how to collect data.
Distinguish observing a process from controlling it.
A dashboard explaining yesterday's downtime does not need permission to change machine settings.
Keeping those capabilities separate can substantially simplify the initial design discussion.
Build an analytical copy with an explicit boundary
2] The practical lesson is to examine trust relationships, rather than assume that copying data automatically creates separation.
Ask who initiates each connection, which credentials it uses and what happens if the receiving service fails.
Draw the return path as carefully as the outward path.
Hidden administration channels can undermine the apparent boundary.
A read-only account restricts some actions, but it does not answer every availability or network risk.
A poorly designed query can still create load, and a compromised integration host can expose other connections.
Choose the architecture with the site's specialists.
The right answer may involve existing historians, gateways or offline exports.
This article does not prescribe a particular device or assume that every machine can support the same approach.
Make time, units and missing data visible
Include the source timestamp, latest successful transfer and expected update interval in the analytical record.
Standardise units and state definitions before asking the model to compare machines.
A stopped state may include planned changeover on one line and only faults on another.
Combining them without explanation produces misleading rankings.
Keep unknown distinct from zero.
A missing production count should not appear as zero output, and a failed sensor should not imply that no fault occurred.
The display needs an explicit unavailable state.
Allow operators to annotate operational context through an approved route.
A maintenance shutdown or trial product run can explain an apparent anomaly.
Those notes should supplement the data without silently altering the original machine record.
Review the connection as an operating service
A gateway with nobody responsible for access, updates and fault response is an ongoing dependency, not a completed project.
Agree which events trigger investigation.
Examples include unexpected connection attempts, a sustained loss of data or an unapproved configuration change.
Route alerts to someone who can act during the relevant operating hours.
Document how the analytical service can be isolated while production continues in its approved state.
NCSC includes an isolation plan among its connectivity principles.[
1] Turn that idea into a site-specific procedure and practise it.
The tradeoff is operational effort.
A modest reporting connection still needs support and change control.
Include those costs when deciding whether the business question justifies a permanent integration.
| Question | Evidence | Owner |
|---|---|---|
| What decision improves? | Specific operational use case | Operations |
| Which data is essential? | Tags, units and update needs | Process engineer |
| What can cross the boundary? | Approved connection design | Controls and security |
| How is failure detected? | Monitoring and stale-data state | Service owner |
| How is it isolated? | Practised disconnection procedure | Site operations |
| Who supports it later? | Named maintainers and access rules | IT and supplier |
Calculate a hypothetical downtime example
It exports approved event data to a separate analytical environment and keeps the AI service outside production control.
One machine records 90 minutes of downtime during a 450-minute scheduled production window.
Ninety divided by 450 is 20%.
The calculation depends on how the plant defines scheduled time and downtime.
A second machine has a missing final hour of events.
The report marks its result incomplete rather than comparing a partial record with the first machine's full shift.
The operations team finds that part of the first machine's downtime was a planned tooling change.
It updates the analysis classification through a reviewed process.
The AI suggests investigation questions but does not rewrite controller records or adjust machine parameters.
Prove the boundary before expanding the dataset
The important evidence includes the factory's response, not just whether the dashboard eventually recovers.
Keep a rollback path for configuration changes.
If a new data collection method affects performance, site staff should know how to return to the approved arrangement and who must be informed.
Expand only when a new question needs additional data and the boundary can support it.
More tags can increase maintenance work without producing a better decision.
The first deliverable is a data-path drawing with named owners, failure states and a practised isolation procedure.
That creates a concrete basis for useful factory AI while preserving the operational discipline that production equipment requires.
What this page cannot conclude
- 01An OT architecture needs assessment by competent controls and security specialists for the actual installation.
- 02Read-only access alone does not eliminate networking, availability or confidentiality risks.
- 03No guidance example should be copied into production without site-specific design and testing.
- 04This article was researched and drafted with AI assistance. Sources and limitations are provided for scrutiny; it is not an independent professional review or a compliance certification.
Sources
- 01Secure connectivity principles for operational technology: introductionNational Cyber Security Centre · accessed Sep 15, 2026
- 02Secure connectivity: operational OT data export exampleNational Cyber Security Centre · accessed Sep 15, 2026
This article was researched and drafted with AI assistance. Sources and limitations are provided for scrutiny; it is not an independent professional review or a compliance certification.
Our editorial standard · Found an error? Send a correction with its source.
/ CITE OR SHARE THIS GUIDE
Make the evidence easy to verify.
When you reference this guide, link to its canonical URL. That gives readers one stable place for the evidence, limitations and future updates.
dotSuper Research Desk. (September 15, 2026). Connect Factory AI Through a Deliberate Data Boundary. dotSuper. https://dotsuper.net/feeds/applied-systems/uk-factory-ai-ot-data-export-boundary