Technical Guides · ASP ENGINEERING LIBRARY

Instrument Data Sheets and Specification Documents

In this article 7 sections

An instrument data sheet is the specification document that defines everything about an instrument: what it measures, under what conditions, with what accuracy, over which communication interface, and with which approvals. It is the contract between the process engineer (what the plant needs), the instrument engineer (how it is selected), and the vendor (what is delivered). Data sheets are the backbone of instrumentation engineering — and the quality of a plant's data sheets determines the quality of its procurement, installation, and maintenance for decades.

A commissioning evidence chain: every acceptance result should lead back to a requirement and identify the configuration that was actually tested.
A commissioning evidence chain: every acceptance result should lead back to a requirement and identify the configuration that was actually tested. View full size

Standard Data Sheet Format

The ISA-20 standard defines the classic instrument specification sheet (transmitters, valves, analyzers, etc.). A complete data sheet has sections:

  • Identification — tag number, service description, line/equipment reference, document number and revision, plant/project name.
  • Process data — the measured variable, fluid and its properties (density, viscosity, composition), normal/design operating conditions: temperature, pressure, flow range, and the required accuracy at the normal point.
  • Functional requirements — signal type (4–20 mA HART, FOUNDATION Fieldbus, PROFIBUS PA, WirelessHART), range and range limits, accuracy and repeatability, response time, turndown, alarm functions.
  • Construction — wetted materials, process connection (size, rating, flange standard), enclosure and electrical classification (Ex zone/division, IP rating), mounting type, and accessories (manifold, bracket).
  • Environmental and approvals — ambient temperature range, hazardous-area approval (ATEX/IECEx/Class I Div), SIL rating if safety-related, and marine/industry certifications.
  • Commercial — quantity, required deliverables (certificates, calibration reports), and inspection/test requirements.

The secret of a good data sheet is completeness with intent: every field is filled because someone decided it, not because the form demanded it. Blank fields on a data sheet become vendor choices — and vendor choices rarely match the plant's intent.

Writing Requirements, Not Solutions

The data sheet should state the requirement and leave the solution to qualified vendors — but only where it matters. Good practice:

  • State functional needs precisely: "accuracy ≤ 0.1% of span including drift over 12 months," not "high accuracy."
  • Specify the interface and protocol (HART device revision, OPC UA server capability) — modern instruments are network citizens; the data sheet is where that is decided.
  • Name the process fluid, its composition limits, and the process conditions at the mounting point — a pressure transmitter selected for a clean gas will not survive a slurry service.
  • Leave manufacturer/model open for competitive bidding unless the plant standardizes (a legitimate choice — standardization documents should say so).
  • Reference the plant's engineering standards (wiring, mounting, tagging) so the vendor's offering conforms without asking.

Data Sheets in the Lifecycle

The data sheet is created during design, but it lives on:

  • Procurement — the RFQ package and the purchase order reference the sheet; the vendor's quotation is compared against it line by line.
  • Vendor document review — the vendor returns the filled sheet with the offered model; review against the requirement: accuracy, materials, approvals, and options must match.
  • Receiving and installation — the delivered instrument is checked against the sheet (tag, model, options); a wrong manifold discovered at commissioning costs a shutdown, not a purchase order change.
  • Maintenance — the sheet is the reference for spare parts, calibration ranges, and replacement; keep it updated when a substitution is approved.
  • Retirement — the record of what was installed remains in the plant's instrument database, linked to the loop folders.

Modern Instrument Data Management

Instrument data today usually lives in a database (CMMS or a dedicated instrument management system) rather than paper files: tag, data sheet fields, calibration history, and device configuration linked to the device management tool (AMS-style). The discipline is the same as paper: one authoritative record per tag, change control for substitutions, and the data sheet as the template the database follows. The DB also enables the strategic views — device age, spare part coverage, SIL proof-test planning — that paper cannot.

Summary

Instrument data sheets are the specification contracts of the instrumented plant: process conditions, functional requirements, construction, approvals, and commercial terms — written as requirements, reviewed against vendor offers, and maintained through the lifecycle. Invest in the data sheet at design time; it is the cheapest quality control the plant will ever buy, and it is the document every later engineer will look for first.

Apply this to your project

  • Agree the test boundary and site authorization, especially where outputs or communications can affect operating equipment.
  • Record expected and actual values, equipment identifiers, software revision, test conditions, and exceptions.
  • Retest changed behavior and archive the final configuration with the test record and recovery instructions.

Follow an ASP project guide to connect the fundamentals with implementation and acceptance.

Engineering review sequence: Prepare → Execute → Resolve → Release. Keep the recorded evidence with the accepted configuration.
Engineering review sequence: Prepare → Execute → Resolve → Release. Keep the recorded evidence with the accepted configuration. View full size

Primary references and further reading

Use the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.

Use this guide in context. Examples are engineering starting points. Confirm device documentation, site requirements, and acceptance criteria before implementation. How this library is maintained · Suggest a correction

FROM REFERENCE TO REAL PROJECT

Bring your next automation challenge.

PLC and DCS engineering, OPC connectivity, and digital transformation. Start with your installed systems, your constraints, and what you need to achieve.

Talk to ASP OTOMASYON