Resources · Framework
Integration Specification Template
This template has eight sections. When you complete them properly, vendors' quotes become comparable. Vendors then have no reason to add contingency for information the brief left out. You are free to copy and print the template, and to use it with any vendor, including us.
Before you start
UNIT 01Most integration briefs describe a solution, and that makes them expensive. A brief that starts with a technology gets quotes for that technology. It rules out cheaper options that no vendor was asked to consider. It also makes the quotes hard to compare, because each vendor fills the gaps differently and prices its own assumptions.
The sections follow the order in which an experienced integrator reads a brief. Sections 02 and 03, the asset list and the tag list, matter more than the other six combined. If you complete those two properly, you will get a firm price. Without them, you will get a wide price range, set high to protect the vendor.
You will not have every answer. Write “not known” where that is true. A vendor can quote a survey to resolve a stated unknown. For a blank, the vendor will add contingency instead.
The outcome, in one paragraph
01Vendors solve the problem you give them. If your brief opens with a technology, you will receive quotes for that technology. You may then miss a cheaper solution that no vendor was asked to consider.
What to write
- What can you not do today that you need to do?
- Who is affected, and what changes for them once the system works?
- What would you measure after six months to confirm that it worked?
- What does it cost you to continue exactly as you are?
Common mistake
Naming a solution in the first line. "We need a dashboard" describes a solution. "We cannot tell which line lost the hour" describes the problem, and the best answer to it may not be a dashboard.
Assets in scope
02This section causes more price variation than any other. If you describe scope as a category ("the pumps"), vendors price it as an average. The real details then emerge during delivery, at extra cost.
What to write
- List every asset by make, model and year, rather than by category.
- For each asset, what interface does it have, and who holds the credentials?
- Which asset is the hardest to access? That asset will set the pace of the project.
- Which assets are out of scope for now, but might be added later?
Common mistake
Leaving out the one machine that everyone knows is a problem, on the basis that it can be dealt with later. The vendor will then quote for it later, at a higher price, when you have less bargaining power.
The tag list
03The tag list is the most useful document you can prepare before you approach vendors. Without one, vendors can only estimate. The variations you pay for later will be real costs.
What to write
- Every value to be read or written: name, source asset, and address if known.
- Data type, engineering units and expected range for each value.
- Required sample rate for each value. State only what you need, because sample rate drives cost.
- Which values are read-only, and which values (if any) are written back.
- Retention: how long each value must be kept, and why.
Common mistake
Asking for every value at one-second intervals. Sample rate is easy to over-specify and expensive to deliver. A controller sized in 2008 may not handle the extra load.
Where the data has to go
04Cost depends far more on the number of system boundaries the data crosses than on the complexity of what is built.
What to write
- Which systems must receive the data? Name the product and version.
- Does any data flow back towards the plant? If so, what data, and who authorises it?
- Who owns each of those systems, and have they agreed to this?
- What happens to the data flow when one end is unavailable?
Common mistake
Assuming that the owner of the receiving system has agreed. On more than half of stalled projects, nobody had asked them.
Network and access
05Once systems are integrated, an informal boundary between networks becomes a security control that the operation depends on. If you specify it after the build, it becomes a change request. If you never specify it, you risk a security incident.
What to write
- How are the plant and business networks separated today?
- How will the vendor get access during the build, and how will that access be removed?
- Who owns security for the operational side? Give a name.
- What must never be reachable from outside the plant?
Common mistake
Arranging vendor access informally on the first day. That access becomes a permanent account that is still open three years later.
Fixed constraints
06A constraint found during the build becomes a variation, with extra cost. A constraint stated at the start is a design input and costs nothing extra.
What to write
- What downtime is available, when, and how far in advance must it be booked?
- What certifications, warranties or class requirements limit what may be connected?
- What environmental conditions must the equipment withstand?
- Which permits are required, and how long do they take to obtain?
- Are there periods when no work may take place at all?
Acceptance
07Without written acceptance criteria, the parties have to negotiate when the work is complete. With written criteria, a test decides it.
What to write
- Which test, run by whom, shows that the system works?
- What accuracy or availability is required, how is it measured, and over what period?
- How should the system behave when a source is unavailable?
- How long does the system run under observation before acceptance?
Common mistake
Accepting the system on the day of commissioning. Ask for a defined observation period afterwards. The failures you most need to catch can take two weeks to appear.
Handover and exit
08Agree the terms for ending the engagement at the start. By the time you need those terms, you will have the least bargaining power.
What to write
- What documentation will be delivered, and in what format?
- Who holds the credentials, licences and source code at the end?
- What training will be provided, to whom, and will it be recorded?
- If you hired a different integrator next year, what would they need? Would they get it?
- What does support cost after the first year, and what does it cover?
Common mistake
Accepting "we'll provide documentation" without a list of the documents. Ask for the list. Put it in the contract as a deliverable with its own sign-off.
Blank template to copy
UNIT 10Save your result
↓Your result as plain text. You can paste it into an email, a board paper or a request for quotation without giving us your email address. It stays clear when you forward it to a colleague who has not seen the tool.
Technical references
UNIT 11These are the sources for the reasoning on this page. We mark standards that you must pay to read. Where a free document covers the same subject better, we list it first.
- ISA-95Paid standardISAThe standard for integrating enterprise and control systems, and the source of the Purdue level model. It gives the official definitions of Levels 0 to 4.
- OPC UAOPC FoundationThe specification and its security model. If a vendor offers OPC UA, use this to check exactly what they are offering.
- Modbus specificationsModbus OrganizationThe protocol specifications, free to read. If a vendor is quoting you for Modbus work, read the application protocol document once.
Links open in a new tab, so you do not lose anything you have entered on this page. We checked every link when we built the page. If a link no longer works, please tell us and we will remove it.
Each of these tools is a short version of a conversation with one of our engineers. If your result raised a question you want to discuss, book a scoping call and bring your result with you.
More resources
- Framework
The Readiness Model
The full method behind the readiness assessment. For each of the five dimensions, it explains what it measures, how it fails and what it costs to fix before a build.
- Framework
Pilot to production
The checks a working pilot must pass before it runs live operations, and the ones where most automation projects at small and mid-sized firms fail.
- Framework
Vendor scorecard
A weighted scorecard for comparing integration vendors on the factors that decide project outcomes. It includes the questions we recommend you ask us.