Mark Lamendola
the sheer number of safety-related standards makes it difficult for an industrial OEM to build a machine that will comply with all that seem to apply to it. One way to make compliance easier is to address safety from the very beginning of the development cycle, and programming with function blocks might become an important part of the solution. Theres a good case to be made that function block implementation advantages include ease of design, implementation cost-savings, operational cost-savings, and performance advantages. These are compelling motivations for any machine builder.In many ways, a function block (FB) drawing (See Figure 1) resembles an integrated circuit (IC). FBs essentially are reusable software ICs. We implement the same logic in FB configurations that we would if we had used hardware. We can tap into libraries of standard FBs, which have been tested and verified, to create new applications. This has naturally led designers to explore safety implementation in FBs.Champion the Cause
The use of function blocks for safety application is something PLCopen is working on. PLCopen (www.plcopen.org), Zaltbommel, The Netherlands, is a worldwide, vendor and product-independent association and says its mission is to be the leading association resolving topics related to control programming that supports the use of international standards.FIGURE 1: FUNCTIONALITY FEEDBACK
The use of function blocks for safety application is something PLCopen is working on. PLCopen (www.plcopen.org), Zaltbommel, The Netherlands, is a worldwide, vendor and product-independent association and says its mission is to be the leading association resolving topics related to control programming that supports the use of international standards.
Metso (www.metso.com), Helsinki, Finland, is a global supplier of process industry machinery, systems and aftermarket services. Metso serves customers primarily in the fiber and paper technology, rock and minerals processing, and automation and control technology industries. Safety FBs would help standardize the implementation of safety functionality in a program, says Bob Bettendorf, controls engineer and technical documentation manager at Metso. This would make programs easier to write and easier to troubleshoot because there would be less variation from programmer to programmer.Its important then to start with safety in mind. Safety often is included at the end, and not integrated into the system philosophy, says, van der Wal. This does not contribute to the overall safety aspects, he says, but that is changing. A parallel can be drawn in the movement from hard-wired relays to PLCs, explains van der Wal.To others this evolutionary path looks like it is headed in the right direction as well. The logical progression for machine code implementationsafety or otherwiseis FBs, says Joe Biondo, manager, market planning for PLCopen member Bosch Rexroth (www.boschrexroth.com). The stability and compact nature of the FBs will make usage more widespread.In the FB environment, a user can provide error detection, damage assessment and confinement, error recovery, fault treatment and continued system service. Function Blocks make it possible to test safety equipment remotely, without impacting productivity. In addition, the need for manual testing should drop dramatically as do safety risks to maintenance personnel. Function Block implementation eliminates duplicate training, maintenance, and inventory costs because an industrial OEM can use the same control device for both basic machine control and safety systems. Essentially, it takes much of the safety monitoring and control out of the hardware and puts it into software.Safety implementation in FBs isnt new. Designers have been using it for years. But advances in PLC design, control device intelligence and digital communications have made it increasingly attractive to implement. Object-oriented programming of FBs plays a key role. Today, you can use drag-and-drop techniques to do in minutes what took hours creating pages of coding.FBs tend to have parameters that must be defined and programmed for the intended function, says Jeff Gellendin, product marketing manager, SafetyPLCs, Rockwell Automation (www.rockwellautomation.com), a PLCopen member. One advantage of function block programming is that the âwiring of these parameters is visually obvious and easy to follow, as opposed to ladder logic programming, where the parameter bits must appear on several rungs of logic.Beckhoff (www.beckhoff.com), another PLCopen member, implements open automation systems based on PC-compatible control technology. Gerd Hoppe, a member of Beckhoffs management team, says efforts to implement safety on a machine or in a plant will move from pure electric solutions to those using a mix of electric, network, and software means. This allows users to achieve the same or higher standards in safety, but with less effort, simpler structures and more flexibility. He argues that traditional safety installations easily exceed 10-15% of the total electric machine equipment, and when installed as a separate system they add significantly to the complexity of installations. Simplifying the architecture and the engineering of automation systems positively influences the manufacturing industry, says Hoppe.Some machine builders agree. I see several justifications for using a safety PLC, says Jason Christopher, controls engineer with Liberty Precision Industries (www.libertypi.com), Rochester, N.Y. Liberty builds and commissions machining systems to a wide variety of industries (See Figure 2).
FIGURE 2: A SOFTWARE IC
In many ways, a function block (FB)resembles an integrated circuit (IC). Function blocks essentially are reusable software ICs in that we implement the same logic in FB configurations that we would if we used hardware.
Standardization is another key to this whole process. Some people argue that standardizing limits engineers from employing superior methods as needed, but in reality, that argument doesnt hold up.Standardization is essential in this field, says Hoppe. If screws could tighten by rotating randomly right or left, how would mechanics [know which way to] tighten a screw? The solution was the standardization of the screw thread. In the same way, safety functionality and field use benefit dramatically from standardization.Biondo agrees. Standardization will help the technology supplier, the machine builder and the end user, he says. Although machine builders and technology suppliers can implement their own safety FBs, standardization will improve re-sales by the end-user and international sales in all respects.Its important to keep the role of standardization in proper perspective, however. The standardization effort on function blocks will not drive the usage of safety PLCs, argues Thomas Pilz, CEO, Pilz Automation Safety (www.pilz.com). What will drive it is the cost-saving potential that safety PLCs and safety networks offer in medium to large automation applications.So it seems users arent going to adopt safety FBs because of standardization. Standardization is not a product benefit for the end user. Standardization lowers costs, and that primarily is what the user sees as the benefit.But, this can lead to a chicken-or-egg argument that goes something like this: Until enough people implement safety in function blocks, theres little economic justification to support standardization efforts. But without standardization, people wont implement the technology. This argument, however, ignores the larger picture.I'm not sure the need to standardize safety function blocks is [either] greater or less than the need to standardize âstandard PLC function blocks, says Gellendin, referring to end users who deploy PLCs from several vendors in their plants. He says standardized FBs would allow these facilities to have identical programs for each brand of PLC.Standardizing for safety purposes is only one part of a larger movement toward standardization. PLCopen is creating standards across the board, not just in safety. There is no reason to leave safety out of the standardization process because including it will bring real benefits.Machine builders tend to view standardization as a good reason for the implementation. There is the risk of confusion for the programmer or technician when they switch between different manufacturers using proprietary function blocks, says Christopher. Having different approaches to safety is risky business.Community Concerns
Theres plenty of opinion that says PLCopen has to do more than just agree on methods of implementation. They also need to address concerns that currently block acceptance. From what I have seen thus far, there [will have to be] a lot more âreal engineering involved to get me comfortable with a programmable safety system, says Christopher. With safety relays, the assumption is that they are going to fail in a safe state as a single-point failure. With a solid-state system, the failure mode is unknown, so you really have to know what you are doing and know all of the relevant product data to feel comfortable that you are creating a safe installation.Ladder logic is simple and cost-effective; thats why its so common in control systems. Ladder logic is not going to go away, because there are so many good reasons to use it, says Christopher. With this in mind, Bettendorf says, I would recommend that the task force consider the structure of the safety FBs so the same functionality can be implemented in ladder logic and structured text. Fortunately, PLCopen addresses these concerns with IEC 61131-3, the only global standard for industrial control programming. The standard includes the definition of the Sequential Function Chart (SFC) language, which is used to structure the internal organization of a program, and four interoperable programming languages: Instruction List (IL), Ladder Diagram (LD), Function Block Diagram (FBD) and Structured Text (ST).Yet, there are some other questions that PLCopen must address before their work is done. "How will safety FBs affect legal liability? asks Bettendorf. Will they lessen or increase the machine manufacturers liability? Will they lessen or increase the PLC manufacturers liability? Will the standards group have any liability just because they developed the standard?PLCopen says it is working within the community to address such concerns, but its a two-way street. The community also needs to work with PLCopen to educate each other and end users. Beckhoff is a member of PLCopen, so I am not neutral about this, says Hoppe. However, PLCopen has developed very good skills to define a standard. I recommend that end users build their understanding and get excited about it. This technology opens doors to new, flexible and safe protection systems that allow for operational improvements. Hoppe exhorts manufacturers to communicate the end user value rather than focusing on the cost saving nature of this technology.More Standards Wars Ahead?
Should machine builders be concerned that PLCopen will simply deliver yet another standard that will fight with other standards for dominance? And if so, how do they prepare for what happens when the dust settles?Actually, there are no other standards just proprietary solutions, says van der Wal. And they can be very expensive, since they are normally stand alone, and not integrated into the same software and hardware platform. Biondo agrees, saying, The IEC61131-3 standard is the most accepted by the automation community. The only other âstandards I'm aware of in the discrete industry are brand-specific.So, where does this leave machine builders and their customers? Todays choices for safety add additional systems to the core machine installation, says Hoppe. Integrated safety would represent a huge step forward .The installation and programming would have a simpler architecture with more flexibility, at the same safety levels. PLCopen represents IEC61131-3 as a user group, promoting the only vendor-independent worldwide-accepted programming standard for PLCs and automation controllers. All international automation providers have more or less implemented IEC61131.
Mark Lamendola is a freelance writer and frequent contributor to CONTROL DESIGN with many years of experience working in and writing about industrial automation issues. You can reach Mark at [email protected].