Legalities: Not all automation standards are equal

Social media poll: Industry standards can be specifications, industrial standards, codes, or aspirational standards. Leave your opinions here.

04/26/2011


Mark Voigtmann is a lawyer with Baker & Daniels, llpI recently took an unscientific poll of automation professionals via various social media groups to ask a simple question: What are the automation standards that you encounter most? There were the inevitable non-answer answers: "I think you need to refine the question." "Any answer you get will be meaningless." And my favorite: “I didn't realize that automation was being implemented by lawyers. But I suppose I should have.”

But then we got into the meat of it.

  • “From a formal standards perspective, I rely on ISA standards where they exist. From there, I fan out to IEC and other accredited standards.”
  • “Definitely ISA 88 and its international shadow IEC 61512.”
  • “Mainly: ISA and IEC. [In] a minor role: NEC, IEEE, PIP.”
  • “IEC 61131 PLC standards and IEC 60417 graphical symbols for use on equipment.”
  • “If you're looking for quality of service issues, I would say the CSIA Best Practices & Benchmarks is a great place to start.”
  • “When it comes to technical work, I would have to say NFPA 70, 70e, and 79. These relate to the National Electric Code and are used by most all enforcement agencies, including OSHA.”
  • “Almost always: UL 508A, NFPA 79, state/local electrical codes.”
  • “I think that ISA95 has much broader applicability to the manufacturing community.”

There were some recurring acronyms of course: IEC, ISA, NFPA, and CSIA. That's when it hit me. One need look no further than the "standards" promulgated by each of these four organizations to see some very important distinctions—not to mention the fact that not all automation "standards" are created equal.

In this sense the individual who wrote "Any answer you will get will be meaningless" had it right. You cannot really assess a standard until you have determined its category. Here are the four categories, as I see them:

Spec standards. IEC 61131-3 strikes me as a pretty good example of a "spec standard." This standard from the International Electrotechnical Commission (now there's an anachronistic, pre-World War I name for you) is said to be the first vendor-independent programming language for PLCs. But, putting that claim aside, there is nothing that requires automation companies to give it any heed—if not specified. For that reason, I call it a "spec standard"—the type of standard that is only in your project if required by the contract documents. (End user-created standards are perhaps the most common type of spec standard.)

Industry standards. By comparison, ANSI/ISA95 fits the definition of what I would describe as an "industry standard"—which means, in my lawyer mind at least, that it potentially has application to your project even if not specified. That is because this standard from the International Society of Automation defines best practices for integrating enterprise and control systems. When I say it "potentially has application," what I am really saying is that if your own method of integrating these systems has problems, someone may be hanging ISA95 around your neck. Thus, something is an "industry standard" if it has the potential to be used against you even if it is not in your contract.

Code standards. NFPA 79 is an example of a "code standard." That means not only is it a standard that has attained pervasive influence (such as an industry standard), it also has become—quite literally—the law. This particular standard, from the National Fire Protection Association, governs electrical wiring in industrial machinery. But don't go out of your way to contact the NFPA to find it. It's right there in the code books. Although the ones adopted by the state legislatures and localities are typically a few years behind the most current version, this is only a minor problem. The bottom line is that these do not need to be in the specs to have legal consequences. If you steer clear of NFPA 79, there is a good chance you have broken the law.

Aspirational standards. On the other side of the spectrum, I see the Best Practices and Benchmarks used by the Control System Integrators Association as the paradigm of an aspirational standard. These standards, which cover a range of activities, from business basics to project competency, accurately set apart CSIA-certified integrators as being the best in the industry. But they are not the sort of standards that are specified for a project—and end users rarely see them. This internal quality makes them, in my view, purely aspirational (if applied correctly).

Moving from the most binding to the least binding category of standards, start with code standards (always binding) to spec standards (binding if specified). Then move through industry standards (persuasively binding) to aspirational standards (not intended to be binding). Only by recognizing the type of standard can you understand its legal impact. (Keep in mind there are some standards that can cross over categories, such as those for "lean manufacturing," the ISO 9000 series of standards, and LEED.)

This is only one part of the equation, of course. The other parts are figuring out exactly what the contract says about standards—and how to mitigate any impact. Read more on that in a future column.

- Mark Voigtmann is a lawyer with Baker & Daniels, llp (Indianapolis, Chicago, Washington, DC, and China). His group assists the automation and process industry in structuring projects and resolving disputes. (Mark.Voigtmann@bakerd.com or 317-237-1265).

ONLINE - Reader feedback - join the discussion, leave a comment below

See other "Legalities in Automation" columns below.

Join the discussion: What do you think are the most-used (or most-useful) automation standards? Click here, scroll down, fill in the boxes, and hit submit, to leave your views.

Editor's note: Voigtmann is among speakers at the CSIA 2011 Executive Conference.



No comments
The Engineers' Choice Awards highlight some of the best new control, instrumentation and automation products as chosen by...
Each year, a panel of Control Engineering editors and industry expert judges select the System Integrator of the Year Award winners.
The Engineering Leaders Under 40 program identifies and gives recognition to young engineers who...
Learn how to increase device reliability in harsh environments and decrease unplanned system downtime.
This eGuide contains a series of articles and videos that considers theoretical and practical; immediate needs and a look into the future.
Learn how to create value with re-use; gain productivity with lean automation and connectivity, and optimize panel design and construction.
Go deep: Automation tackles offshore oil challenges; Ethernet advice; Wireless robotics; Product exclusives; Digital edition exclusives
Lost in the gray scale? How to get effective HMIs; Best practices: Integrate old and new wireless systems; Smart software, networks; Service provider certifications
Fixing PID: Part 2: Tweaking controller strategy; Machine safety networks; Salary survey and career advice; Smart I/O architecture; Product exclusives
The Ask Control Engineering blog covers all aspects of automation, including motors, drives, sensors, motion control, machine control, and embedded systems.
Look at the basics of industrial wireless technologies, wireless concepts, wireless standards, and wireless best practices with Daniel E. Capano of Diversified Technical Services Inc.
Join this ongoing discussion of machine guarding topics, including solutions assessments, regulatory compliance, gap analysis...
This is a blog from the trenches – written by engineers who are implementing and upgrading control systems every day across every industry.
IMS Research, recently acquired by IHS Inc., is a leading independent supplier of market research and consultancy to the global electronics industry.

Find and connect with the most suitable service provider for your unique application. Start searching the Global System Integrator Database Now!

Case Study Database

Case Study Database

Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.

These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.

Click here to visit the Case Study Database and upload your case study.