Does connecting to a DCS void the OEM warranty?

Search this and you get forum threads, a vendor help file and a lot of hedging. The reason is that a definitive answer would be wrong: warranty scope is set by an executed supply contract, and contracts differ. Nobody wants to publish a statement a plant might rely on and then discover their own agreement says something else.

That is a fair concern and it has produced an unhelpful outcome, which is that a question every prospect must resolve before signing has no useful public treatment at all. The answerable version is narrower: what these exclusions usually say, which connection paths typically sit inside them, and how to convert the uncertainty into a written position before it costs anything.

None of this is legal advice, and the executed contract governs in every case.

The clause that matters is normally an exclusion rather than a prohibition. It says the supplier is not liable for faults arising from unauthorised modification of the equipment or its configuration, sometimes extended to unapproved additions to the system.

Two words in that do the work. Modification, which is about changing what the equipment does. And unauthorised, which is about whether the supplier agreed. A change the supplier approved in writing is not unauthorised, whatever else it is, which is why the written confirmation below matters more than the technical argument.

Note also what the exclusion does not usually say. It rarely prohibits reading. It rarely mentions network connections at all, because most of these contract templates predate the question. The absence of a clause about your specific case is a large part of why the answer feels uncertain, and it usually works in the plant's favour rather than against it.

Reading from a plant historian. The historian is downstream of control, already collecting, and reading it usually adds no load to the process network. It is the lowest-risk path in every sense and the one to propose first.

Reading through an OPC server the supplier provided and supports. Using a supplied interface for its intended purpose is difficult to characterise as modification, particularly where the supplier sold it as an option and documented it.

Placing acquisition hardware on a network segment the plant controls, separated from the control network by a firewall the plant owns. The equipment is untouched and the boundary is the plant's, not the supplier's.

Each of those describes a data path rather than a change to equipment, and that framing is the one to use when putting the question.

Modifying the controller programme. This includes adding logic purely to expose tags, which people underestimate because it feels harmless. It is a change to the programme the supplier warranted.

Changing scan time or controller loading in a way that affects deterministic behaviour. A controller that now completes its cycle differently is behaving differently, and where timing matters this is squarely inside the exclusion.

Placing an unapproved device directly on the control network. This is usually the cyber objection and the warranty objection at the same time, and it is the one most likely to be refused.

Changing configuration inside the supplier's scope of supply, including adding an interface that does not already exist. Adding an OPC server where there was none is a change to the control system and needs the same approval as any other, even though the end state looks like the low-risk path.

Clearing the warranty question does not clear the site's own procedure. Most operating plants have a management-of-change process that covers modifications to control and safety systems, and it exists to protect the safety case rather than the commercial position.

The two gates ask different questions. The supplier asks whether their equipment was altered. The site asks whether the documented basis of safe operation still holds. A path can pass the first and fail the second, particularly where the safety case was assessed against a specific configuration.

Where a safety instrumented system is anywhere near the proposal, the answer narrows further. IEC 61511 requires the safety instrumented system to be independent of the basic process control system to the extent that its integrity is not compromised, and no analytics function should sit where a safety function would come to depend on it. That boundary takes precedence over any technical convenience, and the detail is in reading plant data without modifying the control system.

The uncertainty is cheap to resolve and expensive to leave. Write to the supplier describing the exact path, the direction of data flow and what enforces the direction, and ask them to confirm in writing that it falls outside the warranty exclusions.

A usable version reads roughly: we intend to read the following tags from the existing historian, over a one-way path, with no connection to the control network and no change to controller programme, scan time or configuration. Please confirm this does not fall within the exclusions in clause X.

Specificity is what gets it answered. A general enquiry about connecting analytics invites a general refusal. A named path with a named enforcement mechanism invites an engineer to check it against the contract and say yes.

Doing this before a pilot costs an email. Doing it after a fault, when the supplier is looking for reasons the exclusion applies, costs considerably more. It is also the single most effective way to remove the objection permanently, because the answer is reusable across every later phase of the project.