Legalities: Not all automation standards are equal

I 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.

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our CFE Media editorial team and getting the recognition you and your company deserve. Click here to start this process.