Greg: Detailed guidance on instrument specifications is seriously lacking in publications. We are fortunate to have Lucinda Weaver provide us with key extensive knowledge she has learned in the process industry. Lucinda has worked on capital projects for more than 45 years. She started as a programmer doing batch control on the Fisher DC2 and, for the last 10 years, has been a project technical lead, supporting instruments, controls and everything else with a wire attached to it. Her projects have been mostly pharmaceutical in the U.S., Maritime Canada, and in Ireland. Retirement came at the end of 2025.

Lucinda, how can we write good instrument specifications?

Lucinda: This alone could be a topic. I would start at the beginning, but I am going to say start before the beginning.

If you wait for the P&IDs to be developed, you are going to be missing instruments that you absolutely need for the project. Make sure you are invited to the P&ID development sessions. If you are not both the instrument and the process control engineer, make sure the process control engineer is invited as well. Project engineers, process engineers and process development engineers know what needs to be done to control the process, but often they don’t realize all the things you need to make that happen.

In the development process, all instruments must be on the P&ID with tags associated with them. Every company tags instruments differently but make sure that tags are unique but also associate loops together. The P&ID symbols should give you an idea of what type of instrument is involved—a magnetic flowmeter should have a different symbol than a mass flowmeter, etc. 

The last thing you must have to start your instrument index (which comes before any instrument specifications) is a line number for every line that has instruments on it. I would say every line, but I will settle for numbers for lines with instruments on them. Oh, and if it is not in a line, but a vessel, put in the vessel number.

Greg: Seriously, you want a line number at the start?

Lucinda: Absolutely, if the P&IDs have line numbers for each line, that is the way you get all your process data from your process engineer. The material balance gives you process data, but not down to the line level. You need to know the process data for each line. The process engineer needs to know that as well so the line number is a great way for you to communicate the date without you laying a pile of partially finished instrument specifications on that person’s desk and have them fill in the same data five times for five instruments, not the same line.

Good instrument specifications require you to be greedy. Don’t say, it is just a temperature measurement I won’t need to know flow rates or pressures on this line. Get it all. Someday some maintenance person will thank you.

Greg: So, on to the instrument index—there is a lot of data in a good index file. How much needs to be filled out before I start writing instrument specifications.

Lucinda: My bare minimum is the following:

Tag number: For my database I broke the tags into four fields to make sorts easier. My fields were building number, ISA designator, primary unit operation that the instrument is associated with and a suffix that identified the instrument or loop.

Description of the process: Something like RX-201 NaOH feed or RX-201 condenser chilled water outlet.

Instrument specification number: This should be the numbers your organization uses to identify the difference between pressure gage specification packages and flowmeter packages. The organization I spent the majority of my time with had about 50 different specification sheets with numbers from which to choose from.

Finally, that line number: Once you have this in the index you can transfer the data to the individual specification tables. If you have a well-designed database, none of your tables look exactly like the specification because everything is well normalized. The specification sheet will spool data from all different tables, so you don’t have to enter any data twice. For the record, my company was not willing to pay to have a well normalized database and, frankly, we liked using the copy and paste function in spreadsheet viewing mode of the database. If you want to talk about normalized databases, you are talking to the wrong Weaver. For that, you need my husband or son.

Greg: So, I am finally writing specifications, how many of those fields in the specifications must be filled out?

Lucinda: All of them, including all the process data, all the materials of construction, everything about the type of instrument, and every letter and number in the part number. If for all instrument types, you have the exact same section for process data it is easy to bring that data in based on the line number. If you don’t take that section the same for every specification type, then count on a lot of manual entry of data.

Greg: Seriously, every letter and number in the part number?

Lucinda: Only if you want what you want. In existing facilities there are usually standards for instruments to keep the storeroom at a reasonable size. I worked most of my career in FDA-validated facilities that required replacement to be like-for-like, and so one letter off in a part number took 10 signatures to use. If you are working on a greenfield facility in a foreign country, you may want to put in a partial product number and use the words or equal to do bidding and then carefully study the bids to decide what you want to purchase because at that point, you are creating the standards for the site.

Greg: How can we update them when the purchase is made, using the database that the specs are written in?

Lucinda: Before I answer this, I want to step back a bit. Through this process I must remember that my organization used a “modernized” version of ISA spec sheets. The traditional ones were made for handwritten specifications where you could put a lot of items on one page, especially simple things like local gages. 

Even the specs sheets I started with 46 years ago had three valves on a page, so you picked three valves that were similar and could draw lines to the valve on the next column to show same data. Throw those old sheets away and make new ones. One instrument per page with generally the same sections and of course the process data section looks the same for every specification. Do I worry about wasting paper having one specification per page?  Nope, paper is very recyclable, and I ate growing up thanks to the wood products industry.

For revisions, I always had three sets of revision columns in my database. These columns were revision number, date, by whom and description. Over the life of the instrument, you would use more than three revisions, but it normally would be years out, so early revisions would not matter.

Get your subscription to Control's tri-weekly newsletter.   

When I worked on a project, I would use letter revisions until I was ready to send specifications out for pricing (meaning outside the company) then remove all letter revisions and start with Rev 0. When I got the bids /pricing back from the vendors, I would simply update the database, fill in the columns for Revision 1 and print the specification out again.

The real important part of this is not just that I had an up-to-date specification going forward. The big part was I worked in pharma, all validated, all the time. So, we had to fill in documents that checked that the received instrument matched the purchase specification, then later that the instrument had been put in the correct place in the pipeline or vessel. We did these sheets by had for years, but while doing a project in Dublin, Ireland in 2007 my site instrument lead asked me the killer of questions—we have all the as specified data in the database, why can’t we print out check in sheets and line check sheets from the database that show exactly what we purchased and leave a place for the field person to put in the as found by hand. As Gru would say, Lightbulb! (and thanks to Ciaran Brady for this idea). So, we made up sheets that also were printed out of the database for the items to be checked when receiving the instruments and could also be used for the line checks.

They essentially had a column describing the aspects of the instrument to look at, a printed column called “as specified” and a handwritten column called “as found”. If the as specified and as found did not match, we investigated and got it corrected. We worked with validation to make sure they would accept the sheets and the rest is history. The biggest complaint I got about these sheets—from the project managers, “but now you have to update the database after purchasing.” Well, duh!

Greg: How can we ensure they are installed correctly and in the right location?

Lucinda: We used the sheets printed out of the database I talked about above to do this. We had a nice protocol written in conjunction with validation to confirm the essential detail. Since I put a line number in the database, that was on our line inspection sheets. Our protocol would call out to check things like flow arrows, limit switch setting and anything we could do up front before we even started on loop check.

I’ll be honest, with the right coaching and documentation you don’t need a fully qualified instrument engineer to do this work. For about five years, I had a summer intern for a full semester/summer co-op student working for me as I tried to corrupt good chemical and mechanical engineers and turn them into instrument engineers. I always tried to have a project in the phase of checking out the instruments in the field against the P&IDs and field check sheets when a new student started. My rationality was that before a person could specify a regulator, they needed to know what a regulator looked like, and this was the perfect way. I was always on the job site answering questions and helping them when needed and we got it done. They learned so well that by the time I had one for a month every project manager on the engineering floor was asking to borrow my student.

Greg: How can we ensure instrument specifications are uploaded and updated in instrument database for total life of the facility document and be used for more intelligent maintenance?

Lucinda: If you follow this system, the specifications will always get updated in the project database because if they don’t, they will never pass the next step. Getting merged into the site database would be part of the project turnover package. Obviously, the maintenance people writing PMs for the instruments would need an early copy of the database to start their work. We made a point to not upload the project database until the end of Operations Qualification because there is always that little part of the process that does not work the way it was supposed to work, that instrument that all of you missed needing during P&ID development and that instrument that just does not work the way you thought it would, so there are some definition last minute revisions. So, one of the steps in the turnover package is to upload the database into the site database. Now, if you have used the database with the same structure as your site database, the upload is easy. If someone at a design firm decided they did not like your database and made changes (and I can name names, but I will not) then before the databases can be merged, you have to unfix those fixes made during the project so everything goes together.  

This is the easiest step to not forgetting. Your site maintenance will not accept the project until this step is done. They will nag you until your death or until they have it (and point all service requests to you until it is done as well).

Once you get the system set up so the mechanics on the floor can get the specifications just like they get the loop drawings and P&IDs, maintenance is easy. An instrument causes problems at 2 a.m. on a Saturday the night mechanic goes to a terminal in the building, logs into the maintenance system, prints out a copy of the loop sheet or wiring drawing, prints out a copy of the specification and then looks online for any manuals they might need to work with the specific instrument. Or if you are an up-to-date site, the mechanic has a tablet that they can pull all this data up on so there is no printing involved. With this much at their fingertips, it is rare that the engineer has to be called in the middle of the night.

When the time comes that the instrument originally installed is no longer available, or the manufacturer decides it will be fun to screw around with everyone and change the part numbers, then the specification will need to be updated again in the system, but with a great database that is only in one location and if works its way down to all the sheets I have referenced above. OK, maybe the loop sheet might need to be updated, there are a lot of us that have not managed to get our databases that neatly tied into our computer automated design (CAD) system.

Greg: Next month, Lucinda provides guidance on creating the instrumentation index and dealing with packaged equipment.