Book Excerpt + Q&A with Author of New Edition of Condensed Handbook of Measurement and Control

Book Excerpt + Q&A with Author of New Edition of Condensed Handbook of Measurement and Control

This ISA author Q&A was edited by Joel Don, ISA’s community manager. ISA recently published the fourth edition of The Condensed Handbook of Measurement and Control by Nabil (Bill) E. Battikha, PE. In this Q&A feature, Bill highlights the value and importance of this new edition of his bestselling ISA book. Click this link to download a free excerpt from The Condensed Handbook of Measurement and Control.

Q. Why were you compelled to publish an updated edition?

A. There have been many changes in technology over the past 10 years or so (since the publication of the third edition), particularly in the areas relating to control equipment symbology, sensors, and safety instrumented systems—among other topics. I also received some comments from my students, asking if a new edition was on the way.

The overall success of the previous printings (both the first and third editions were recognized by ISA as best sellers) also encouraged me to review the current book, update it, and publish a fourth edition.

Q. How would you describe the book’s core value to readers?

Its core value is that it covers—in a condensed format and practical approach—the fundamental knowledge required for applying process instrumentation and control. Readers are able to get answers to common, day-to-day questions relating to the implementation of process instrumentation and control systems.

Q. Why do you think the subject matter of this book continues to be relevant and important as a reference resource?

The book addresses the common challenges and concerns in process instrumentation and control implementations that are faced each day.

 

Blog Author Q&A Free Bonus! Click this link to download a free excerpt from The Condensed Handbook of Measurement and Control.
 

Q. What makes this fourth edition different or more useful than the third edition?

The fourth edition includes an entirely new chapter—on Check-out, Commissioning, and Start-up—a new appendix—on A Sample Specification for a Control Panel—and significant updates to all other 20 chapters and nine appendices.

Q. Do you have any other comments you would like to add?

This book is currently being used as the reference material for online courses offered at three North American universities.  You can learn more by visiting my website at www.bergotech.com.

Meet The Author
Nabil (Bill) E. Battikha, PE, has more than 40 years of engineering, management and hands-on experience in the field of process instrumentation and control. He serves as president of Bergotech, Inc., a firm specializing in process control education. Over the course of his extensive career in the U.S. and Canada, Battikha has worked with suppliers of control equipment, consultants and end users in virtually all areas of process control engineering, management and training. His working experience covers diverse industries, including petrochemicals, power generation, specialty and bulk chemicals, paints, films, automotive, breweries, rotating machinery and turbines, municipal and industrial waste incineration, coal handling, explosives and steel. Bill has helped develop ISA standards (ISA84 and ISA91) and presently serves on several ISA standard development committees. Over the course of his career, he has performed plant audits and assessments, co-authored a patent and a commercial software package, and acted as a technical advisor in an international court case. An accomplished author, he has written numerous technical papers and four ISA books on process instrumentation and controls. They include four editions of The Condensed Handbook of Measurement and ControlThe Management of Control Systems (1992), Developing Guidelines for Instrumentation & Control (1994) and Managing Industrial Controls (2014). Over the last 20 years, Bill has been highly involved as a process control educator. He has developed courses and conducted process instrumentation and control training at: Penn State University, the University of Wisconsin, the University of Kansas, the University of Toronto, Dalhousie University, and ISA. He also designed and conducted in-plant customized training courses and seminars for engineering/technical personnel, operators and sales staff. Bill earned a bachelor of science degree in mechanical engineering.

Connect with Nabil
LinkedIn

 

Book Excerpt + Q&A with Author of Process Analyzer Systems Project Engineering and Management

Book Excerpt + Q&A with Author of Process Analyzer Systems Project Engineering and Management

This ISA author Q&A was edited by Joel Don, ISA’s community manager. ISA recently published Process Analyzer Systems Project Engineering and Management by Gary Nichols, PE, CAP. In this Q&A feature, Nichols highlights the focus, importance, and differentiating qualities of the book. Click this link to download a free excerpt from Process Analyzer Systems Project Engineering and Management.

 

Q. Why were you inspired/motivated to write this book?

A. There are many books and other resources available on engineering project management. However, there are few available on control systems engineering project management, and none available—that I am aware of—on process analyzer engineering project management. By writing this book, I hope to ease the engineering and design burden for new and experienced engineers who work on process analyzers.

Q. How would you describe the book’s core value to readers? Why and how would they benefit by reading it?

In my experience, process analyzers are the least understood of the petrochemical and refining disciplines and sub-disciplines. This book presents an opportunity for analyzer engineers and engineers in other areas of project engineering to understand each other better and produce higher-quality new and revamped plants and operating units where process analyzers are needed.

Q. What is the most compelling challenge that the book addresses?

Quality. Of the three corners of project management—cost, schedule and quality—quality is the most difficult to measure and control and, as a result, the most often overlooked. Though quality can seldom be quantified, this book should help engineers identify situations that have the most impact on analyzer engineering quality.

 

Blog Author Q&A Free Bonus! Click this link to download a free excerpt from Process Analyzer Systems Project Engineering and Management.
 

Q. What makes this book different than other books on the subject? What differentiates it?

The first difference is the emphasis on quality and ways to improve and ensure high-quality projects within the limits of budget and schedule. Secondly, the book includes useful photographs and informative engineering drawings of completed analyzer engineering projects. And thirdly, the book provides a complete illustration of all the steps within a realistic project—beginning with project conception to project turnover.

Q. Are there any specific sections/aspects of the book do you feel are the most compelling to highlight in the press release?

Several chapters, in fact, come to mind. Chapter 1, on safety and ethics, is by far the most important chapter; it delineates the professional engineer’s first obligations to the public. It includes: key excerpts from NFPA standards; an excerpt from state engineering laws and rules; and complete codes of ethics from well-known engineering societies. There is also a link to the website of a public tragedy in 1937 that could have been prevented had engineering safety principles been applied.

Along with Chapter 1, Chapter 3 on project risks and quality is key to maintaining budget, schedule and quality. Throughout the book, I encourage readers and users to add their own experiences and ideas to those in the book, and to change the tables, templates and lists to fit their own situations.

In addition, Chapter 4 on project scope and Chapter 5 on data sheet preparation vitally important because a successful project begins with adequate and accurate documentation; it’s always less costly to improve documentation “up front” than to reorder and rework later in a project. I illustrate how to use the best process analyzer data sheets and formats.

Q. Do you have any other comments to make about the book?

Much of the book is written in a “how to” style to give process analyzer engineers a starting point for meaningful project work on process analyzer projects. Though I encourage readers to customize the information to fit their own situations, using these templates to get started will at least help members of the analyzer engineering community to begin writing out the required documentation.

Furthermore, the ideas in this book can be rewritten by appropriate subject matter experts to fit other areas of automation and instrumentation beyond analyzers.

Meet The Author
Gary Nichols, PE, CAP, is a retired registered Professional Engineer in control systems engineering in Texas. He has more than 40 years of experience in process analyzer systems engineering, including applications development, specifying, engineering, constructing and starting up analyzer systems. Nichols earned a bachelor of science degree in chemistry from California Polytechnic State University, San Luis Obispo, and a master of science degree in analytical chemistry from the University of Georgia. He is a member of Sigma Xi, the Scientific Research Society; and a senior member of ISA. He is a Certified Automation Professional, an American Society for Quality Certified Reliability Engineer, and Certified Quality Engineer.

Connect with Gary
LinkedIn

 

Why You Should Establish a High Level of Trust with Your Automation Co-Workers

Why You Should Establish a High Level of Trust with Your Automation Co-Workers

The following tip is from the ISA book by Greg McMillan and Hunter Vegas titled 101 Tips for a Successful Automation Career, inspired by the ISA Mentor Program. This is  Tip #4.

I have managed hundreds of projects and engineers over my career, and one of the most important concepts I stress to my team is to tell me the complete truth − NOT what I want to hear. If a project is running behind schedule, I need to know NOW so I can adjust and possibly recover. If I am told that everything is fine and on schedule throughout a project, only to find problems at the end, then I have no option but to fail.honesty per cent meter

However, this concept goes far beyond project status reports. For example, overstating experience and skill sets on resumes may be common practice, but as a person who routinely reads resumes and interviews engineering candidates, I can unequivocally say that the quickest way to lose an interview opportunity is to overstate or lie on your resume. If I cannot trust you to truthfully fill out a resume, how can I possibly trust you to design control systems with people’s lives at stake? Obviously, listing your work experience is important, but do not take credit for things you did not do and do not claim experience or knowledge you do not have.

If I had to pick one aspect of my personality that has helped advance my career, it would be my reputation as a “straight shooter.” If you ask me a question, I am going to answer it to the best of my ability, and if I do not know the answer, I will say so. Telling the truth breeds trust, and it is that trusting relationship with coworkers and clients that has served me well throughout my career.

Concept: This concept is straightforward. Do not lie, and do not tell people “what they want to hear” just to avoid conflict. People generally give a new acquaintance or business colleague the benefit of the doubt when they first meet them and assume they are a truthful person. However, once the first lie or half-truth is told, everything you say may be called into question. A reputation as a liar can stick with you for a lifetime.

101 Tips for a Successful Automation CareerDetails: Work very hard to establish a high level of trust with your co-workers or clients. Do not commit to goals you cannot achieve, but always deliver what you promise. If the project is not on track, tell your co-workers or client (immediately) and seek advice on the best way to resolve it. Your word should be your bond. If you know the answer, provide it. If you do not know the answer, then saying “I don’t know, but I will find out” is perfectly acceptable.

Watch-Outs: New graduates and inexperienced engineers tend to “pad” their resumes, hoping to get their foot in the door. The fact is that NO new graduate has much worthwhile experience, so the hiring firm has pretty low expectations in that respect. If a candidate declares himself an expert at programming because he wrote a handful of code or claims extensive experience when he has none, not only will he not get hired, he probably will not even get a shot at the first interview.

One prospective candidate submitted a resume via email to my company. One of the hiring managers happened to open the document up with “Track Changes” enabled, which highlighted all of the recent edits to the resume. Apparently the candidate had a degree in “chemical engineering,” but decided to change it to “electrical engineering” since he assumed my company was more interested in that major. Ironically, we hire engineers with either of those degrees, but needless to say we did NOT hire him!

Exceptions: None.

Rule of Thumb: Tell the truth − always. A reputation as a liar can stick with you for a lifetime.

Hunter VegasAbout the Author
Hunter Vegas, P.E., holds a B.S.E.E. degree from Tulane University and an M.B.A. from Wake Forest University. His job titles have included instrument engineer, production engineer, instrumentation group leader, principal automation engineer, and unit production manager. In 2001, he joined Avid Solutions, Inc., as an engineering manager and lead project engineer, where he works today. Vegas has executed nearly 2,000 instrumentation and control projects over his career, with budgets ranging from a few thousand to millions of dollars. He is proficient in field instrumentation sizing and selection, safety interlock design, electrical design, advanced control strategy, and numerous control system hardware and software platforms.

Consider the Big Picture When Justifying an Automation Project

This guest post is authored by Roy Kok, vice president of marketing at ARC Advisory Group.

Clearly, any new automation project requires economic justification.  While this often involves hard “dollars and cents” quantification of cost savings from increased production, reduced raw material costs, or increased uptime; it is also about “soft” benefits, such as reducing risks and improving agility.  All contribute to making your company more competitive.  This article will Question mark with different directionfocus on the latter, while also highlighting considerations for the former.  It will also share some best practices that ARC Advisory Group has identified.

When considering a change of any kind and researching the alternatives, it is very important to understand that your business is likely to be flooded with opportunities to invest capital and that change needs to be justified for the benefit of the company.  Personal or department goals need to be subordinated to corporate goals.  In the automation domain, a number of factors should be evaluated for their economic contributions to a justification.  But it doesn’t end there.  Justification must take into account the broader opportunity to better position your company for future competition, likely involving greater agility, additional products, or improved quality.

Example Items to Consider in a Justification

Maintenance and Service Costs – These will increase for older equipment.  Spare parts may be difficult to find.  Direct replacements for a component disappear.  Those familiar with the technologies may become a rare commodity.  In addition to increased costs of repair, older systems are likely to have a longer mean time to repair.  If repair requires production shutdown, this downtime will clearly affect production throughput and it will be important to know your cost of downtime.

Energy Costs – Older systems typically use more energy.  For example, fixed-speed motors are giving way to variable speed drives for energy savings.  Loose process control may cause cycling that can waste energy or affect product quality.  Process control designs can be improved along with more energy efficient process design.

Recycling and Sustainability – These factors may also be relevant in corporate culture or product costing.  Recycle costs or construction materials may figure into the value of a system or its replacement.

Improved Control Dynamics – will also lead to shorter startups, improved product quality, quicker product changeovers and quicker shutdowns.   These will all have associated cost savings.

Removal of Physical Constraints – Modern control systems, for example may improve space utilization even with expanded operations.

Improved Data Analytics – Today’s advanced analytics can help streamline operations through system modeling.  Perhaps a new solution can rely on data analytics – process modeling to remove the need for physical product sampling.  An example of this is predictive emissions monitoring systems (PEMS) replacing continuous emissions monitoring systems (CEMS) in some applications.

Added Flexibility – Existing systems may have been designed and implemented for a specific product and purpose, but are difficult to change and adapt to new product or business requirements.  These can include product variations or changes to batch or lot sizes.   A new system can provide a great deal of flexibility, which could provide significant benefit for your business.

Now, for a couple of items that may not be as intuitive:

Upgrades to complex systems, such as a control system, often provide the ability to make continuous improvements over time, plan for graceful degradation of an automation system, and perform future expansions in a well-managed, modular fashion.

For example, redundancy is typically a requirement in medium-to-large automation applications.  But for smaller applications, the loss of a display console may be compensated for by a backup Web-based HMI interface direct to a controller.  This level of backup can come at a drastically reduced price, while also delivering added flexibility and functionality on a day-to-day basis.

A concentration on modularity for a new system can deliver a great many new features that can be surprisingly easy to implement.  Perhaps you’ll want a text message while you troubleshoot a challenging issue.  Perhaps you’ll want a special report while you are making some control enhancements to generate “before-and-after” analytics.  Or, perhaps you’ll want to plan ahead for integrating additional sensors that you know will be coming with a new enhancement down the line.  Relying on standards and leaving the door open to third-party products and interfaces; ad hoc and short-term enhancements, outside the core functionality of a system could help your company adapt to changing needs.  Selecting the right technologies and data infrastructures and focusing on integrating best-in-class components can address your current needs well; while also significantly improving your ability to respond to future and transient requirements.

Conclusion

Many factors will impact the success of automation or related IT projects.   But first considerations should be based on overall company directives with respect to its competitive stance.  What will make the company more competitive in the future and how can this project influence that?

Then, it’s important for everyone to be involved with the process.  Communicate widely throughout your organization.  Consider all alternatives and re-evaluate and tune the process to drive toward your desired outcome.  If your staff is new or inexperienced in making this type of strategic decision, involve industry experts as necessary, to assist with selection criteria development, architecture development, vendor selection or cost justification.  However, don’t delegate the responsibility completely.  Make it a team effort.

Roy Kok2

About the Author
Roy Kok has worked in the automation industry for more than 30 years, in the areas of OPC technology, communications, HMI/SCADA software, historians, embedded software, and industrial computing. At ARC Advisory Group, Roy is responsible for all marketing management, working with our team to deliver value for both the market and ARC clients. Roy’s experience includes management positions with Intellution, GE, VenturCom, Nematron and Kepware, among others. He has run his own consulting business offering business development and marketing services to a variety of hardware and software companies and he specializes in the areas of strategic positioning, sales process, messaging, social media, and website SEO.

Why You Should Test Every Communication Network Before DCS Start-up

The following tip is from the ISA book by Greg McMillan and Hunter Vegas titled 101 Tips for a Successful Automation Career, inspired by the ISA Mentor Program. This is  Tip #28.

101 Tips for a Successful Automation CareerOver the course of many years, I have learned to be suspicious of anything that is marketed as “Plug and Play.” I suppose I may be the only person with this problem, but with amazing regularity, I find plug and play devices that do not plug and play.

Concept: Control system communications can be a tricky thing. In some cases, the wires are hooked up, and everything begins communicating immediately. In other cases, NOTHING works, and it can take hours, days, or weeks to get the first piece of data through.

Details: It is thrilling to browse for a network printer, find it, and suddenly be able to print without any further problem. Unfortunately, more often than not it does not work that way. The computer cannot find the printer, or the printer driver cannot be found, or the driver is not compatible with the computer’s software, etc. In short, it can take a great deal of time and effort to get “plug and play” devices to actually play.

With the advent of instrumentation networks, many devices and control networks are also marketed as “plug and play.” Presumably, one can just hook up a device, and it will immediately start communicating. However, real world experience suggests that it is not always so straightforward. In my experience, either it works just as marketed and the system communicates immediately, or it will take hours, days, or even weeks to get online … especially if the technology is unfamiliar. Once communications are established, the networks generally work well, but getting to that point can be a trying experience.

If the project calls for the incorporation of a new network type into a control system, fully test it BEFORE the start-up begins. Gather a couple of devices (ideally one of each type), and set up a temporary network in advance to establish communications and get the network configured. Even if the project is just extending an existing network, be sure to pretest any new device types that are not already functioning. New devices usually require a different communication file or may need a special character string to get them to respond on the network. Even new versions of equipment that have been used for years can be troublesome if the hardware revision has changed.

Watch-Outs: On one project, the team added a new positioner to an existing Profibus PA network and did not test it in advance. Once the plant was shut down, the positioner was wired into the network, and problems immediately ensued. First, the positioner was a new model and was not listed as a choice on the system. The correct GSD was found, but then it had to be incorporated into the gateway configuration without deleting the existing setup and rebuilding it from scratch. Eventually, that was accomplished, and the device was finally communicating on the network, but the unit ignored the commands being sent to it. After multiple phone calls to several tech support sites across the United States and Canada, the team finally located an expert in Germany who could speak no English but did know the product. Emailing through a translator, the team finally realized that the positioner required the system to write a hexadecimal command to a certain register in the positioner so that it would accept the system command value as legitimate.

The device literature marketed the positioner as a “plug and play” device.

Exceptions: Some communications networks really do work right out of the box. However, a project team would be wise to plan for the opposite.

Insight: About a week before every major DCS start-up, consider performing a “network startup.” During this time, power up as many of the systems as possible, and bring as many of the communication systems on line in advance of the plant cut-over.

This early effort is critical because it gives the team a full week to resolve any fiber or major communication problems before the plant comes down. If communications are not established in advance, the whole checkout can be stalled while engineers frantically try to establish system communications.

Rule of Thumb: Find a way to test any communication network prior to installation. It may work perfectly without any issues at all. But when it fails to work, it can take a great deal of additional effort to get it functioning.

Hunter Vegas

About the Author
Hunter Vegas, P.E., holds a B.S.E.E. degree from Tulane University and an M.B.A. from Wake Forest University. His job titles have included instrument engineer, production engineer, instrumentation group leader, principal automation engineer, and unit production manager. In 2001, he joined Avid Solutions, Inc., as an engineering manager and lead project engineer, where he works today. Vegas has executed nearly 2,000 instrumentation and control projects over his career, with budgets ranging from a few thousand to millions of dollars. He is proficient in field instrumentation sizing and selection, safety interlock design, electrical design, advanced control strategy, and numerous control system hardware and software platforms.

Reduce Development Time and Project Risk by Testing and Proving New Code

The following tip is from the ISA book by Greg McMillan and Hunter Vegas titled 101 Tips for a Successful Automation Career, inspired by the ISA Mentor Program. This is Tip #27.

101 Tips for a Successful Automation CareerOver the course of many projects, my project team and I have learned this tip the hard way, and with every project we promise to test new or revised software harder and more thoroughly than the time before. Despite all of our efforts, we STILL find small bugs late in the game that require us to touch each and every module to correct. I do not know if we will EVER learn this lesson completely, but we have gotten much more vigilant in our early testing. Pain has been very instructive.

Concept: 100 copies of garbage is a LOT of garbage!

Details: Many young engineers are in a hurry to show progress so they create a template, decide it works, and promptly make 100 copies to show their boss what they have accomplished. Later a bug (or two or three) is noticed, and suddenly they have two or three hundred bugs to fix rather than just two or three.

Earlier tips highlighted the fact that the automation field demands fanatical attention to detail, and this concept is a clear example. When creating a piece of code that will serve as a template for others, beat on it mercilessly to ensure the code is bug free. Once that is accomplished, give it to someone else and let THEM beat on it some more. Test it in every way possible, and make sure all of the problems have been wrung out before releasing it for replication. Doing this takes more labor initially, but it will save hours, days, and even weeks of labor further down the road.

This process seems like a simple task, but actually accomplishing it on a routine basis is always difficult to do. When the project is starting up and lots of activities are going on, finding the time and discipline to thoroughly debug code prior to replication can be challenging, but the consequences of NOT doing it can be dramatic.

This same concept applies to higher levels of programming. When programming a system with five virtually identical reactor trains, create and thoroughly test the software for one train in its entirety before replicating that software to the other four trains. If possible, create the first reactor train software, test it as thoroughly as possible, and then give it to the client for still further testing and review. Once everyone is satisfied with reactor train No. 1, THEN replicate the software for the other trains.

Watch-Outs: Have someone other than the original programmer test the code. As mentioned previously, a second person is much more likely to spot errors the programmer has overlooked.

Exceptions: None … unless the project is a time and material job and maximizing billable hours is the primary goal. (Just kidding!)

Insight: Once a piece of code HAS been tested and proven, consider moving a copy of it to a system library where others can use it. Doing this can save hundreds of hours of development work and reduce project risk.

Rule of Thumb: If a piece of code is to be replicated many times, always have two different people independently test it whenever possible.

Hunter Vegas

About the Author
Hunter Vegas, P.E., holds a B.S.E.E. degree from Tulane University and an M.B.A. from Wake Forest University. His job titles have included instrument engineer, production engineer, instrumentation group leader, principal automation engineer, and unit production manager. In 2001, he joined Avid Solutions, Inc., as an engineering manager and lead project engineer, where he works today. Vegas has executed nearly 2,000 instrumentation and control projects over his career, with budgets ranging from a few thousand to millions of dollars. He is proficient in field instrumentation sizing and selection, safety interlock design, electrical design, advanced control strategy, and numerous control system hardware and software platforms.

Pin It on Pinterest