Contents
An industrial data architecture should explain how information moves from its source to a useful application, what happens when a connection fails and who owns each boundary. Begin with the operational use and site constraints. Choose components only after the required behaviour and review responsibilities are clear.
Define the operational use and system boundary
Identify the equipment, signals and users involved in the first release. Describe whether the software supports observation, analysis or a proposed operational action. Keep any change to equipment control explicit and subject to the responsible site and engineering review.
Document the existing systems and approved interfaces with their owners. Record constraints on access, maintenance windows and data collection. A reference diagram is a starting point for discussion, not evidence that a particular connection is suitable for the site.
Give collection and application components clear roles
Specify what happens close to the data source and what happens in the receiving application. Identify where readings are timestamped, validated and transformed. Keep the reason for each transformation visible so the application team can understand the information it receives.
Compare possible deployment locations against connectivity, support and the actual processing need. Avoid choosing an edge or cloud arrangement solely from a general preference. Record the assumptions that determine the choice and the evidence required to confirm them.
Design for interrupted communication
Agree what should happen when a connection is delayed or unavailable. Specify whether data is buffered, how long it remains useful and how the application indicates a gap. Include the consequences of storage limits or a prolonged outage in the review.
Define how repeated and late records are recognised when communication returns. Test recovery with controlled inputs and reconcile the results at the destination. A restored connection does not by itself prove that the data history is complete or correctly ordered.
Keep the data contract understandable
Record identifiers, units, timestamp meaning and relevant operating context. Define the representation of missing or invalid measurements. Have the operational owner review representative examples so the interpretation remains connected to the equipment and process.
Version the contract when meaning or structure changes and agree how consumers adapt. Retain enough traceability to investigate a disputed result. Keep diagnostics proportionate and avoid collecting sensitive details that are unnecessary for the supported use.
Review access and maintenance responsibilities
Map which components communicate and which authorised people can configure or support them. Have the site's responsible security and engineering owners assess the proposed boundaries. Include remote support, credentials and dependency updates in that review.
Name who maintains each component and how a change is approved. Document how faults are diagnosed and escalated across site, software and supplier teams. Keep access and operating instructions usable by authorised replacements rather than depending on a single original implementer.
Verify a bounded deployment before expanding
Create an acceptance plan covering representative readings, missing data, outages and recovery. Distinguish simulated tests from checks against the approved site configuration. Agree the live verification boundary with the responsible owners before exercising the connection.
Review the result with the people who use and support it. Confirm that freshness, exceptions and limitations are visible and that the response process works. Expand the architecture only with evidence that the first deployment meets its defined purpose and has continuing ownership.
An edge-and-cloud comparison under interrupted connectivity
For a fictional observational pilot, assume a site permits a read-only equipment interface but its external connection may be unavailable for several hours. Option A streams readings directly to a cloud application. Option B uses an approved local collector with bounded buffering before onward delivery. Compare both against the same freshness need and site maintenance process; neither option changes machine control.
For the buffered option, define stable device identity, event time, sequence reference, units, maximum retained period and what happens when storage fills. During outage, the remote application shows unavailable or stale data. After reconnection, deduplicate and order historical readings without presenting delayed events as current. Reconcile a controlled sample and account for any gap rather than assuming restoration proves completeness.
The local collector adds patching, replacement and support responsibilities; the direct stream depends more immediately on external connectivity. Have site security and engineering owners approve interfaces, network boundaries and remote support. NIST’s OT guide identifies distinct reliability and safety considerations. Use its guidance to structure review, then test the actual site configuration and owners before making an architecture commitment.
NIST: Guide to Operational Technology Security, SP 800-82 Rev. 3
How this relates to Veda Software’s work
Powerleague illustrates separation of local users, central visibility and an operational handoff. That is adjacent responsibility evidence only, not an edge/cloud, IoT or industrial network implementation.