PLC Programming

Reliable and Robust

During discussions about RLL's popularity, Morley, with his unique flair for explaining things, adds, "Most software development languages are ‘go to' languages, meaning the program jumps from routine to routine based on the results of the current routine. Without a really good structure and extraordinary discipline by everyone that ever touches that software, unexpected and often undesirable and even disastrous results can occur. Pure RLL is a ‘come from' language. That means if one line or rung of the program is incorrect, nothing drastic is likely to happen. It's this fundamental difference between a ‘go to' and a ‘come from' language that enables RLL's robustness. When you think about it, each rung of RLL is really a complete program. It's that simplicity that allows the guy or gal, who is usually an electrician on third-shift, to quickly deal with a problem they find."

Of course it's understood that having a robust programming language is nearly worthless if the hardware isn't equally robust. In that regard, PLCs have established an unprecedented record for reliability and availability in applications ranging from chicken farms to amusement parks, and even on the International Space Station.

The inherent notion that the term PLC implies reliability was established by the Modicon project 084's developers, and can be witnessed at Modicon's headquarters in North Andover, Mass., where an early Modicon 084 that provided nearly 20 years of uninterrupted service at a General Motors manufacturing facility is on display.

Eventually the PLC's reliability became so legendary that it was used in safety applications.

RLL in Safety Applications

Though some will argue that any PLC can be used in functional safety applications, there is a class of PLCs available that have been specifically designed as "Safety PLCs."

The fundamental differences between a conventional and a safety PLC is that the safety PLC is designed to be fault-tolerant and fail-safe, meaning:

• A single fault in the system must not create erroneous inputs or outputs, nor prevent the system from performing its designed purpose;
• All detected faults must be alarmed and provide indication of the nature and location of the fault; and
• Any single fault must be repairable on-line without interrupting the safety PLC's operation.

In order to meet these criteria, safety PLCs include special design characteristics, such as:

• Robust internal diagnostics of hardware and software;
• Use of special software techniques to ensure software reliability;
• Use of on-line hardware redundancy with automated switch-over and recovery capabilities; 
• Exhaustive testing and certification designed to ensure the safety PLC conforms to relevant international safety standards.

Among the risks of using a conventional PLC as a safety PLC is overcoming the tendency of electricians and instrument technicians to use conventional PLC troubleshooting techniques on safety PLCs. For example, most conventional PLCs permit persons with proper login credentials to bypass inputs, force coils, reset timers, disable outputs, etc. Using those sorts of "on-the-fly" practices simply isn't acceptable in functional safety applications. In fact, such practices are often banned and/or are subject to rigid change control procedures.

Several approaches have been designed to prevent unauthorized and/or unsafe changes to safety PLCs.  One of the latest is the use of pre-engineered, pre-tested software modules that can't be modified, and that have been third-party-certified by such organizations as TÜV Rheinland Industrie Service  GmbH.

Certified pre-engineered software module availability varies from manufacturer to manufacturer, and the available choices often reflect the needs of a specific industry served by the PLC manufacturer (i.e., process verses discrete manufacturing verses transportation). When evaluating pre-engineered modules, pay close attention to these characteristics and features:

• Alarming per good engineering practices, such as EEMUA 191;
• Pre-engineered failure handling, especially important for sequencing modules;
• Standardized operator graphics, which are often optional, but usually worth the additional cost;
• Richness of the library of modules;
• Off-line simulation capability; 
• Managed by-pass handling.

One of the things you may find when examining pre-engineered functional safety software modules is that these modules often are written in a IEC 61131-3 language other than RLL. Initially this may seem like a serious drawback from a maintenance perspective, but it's important to keep in mind that safety PLCs have an entirely different purpose than control PLCs. It will be very rare that electricians and instrument technicians are troubleshooting or even viewing the software of a safety PLC, so when evaluating safety PLCs, it's best not to get locked in to thinking, "It must be RLL or nothing."

Listen to the Users

So far, we've seen 40 years and counting of advances in microprocessors, memory chips, operating systems, programming languages, communication protocols, etc. Yet through it all, the programming language of choice for the PLC remains essentially unchanged. Why? Because in 1968, the inventors of the PLC listened to their users. Today users can quickly and efficiently interpret the RLL hosted in any one of a dozen different brands of PLCs because of RLL's transparency.

Job well done, Bedford Associates Project 084 Group. Thanks!

Dave Harrold is a Control contributing editor and co-founder of the AFAB Group.