Instrument index insights

Greg: The literature is sparse on the many diverse requirements for successful instrumentation design and implementation. My primary motivation in this column is to share practical knowledge often gained the hard way by practitioners. We are fortunate to capture the expertise of Mike Laspisa as to what is essential in getting the best core document for an instrumentation project, the instrument index. Mike spent 37-plus years working in the instrumentation and control (I&C) discipline, including 32 years as a lead I&C engineer or manufacturing plant staff I&C engineer.  Mike has helped us considerably in previous columns “Instrument specification: Where we are and where we should be” and “I&C construction scope.” Hunter Vegas, engineering manager at Wunderlich-Malec, is also chiming in. Hunter is coeditor of the Process/Industrial Instruments and Controls Handbook Sixth Edition. Hunter is also cofounder of the ISA Mentor Program and coauthor of 101 Tips for a Successful Automation Career.

What are some key aspects, Mike?

Mike: The instrument index has been around forever. Initially mainframe computers were used by large engineering firms to produce device and piping line lists for mostly industrial utility projects. For the majority of firms/projects back in the 1970s, the Index was mostly drafted on 11x17 Mylar sheets or hand printed on 8-1/2 by 11-in. pages. It wasn’t until PCs were installed in engineering offices in the early 198’s that the Lotus 123 spreadsheet, or early databases like dbase II/III, started being used to create them. Its evolution to electronic media and relational data model structure has allowed the index to become a more powerful I&C project execution tool that includes “Issues for Approval” (IFA), “Issues for Bid” (IFB), and “Issues for Construction” (IFC).

Index preparation is usually started during the development of the "Issued for Approval" (IFA) of the piping and instrumentation diagrams (P&IDs) following I&C device tag assignments. This initial version of the index should be used to document the project device and input/output (I/O) counts so that scope creep can be identified and tracked.

Tag assignment is crucial because a scheme change later on will impact many project documents and adversely affect scope tracking. Device symbols and tagging conventions can be per ANSI/ISA-5.1 or a hybrid concept incorporating your client’s preferences. The P&ID legend sheet(s) should include the basic tag convention table and symbol definition chart for the project. Ask your client if they have tagging/symbol standards before beginning IFA P&ID development.

Hunter: One role of the instrument index may be to make sure that duplicate tag numbers aren’t assigned. If the tags are being assigned sequentially, we’ll often sort on tag number before adding new ones to avoid duplicates.

One caution about tag number schemes. Some plants try to incorporate “smart” tag numbers that indicate instrument location (such as floor, bay, etc.). This is great in theory but can be difficult in practice for a greenfield or brownfield project. In some cases, the physical locations may not be known for some time, yet tags need to be assigned so basic work can get started and the P&IDs created. This forces you to guess on the location and then adjust tags later which can require a significant amount of rework. Long story short—carefully consider the value that “smart’ tag number assignments provide. Sequential numbers are much easier to handle.

Greg: What is the progression in project phases?

Mike: What starts as basically just a list of devices, develops into a multi-functional document as the project transitions through its different phases.

Engineering project execution uses include assisting with the preparation of instrument specifications, control system I/O assignments, control panel drawings, construction scopes of work and their referenced installation documents (loop drawings, wiring diagrams, location plans, installation details, field junction box drawings, etc.). Index revision change reports can be used to support engineering change order submittals to the client for approval.

The inclusion of soft tags can support the control system functional definition, especially when advanced control strategies, control sub-system hard I/O handshakes, or arithmetic functions are required for process control and/or reporting. Client reporting needs should be addressed during the development of the control system specification because the index does not usually include tags for the software-generated totalizers that are needed to support shift/daily/weekly production and inventory reports.

The index also includes contractor trade scope definition and installation document references. Each device is identified as being installed, wired and/or tubed (process connection or instrument air drop) by the applicable trade. Instrumentation installation and hook-up is usually included as a sub to the mechanical or electrical contractor. The index provides a device count for the prospective contractor bid proposals. After bid awards, it can also be used to track device scope additions, deletions and changes. This has proven to be successful, especially on large projects, in evaluating contractor work-order change requests. A tracking coding method also makes it easy to provide contractors with detailed lists of devices that have either been added (A), deleted (D), or changed (C) since the bid and construction issues of the index.

Hunter: Often there are different “versions” of the instrument index that share common data. For instance, an engineer responsible for hardware/electrical design will be focused on real world I/O and not really care about software-related tags or tags for soft I/O (e.g., I/O communicated over networks). The engineer responsible for instrument specifications only cares about physical instruments (whether or not they have wires on them) and would not care about soft I/O tags. Meanwhile, a configuration engineer cares very much about hardwired and soft I/O tags and software devices, but doesn’t care about relief valves, pressure gauges or remote versus local transmitters.

All of this information can be incorporated into a single instrument index/database if it is created wisely and each interested party can easily pull out the information they require while ignoring the rest. The most difficult aspect here is allowing multiple parties to access and adjust their information without impacting the others. The other difficult challenge is making others aware of changes you made that impact them. (Such as adding a transmitter, or replacing one type of flowmeter with another.) Change tracking can be very difficult—it is not enough to flag a line in the index and note something has changed. There might be 50 or 100 items in that single record forcing other groups to cross check each item to figure out what was altered.

Mike: The instrument index can be created and maintained in several formats:

1. A simple Excel workbook file version of the instrument index can at least provide multi-variable sorted lists to support the execution of both project engineering and construction efforts.
2. A database like MS Access allows for customized data entry forms and an integrated multiple reporting structure.
3. Relational database software programs are commonplace. These packages can be used to generate a variety of project documents directly from data entries associated with the I&C device tags.

Hunter: Also, the size and complexity of the project and the number of different parties that must access the index often drive the decision on format.

Greg: What are some additional insights?

Mike: Although sometimes only referred to as an instrument list (or tag list), the index has proven to be much more valuable than just a list of I&C devices.

For me, the instrument index has always been a project control document. And although on large projects I have allowed the index to be updated by select project team members, I have always guarded its integrity by performing frequent reviews and backups to both network and local hard drives. Revision control and history requires extra work and is sometimes overlooked.

Hunter: And while it is easier to have one individual in charge of the index, this is often not possible on a larger job or one that involves multiple engineering firms. If shared control is required, it is paramount that solid lines of communication be established and specific rules as to what changes are allowed defined in advance. 

Greg: Any concluding remarks?

Mike: The instrument index is the backbone of the I&C engineering effort on any project. Its value should not be dismissed as just a list of devices. It is a multi-functional tool used in both the engineering and construction phases of a project. It is used to define the project scope; provide device tag lists for I&C device specification and installation detail preparation; provide software tags for control system configuration and programming; as well as provide the installation contractor with a means to track progress and create turnover packages.

Greg: The Control Talk Columns “Prevent pressure transmitter problems,” “Your DP problems could be the result of improper use of purges, fills, capillaries and seals,” “The art of flowmeter selection,” and “A meeting of Minds” provide a lot of guidance on what can go wrong with our most common measurements.