OT/IT integration: MES, ERP, historians and the unified namespace

The problem this solves

A plant typically has controllers that know precisely what each machine is doing, a SCADA system displaying it, possibly a historian recording it, an MES tracking orders and an ERP running the business. Each is competent. The difficulty is that they were bought at different times for different reasons, and the data in one is not available to another without somebody building a path.

The consequences are familiar. Production reports are assembled by hand from several sources. The figure in the morning meeting disagrees with the figure on the shop floor and nobody can say which is right. A question like “what did we actually make on line three last Tuesday, and why was it less than planned” takes a person half a day, and the answer arrives too late to act on.

None of that is a technology problem in the sense of missing capability. The data exists. What is missing is a path between systems, and an agreement about what the numbers mean once they arrive.

This article is about that work: getting data from the control layer into the systems that run the business, without compromising either. It assumes you can already read from your controllers; if you cannot, SCADA and PLC integration covers that, and retrofitting legacy machines covers equipment with no controller worth reading.

Why OT and IT pull in different directions

Most of the friction in these projects is not technical. It comes from two groups with genuinely incompatible priorities, both of which are correct within their own remit.

Where the two sides differ, and what it means for a project

Question	Operational technology	Information technology	Consequence
First priority	Availability. The line must run.	Confidentiality and integrity.	OT resists any change during production; IT resists any unpatched system.
Patching	Rarely, in planned shutdowns, after validation	Promptly, often automatically	The same server cannot satisfy both policies. Do not try.
Equipment life	10 to 25 years	3 to 5 years	Integrations outlive the IT systems they were built for. Design for replacement.
Acceptable downtime	Often none without notice	A maintenance window is normal	Anything touching the control network needs a shutdown slot, which constrains the schedule.
Change process	Formal, sometimes safety-assessed	Comparatively quick	An IT-paced project will stall at the first control-side change.
Who is blamed for a fault	Production stops; it is visible immediately	Usually recoverable	OT caution is rational. Treating it as obstruction is how projects lose the people they need.

The practical lesson is that “OT/IT convergence” is a poor description of what should happen. The two domains should not converge into one flat environment with one policy; they should be connected deliberately at a controlled point, keeping their separate policies. Convergence as a literal goal produces the worst of both: a control network patched on IT’s schedule, or a business network held back by OT’s.

The organisational part, which decides the outcome

One decision matters more than any architectural choice: who owns the definitions. If the plant and the business each compute availability their own way, the two figures will differ, somebody will notice, and the credibility of the whole system goes with it.

This has to be settled with the people who will use the numbers, before the integration is built, and it is not a technical conversation. Does a planned changeover count against availability? Is a machine running at reduced speed available? Does rework count as production? There are no universally right answers, only an answer your organisation agrees on and writes down.

We would push for this explicitly at the start of a project, because it is the part that cannot be retrofitted. Everything else can be rebuilt; a year of history computed against definitions nobody accepts is simply lost.

What each system holds, and what it wants

Before building anything, it is worth being precise about what already exists. In our experience a significant fraction of proposed integration work turns out to be duplicating something a historian has been recording for years.

The systems in a typical plant, what they have and what they need

System	Holds	Typically wants	Normal way in
PLC / controller	Live machine state, I/O, counters, alarms	Nothing. It should be left alone.	OPC UA, Modbus, vendor driver — read only
SCADA / HMI	Live plant view, operator actions, alarm history	Little; it is a display layer	OPC UA server, sometimes a database behind it
Historian	Long tag history, compressed, with timestamps	More tags, better naming	SQL, REST, OPC HDA, vendor SDK
MES	Orders, routings, batches, genealogy, labour	Counts, cycle times, downtime reasons, quality results	REST or SQL staging tables
ERP	Orders, stock, costs, planning, purchasing	Confirmed production, consumption, scrap, machine hours	Vendor API, middleware, flat-file interface
CMMS / maintenance	Work orders, asset register, findings history	Run hours, condition alerts, fault codes	REST; frequently overlooked and one of the most valuable links
Quality / LIMS	Test results, specifications, certificates	Batch and process context for each result	SQL or file exchange

Two observations from that table. First, the controller wants nothing: every useful flow is upward, which is convenient because it is also what security requires. Second, the maintenance system is usually the most neglected connection and frequently the highest value, because linking condition data to recorded findings is what makes predictive maintenance possible at all.

The historian question, asked properly

Before specifying new collection, three questions about the existing historian settle a surprising amount:

• Which tags are actually being recorded, and at what resolution? Many historians are configured once at commissioning and never revisited. It is common to find the interesting tags absent and hundreds of uninteresting ones archived faithfully.
• What compression is applied? Historians routinely store changes rather than samples, with a deadband. That is fine for trends and can destroy the short transients that condition monitoring depends on. A tag that looks recorded may not be recorded usefully.
• Can anything get data out in bulk? Some historians export readily. Others make it awkward enough that teams give up and collect in parallel, which is how a plant ends up with two disagreeing records of the same machine.

If the answers are good, extending the historian is almost always cheaper than building alongside it. If they are poor, that is a finding worth having before committing to anything else.

Point to point, and why it stops scaling

The natural way to connect two systems is directly. It is quick, it is obvious, and for two systems it is correct. The difficulty is what happens as the count grows.

Each interface is not merely a connection. It is a format, a schedule, an error-handling decision, a set of assumptions about what the other side means by a field, and a piece of knowledge held by whoever built it. Multiply that by ten and the maintenance burden is the project.

The failure mode is specific and worth recognising, because it arrives late. Everything works. Then ERP is upgraded, three interfaces break in different ways, and the person who built two of them has left. Nothing was badly engineered; there were simply too many independent couplings for the number of people available to maintain them.

The middle option, which is often right

Between direct connections and a full architecture there is an intermediate step that suits many plants: a single integration layer that reads from the control side once and serves everything above it, without adopting any particular product or pattern. One connection down, several up, one place where naming is decided.

This captures most of the benefit for a fraction of the commitment, and it is what we would suggest for a plant with three or four systems and no immediate plan for more. The formal patterns below become worthwhile when that layer starts to strain.

The unified namespace, without the enthusiasm

The idea is straightforward. Instead of systems asking each other for data, every system publishes what it knows to one place, structured by an agreed naming scheme, and anything that needs data subscribes to it. The central place always holds the current state of the plant.

In practice this is usually an MQTT broker with a hierarchical topic structure, frequently with Sparkplug B for a defined payload format and birth-and-death certificates so subscribers know when a publisher has gone. The protocol comparison covers the transport choices; what matters here is the pattern rather than the product.

What the pattern gives, and what it costs

Claim	What is true	What is usually left out
Adding a system is one connection	Genuinely true, and the main benefit	Only if the naming scheme already covers it. Retrofitting names is painful.
Systems become decoupled	True: publishers and subscribers need not know each other	They are now all coupled to the broker and to the naming scheme instead.
The current state is always available	True with retained messages	It is a current-state store, not a historian. You still need history somewhere.
It is vendor neutral	The pattern is; MQTT and Sparkplug are open	The tooling around it frequently is not. Check before committing.
You can start small	True, and you should	Starting small without agreeing the naming produces a mess faster.

Two costs deserve stating plainly. The broker becomes infrastructure you must keep running, monitor and make redundant, because everything now depends on it — a single point of failure introduced deliberately in exchange for removing many points of coupling. And the naming scheme becomes a governance problem: somebody must own it, and changing it later means touching every publisher and subscriber.

Our honest position is that the naming discipline delivers most of the value and can be adopted without any particular broker. A plant that agrees how assets and measurements are named, and applies it consistently, has done the hard part. A plant that installs a broker without that agreement has bought a faster route to inconsistency.

Naming, concretely

A workable scheme is hierarchical, describes location and asset rather than equipment model, and is stable against reorganisation:

• Site, area, line, cell, asset, measurement. For example plant2/assembly/line3/press1/motor_current. Predictable enough that a subscriber can construct a topic without asking.
• Name the role, not the part. press1 survives replacing the press; a name containing the manufacturer and model does not.
• Keep units and context alongside the value. A number without its unit, scale and timestamp becomes uninterpretable the moment the person who configured it leaves.
• Decide the boundary between structure and payload once. Encoding everything in the topic makes subscription rigid; encoding everything in the payload defeats the point of the hierarchy.
• Write it down and put it under change control. An undocumented scheme is a scheme that will diverge.

This is unglamorous, it takes a few meetings, and it is the difference between an architecture that absorbs the next ten years of additions and one that has to be redone.

From tags to something a business system can use

A controller exposes tags: a register holding a number. Nothing in the tag says what it measures, what unit it is in, which asset it belongs to or whether it can be compared with the tag next to it. A business system needs all of that, and supplying it is most of the work in an integration.

The gap is best seen in an example. A historian may record L3_M4_PV1 sampled every second for three years. That is data. To be useful it needs to be known as the spindle load of press 1 on line 3, in amps, full scale 60, valid when the machine is running, comparable with the same measurement on presses 2 and 3 but not with the one on line 4 because a different sensor is fitted. None of that is in the tag, and all of it is usually in somebody’s head.

What a raw tag lacks, and where the context has to come from

Missing	Why it matters	Usual source
Asset identity	Nothing can be aggregated or compared without it	An asset register, ideally the maintenance system’s
Unit and scale	A raw count is uninterpretable and silently wrong when scaling changes	Controller configuration, drawings, commissioning notes
Validity	A reading taken while the machine is stopped will distort every average	A state tag, or derived from another measurement
Comparability	Two tags with the same name may not measure the same thing	Only a survey establishes this
Meaning of a state code	Downtime reasons are worthless without the code list	PLC program, often undocumented
Expected range	Without it no threshold can be set and no outlier detected	Observation over time, not specification sheets

The practical approach is to build an asset model separate from the tags: a description of the plant as assets with properties, each property bound to a tag with its unit, scale and validity condition. Adding a machine then means adding an instance and binding its tags, rather than writing new logic. Some historians and platforms provide this directly; where they do not, it is worth maintaining as a configuration file under version control, and it should be part of what a supplier hands over.

This is also where the naming scheme pays for itself. Consistent naming plus an asset model means a subscriber can find what it needs without asking anyone, which is the difference between a system that absorbs additions and one that needs an engineer for each.

Deriving figures once

Measures like availability, OEE, energy per unit and mean time between failures are calculated from raw measurements, and the calculation must exist in exactly one place. Two systems computing OEE their own way will produce two answers, and the resulting argument tends to discredit both.

Our preference is to derive close to the source, publish the derived figure alongside the raw measurements, and have every consumer read the same one. It costs a little flexibility: a consumer wanting a different definition cannot have it without a change. That constraint is the point — it forces the definition to be agreed rather than quietly forked. The definitions themselves are covered in OEE and energy monitoring.

Timestamps, and why they cause so much trouble

Almost every integration eventually produces a problem that traces back to time, and it is worth getting right early because retrospective correction is rarely possible.

• Clocks drift. Devices without synchronisation drift by seconds a day, which is enough to reorder events and make a cause appear after its effect. Anything correlating measurements across machines needs a common time source.
• Whose timestamp is it? The moment of measurement, the moment a gateway read it and the moment a database stored it can differ by seconds or, after a network interruption, by hours. Record the measurement time at the source and treat arrival time as separate.
• Local time will bite you. Store in UTC and convert for display. A plant storing local time has one hour each year that occurs twice and one that never occurs, and shift reports across those boundaries are wrong in ways nobody notices for months.
• Order is not guaranteed. Buffered data arrives after live data. Anything assuming monotonic arrival will mis-sequence exactly when something interesting happened.
• Resolution is a decision. Second resolution is ample for production counting and useless for diagnosing an electrical transient. Choose per measurement rather than globally.

Practically: synchronise to one source, keep a source timestamp and an arrival timestamp on every record, store UTC, and make consumers tolerant of late and out-of-order arrival. None of this is difficult when designed in and all of it is expensive to add afterwards.

The connection will break

Any path crossing a boundary fails sometimes: a switch reboots, a certificate expires, a gateway is unplugged during maintenance, a firewall rule is tightened by someone doing their job. The question is not whether but what happens to the data meanwhile.

Behaviour during an interruption

Design	During the outage	Suits
No buffering	Data is lost, usually silently	Live display only, where history has no value
Memory buffer	Minutes to hours survive; a power cycle loses everything	Brief network interruptions
Local persistent store	Days survive, including power loss, and backfill on reconnection	Almost anything where history matters
Local store plus local decisions	Alerts continue working while disconnected	Anything an operator relies on

A local persistent buffer that backfills is not expensive and removes a whole class of problem, so it is worth specifying by default. It does require consumers to accept late data, which is the point above about ordering.

The subtler requirement is that failures must be visible. A path that stops delivering and reports nothing is worse than one that fails loudly, because the figures keep being produced from stale data and nobody knows. Every path should have a heartbeat and an alert on its absence, and somebody should receive that alert. Silent failure is the most common way a system that once worked stops being trustworthy without anyone noticing.

Idempotence, briefly

Once data can be resent after an interruption, the same record may arrive twice. If the receiving system counts production, a duplicate becomes a real error in stock or cost. Every record therefore needs a stable identity — asset, measurement, source timestamp — so a repeat can be recognised and discarded. This is a small design decision that prevents a genuinely awkward class of discrepancy, and it is easiest to get right before the first backfill rather than after.

Living alongside what already exists

Very few plants integrate from nothing. Usually there are existing paths: a spreadsheet an engineer maintains, a database somebody’s predecessor built, a vendor tool nobody fully understands. How these are handled determines whether a project is adopted or resented.

Switching everything at once is rarely wise. Running new and old in parallel for a period is what allows the reconciliation described above and gives people time to trust the new figures. The important discipline is that parallel running must end on a stated date, because two systems maintained indefinitely is the worst outcome: twice the effort, and an argument available whenever the answer is unwelcome.

The spreadsheets deserve particular care. They are frequently dismissed and they usually encode real knowledge — which machines are excluded, how a particular exception is handled, why one line is counted differently. Reading them before replacing them is how that knowledge survives, and the person who maintains one is normally glad to be asked rather than overruled.

What this costs

We cannot give figures without seeing a plant, but the shape of the cost is consistent and worth knowing, because it is not where people expect.

Where the effort goes on a typical integration

Item	Share of effort	Notes
Survey and discovery	10 to 15%	Consistently pays for itself by removing work later
Agreeing definitions and naming	10 to 20%	Mostly meetings. Compressed more often than any other stage.
Network and boundary work	10 to 20%	Higher where segmentation does not yet exist
Building the data paths	20 to 30%	What people assume is the whole project
Reconciliation and validation	15 to 25%	Where credibility is won or lost
Documentation and handover	5 to 10%	First thing cut, and what determines who can maintain it
Software licences	Varies widely	Per-tag or per-connection pricing scales unpleasantly. Check early.

Two points follow. Building the paths — the part that feels like the project — is under a third of the effort, and estimates based on it alone are short by a factor of three. And licence models matter more than they appear: per-tag pricing that is trivial for a pilot can dominate a site-wide rollout, so it is worth pricing the intended scale rather than the trial. The general question of where money goes is covered in product cost reduction.

The ongoing cost is small but not zero. Someone must hold the naming scheme, respond to alerts when a path fails, and adjust the mapping when a machine is replaced. An hour a month of deliberate ownership is usually enough; its absence is what separates systems still trusted after three years from those quietly worked around.

Getting data into MES and ERP

These are the connections with the most business visibility and the most ways to go wrong, because they cross from measurement into accounting.

What MES wants

An MES is generally trying to know what was made, when, on what, by whom, against which order. From the equipment it wants counts, cycle times, states with reasons, and quality results, each attributable to an order and a batch.

The recurring difficulty is attribution rather than measurement. A machine knows it produced 412 pieces; it frequently does not know which order they belong to, because the order exists only in the MES. Closing that gap means either the operator confirming the order at the machine, or the MES telling the machine what it is currently running. The second is better and requires a downward data path, which is where the security conversation becomes concrete.

What ERP wants, and why it is delicate

An ERP wants confirmed production, material consumption, scrap and machine hours, because those drive stock, cost and invoicing. That has an implication worth stating clearly: data flowing into ERP becomes financial data. A count that is 2% optimistic is a tolerable dashboard error and an unacceptable stock discrepancy.

This changes the engineering. Automated counts need a reconciliation path against physical checks, a defined handling of edge cases like rework, partial batches and rejects, and an audit trail showing where each figure came from. We would treat any direct machine-to-ERP posting without those as a liability rather than an achievement.

Integration approaches into business systems

Approach	Suits	Advantages	Against it
Vendor API	Modern systems with documented interfaces	Supported, validated, survives upgrades	Rate limits and rigid data models; may not expose what you need
Staging tables in a database	Established systems, batch flows	Simple, debuggable, easy to inspect	Couples you to a schema that may change without notice
Middleware or integration platform	Several systems, transformation needed	Mapping and monitoring in one place	Cost, plus a platform to operate and skills to retain
File exchange	Legacy systems, low frequency	Works with nearly anything	Fragile, hard to make reliable, no natural error path
Direct database writes	Almost nothing	Quick	Bypasses validation, voids support, breaks on upgrade. Avoid.

The reconciliation that always surfaces

The first time automated figures meet the existing production report, they will disagree. This is not a defect and it is worth warning stakeholders before it happens, because the credibility of the project depends on how it is handled.

The causes are mundane: shift boundaries defined differently, a counter that includes test pieces, a machine counting strokes where the report counts finished assemblies, downtime attributed to different reasons, or a manual report that was quietly rounded for years. Usually both numbers are defensible and they are measuring subtly different things.

The right response is to reconcile explicitly and document the difference, not to adjust one until it matches the other. A documented 3% difference with a known cause is trustworthy. A number tuned to agree is not, and the tuning will be forgotten long before the number is.

The security boundary

Connecting control systems to business networks is where the most consequential mistakes happen, and where we would decline to proceed without understanding the network first.

The principle is a single deliberate crossing point, with data flowing upward and no path allowing the business side to reach a controller. In practice that means:

• Segmentation with an enforced boundary between the control network and everything else — not a shared VLAN, not a flat network with a router.
• A broker or gateway in a demilitarised zone that the control side publishes to and the business side reads from, so neither reaches the other directly.
• Outbound-only connections from the control side where possible, so no inbound path needs opening.
• Read-only access to controllers unless a write path is genuinely required, and if it is, a specific, narrow, logged one rather than general write capability.
• No temporary exceptions. A rule opened for a commissioning week and left in place is the single most common finding in a plant that believes itself segmented.

Where a downward path is unavoidable — the MES telling a machine what order it is running — it should be a narrow, validated, logged interface that accepts specific values and rejects everything else, not a general-purpose write channel. The distinction is the difference between a controlled feature and an open door.

What we can do here is assess the network, design the boundary and document it. What we do not do is issue security certifications or claim a plant is compliant with any particular standard; that is for an accredited assessor. Device-level security is covered separately in device security and updates, and the regulatory side in security regulation for connected products.

Sequencing a project

Integration work fails more often from sequencing than from technical difficulty. The order below front-loads the findings that change the plan.

A workable sequence

Stage	Work	Typical duration	What it prevents
1. Survey	What systems exist, what each holds, what the network looks like	1 to 2 weeks	Building what a historian already records
2. Definitions	Agree terms, naming, ownership with the people who will use the figures	2 to 4 weeks, elapsed	Numbers nobody accepts; unusable history
3. Boundary	Design and agree the crossing point and segmentation	1 to 2 weeks	A connection that has to be undone
4. One path	One asset, one measurement, end to end into one business system	2 to 4 weeks	Discovering an obstacle after committing to scale
5. Reconcile	Compare with existing reports; document differences	2 to 4 weeks, elapsed	A credibility failure at the first management review
6. Extend	Add assets and measurements against the agreed scheme	Ongoing	Divergent naming; per-asset special cases

Stages 2 and 5 are elapsed time rather than effort, and they are the two most commonly compressed. Both involve waiting for people to agree, which cannot be accelerated by adding engineers.

What to hand over

Regardless of who builds it, a few things should end in your hands: the tag and topic mapping with what each measurement means, the naming scheme under change control, the definitions and how each derived figure is calculated, the network and boundary design, and the rationale for anything unusual. Those are what let a different supplier, or your own team, continue the work. A supplier comfortable providing them is worth working with.

Discrete, batch and continuous plants differ

Most writing on this subject assumes discrete manufacturing — countable units moving through stations. A good deal of it transfers poorly to a plant making liquids, powders or continuous product, and the differences change what the integration has to do.

What changes with the type of production

	Discrete	Batch	Continuous
The unit of production	A countable piece	A batch, with a recipe and a genealogy	A rate, integrated over time
What ERP needs confirmed	Counts, scrap	Batch yield, consumption against recipe	Quantity over a period, from flow and density
Traceability demand	Serial numbers where required	Usually strict: forward and backward genealogy	Time-based, with mixing to account for
Downtime	Mostly unambiguous: stopped or running	Includes changeover and cleaning as distinct states	Often reduced rate rather than stoppage, which is harder to define
The awkward part	Attributing output to an order	Batch boundaries, and equipment shared across batches	Deciding when the product became in-specification

Two consequences worth naming. In a continuous plant, availability and OEE as normally defined can be actively misleading, because the plant never stops and the loss is in rate and quality rather than downtime; energy or yield per unit of output is usually the more honest measure. And in a batch plant the genealogy requirement means the integration has to carry equipment and material context alongside every measurement, which is a materially larger data model than a discrete line needs. A supplier quoting a discrete-manufacturing approach for a batch plant has probably not understood the requirement.

Questions worth asking a supplier

Including us. The answers distinguish people who have done this from people who have read about it:

• What will you survey before proposing anything, and what would make you change the approach? An approach that cannot be changed by findings was not derived from them.
• Who owns the naming scheme, and what happens when it needs to change? If there is no answer, it will be discovered by accident later.
• What exactly is handed over, in what form? Mapping, definitions, network design and rationale, or a working system nobody else can modify.
• How will we know when a data path has failed? If the answer is that someone will notice the numbers look wrong, that is not monitoring.
• What happens to figures already collected if a definition changes? Recalculated, kept both ways, or quietly inconsistent.
• How does licensing scale to the whole site? Ask for the number at full scope, not the pilot.
• What will you not do? A supplier with no stated limits has not thought about them, and the limits will appear as surprises.

Our own answers are in this article, which is deliberate: a survey first, definitions agreed with the people who use them, everything documented and handed over, no security certification, and no fixed price before seeing the network.

What usually goes wrong

• Starting with the platform. A broker installed before the naming is agreed produces inconsistency faster than point-to-point would have.
• Treating it as an IT project. Anything touching the control network needs OT’s process and OT’s shutdown window. Scheduling around that is not optional.
• Connecting everything because it is possible. Each interface is a permanent maintenance obligation. Build the ones with a named consumer.
• Letting each department define its own terms. The disagreement will surface in a management meeting rather than a design review.
• Ignoring the historian. The commonest source of duplicated effort and of two disagreeing records.
• No owner. Integrations decay: systems are upgraded, tags are renamed, certificates expire. Without someone responsible, the first silent failure is found when a report is wrong.
• Assuming a successful pilot generalises. One line with a helpful controls engineer is not twelve lines with mixed vendors and no documentation.

How we help with this

We work on the path between the control layer and the systems that run the business: surveying what exists, designing the boundary, agreeing naming and definitions with the people who will use the figures, building and documenting the data path, and handing over the mapping and rationale.

We would start with a survey rather than a proposal, because the honest answer to scope and cost depends on what your systems already hold and how your network is arranged, and neither can be guessed from outside. We do not issue security or compliance certifications, and we would not promise a reporting improvement before seeing whether the underlying data supports it.

Related pages: industrial IoT integration, industrial IoT, and cloud backends and dashboards for what happens to the data once it crosses the boundary. If the measurement you need does not exist yet, sensor selection comes first. For the wider picture, what industrial IoT actually is.

Questions we are asked about this

Common questions

What clients ask before starting

What is the difference between OT and IT?

Operational technology runs the process: controllers, drives, instruments, SCADA. Information technology runs the business: servers, networks, ERP, email. They developed separately with genuinely different priorities — OT values availability and determinism above almost everything, IT values confidentiality and patching currency — and most integration friction comes from those priorities colliding rather than from any technical incompatibility.

Do we need a unified namespace?

Not for a first integration between two systems, where it is overhead without benefit. It earns its place when you have several systems that all need the same data, or when you expect to keep adding them, because it converts a problem that grows with the square of the system count into one that grows linearly. Adopting the naming discipline is worth more than adopting any particular broker.

Can we connect our PLCs straight to ERP?

Technically often yes, and it is usually a poor idea. The two have incompatible lifespans and change rates: a controller may be untouched for a decade while ERP is upgraded repeatedly, and a direct coupling means every ERP change becomes a controls project. An intermediate layer that both sides talk to instead is more work initially and far less afterwards.

Is it safe to connect control systems to the business network?

It can be, with a controlled boundary, one-directional data flow where possible, and no path that allows the business network to reach a controller. What is not safe is a flat network, or a convenience route opened for a project and never closed. We would not advise connecting anything until the segmentation is understood, and an assessment of that is part of the work rather than an add-on.

We already have a historian. Is that not enough?

It is often most of what you need and is routinely overlooked in favour of something new. A historian already holds tags, history and compression, and the real question is whether it holds the right tags at a useful resolution and whether anything can get data out of it. Extending what exists is usually cheaper and less disruptive than replacing it.

Who should own the integration?

Somebody with authority over both sides, or two people who are explicitly required to agree. Integrations owned only by IT tend to break production; those owned only by OT tend to produce data the business cannot use. The naming and definition decisions in particular need a single owner, because they are the part that cannot be fixed later without redoing the work.

How long does this take?

A first useful data path from controllers to a business system is typically weeks rather than months, if the network is understood and the tags exist. What takes longer is agreeing what the numbers mean across departments, which is organisational rather than technical and is consistently underestimated.

What do you actually do on a project like this?

Survey what systems exist and what each already holds, establish where the boundary should sit, agree the naming and definitions with the people who will use the figures, build and document the data path, and hand over the mapping and rationale. We do not issue security certifications, and we would not quote a fixed price before seeing the network and the existing systems.

Start a conversation

What are you assembling by hand that a system should be producing?

Tell us which systems you run, what the current reporting process looks like and where the figures disagree. That is usually enough to say where the useful integration is.

Leave empty

Your name *

Email address *

Company

Country *

What are you working on? * I agree that iTechGeeks may use these details to respond to my enquiry. Privacy policy. Send enquiry ↗

Prefer email? Write to info@itechgeeks.in