Automatic PLC Code Generation & Design Interchange Standards

Open standards, more powerful desktop computers, and lower cost software are making design, modeling, and automatic code generation for PLCs and PACs practical for improving automation.

Innovations in Product Life Cycle Management (PLM), modeling and simulation software are enabling virtual designs of machine, production lines and processes to avoid costly mistakes in actual implementation. The entire plant and controls can be commissioned virtually to find problems before committing to real machines and controls - reducing the time it takes to startup the manufacturing process and avoiding costly rework at production startup time.

Open communications between modeling, simulation, PLC software and controllers is essential to achieve wide adoption of virtual design methods.

The following illustrates progress made in modeling and automatic PLC/PAC code generation.

PLCopen XML Standard

The PLCopen XML interchange standard version 2.01 is an open (non-proprietary) data interchange standard that has been adopted by the AutomationML group as part of an initiative to offer a common, top level XML format for all plant data including topology data, 3D geometry, kinematic data, sequence description, and logic information. There are proprietary approaches to accomplish code generation from models, but they use proprietary interchange formats unique to the modeling software and specific PLC vendor’s products, and therefore limit application possibilities. The PLCopen standard provides a vendor neutral open standard to accomplish the objective of broad adoption.

The PLCopen XML schemas and documentation as well as an introduction are available free to anyone. The downloadable files include a 156 page explanation of the PLCopen XMLSchema and a 58 page document describing the standard and XML schema files.

AutomationML

AutomationML is gaining momentum as an overall standard for design and open plant information interchange. The goals of AutmationML are to reduce engineering costs, lower engineering time, open engineering data to protect investment, and lower entry barriers for innovative niche product & service vendors, seamless data transport, and data consistency. The AutomationML group notes that the economic driver for their efforts is that nearly 60% of the costs of automation control and robotics today are engineering and commissioning. Automation and controls members of the organization include ABB, Kuka, Siemens, and Phoenix Contact.

In addition to the PLCopen XML standard, AuotmationML has also adopted other standards including CAEX, COLLADA, and MathML.

CAEX

CAEX (Computer Aided Engineering Exchange) a neutral data format that allows storage of hierarchical object information such as the hierarchical architecture of a plant. CAEX is currently applied in the areas of process engineering, control engineering, oil & gas industry and manufacturing automation engineering. On 12 August 2008, the final version of IEC 62424 (Ed. 1.0) was published.

COLLADA - Digital Asset and FX Exchange Schema

COLLADA defines an open standard XML schema for exchanging digital assets among various graphics software applications that might otherwise store their assets in incompatible file formats. COLLADA documents describe digital assets as XML files, usually identified with a .dae (digital asset exchange) filename extension. www.collada.org

MathML

MathML (Mathematical Markup Language) is a low-level specification for describing mathematics as a basis for machine to machine communication. This specification, from the W3C group, is based on XML for describing mathematical notation and capturing both its structure and content. The goal of MathML is to enable mathematics to be served, received, and processed just as HTML has enabled this functionality for text.

More information will be available at the AutomationML User Conference which will take place on May 5-6, 2010 at ABB Forschungszentrum Ladenburg near Mannheim, Germany. At the conference, topics to be discussed include data formats, AutomationML concepts, developer workshops, tools for supporting AutomationML and future developments.

Databases - The Perfect Complement to PLCs

LCs? Okay, you’ve tackled PLCs and now you can program ‘em with one hand behind your back. So what’s next? What’s the next logical challenge? Think SQL and relational databases. Why? You’d be amazed the similarity. It’s the next logical progression.

You might ask how it is they’re even related. For one thing, relational databases can sort of be an extension of PLC memory. Live values can be mirrored there bi-directionally. Historical values and events can be recorded there as well. But operators and managers can interact with them too. It’s been over twenty years of working, living, breathing and thinking PLCs, but over the last six years I’ve delved heavily into SQL and learned a lot about relational databases. I’ve discovered that working with SQL is remarkably similar to working with PLCs and ladder logic.

SQL has four basic commands and about a hundred different modifiers that can be applied to each. These can be applied in various ways to achieve all types of results. Here’s an example. Imagine effluent from a wastewater plant with its flow, PH and other things being monitored and logged. That’s what you typically see. But now let’s associate other things with these, such as, discrete lab results, the name of the persons who did the lab work, the lab equipment IDs and calibration expiration dates, who was on shift at the time and the shift just prior, what their certification levels were, what chemicals where added and when, who the chemical suppliers were, how long the chemicals sat before use, and so forth ad infinitum. All of this becomes relational data, meaning that if it’s arranged properly in tables you can run SQL queries to obtain all types of interesting results. You might get insight into the most likely conditions which could result in an improper discharge so it can be prevented in the future.

In my explorations of SQL, I found myself looking at the layout of my tables and evaluating the pros and cons of each layout. I massaged them, turned them on their side, upside-down, and finally ended up with the most appropriate arrangement for my application. And similar to PLC programming, I explored innumerable what-if scenarios. I was struck by the amazing similarity in my approach to developing solutions for PLCs. This has been a lot of fun – in fact exhilarating – just like PLCs used to be. It’s the next logical progression you know.

SQL is a high level language that isn’t very hard to learn and you can be very clever with it. I prefer to think of it as a natural extension to my PLC programming skills. Now that you have the machinery running, what did it do? Furthermore, relational databases and SQL pull people and processes together. Machines don’t run alone. They’re merely part of a containing process and that process was devised by people. SQL and relational databases form the bridge to integrate processes, machinery and people together. I don’t believe a COTS (commercial-off-the-shelf) package can do it any more than you could offer a COTS palletizer program and have it be of any use. It just doesn’t work that way. Every machine is different. And every business process is different. That’s where the SQL comes in. It has to duplicate or augment existing process flows and these are intimately connected to the machinery. And that’s why the PLC programmer is best suited to implement solutions involving PLCs and relational databases.

So where do you start? I would suggest picking up a book at the bookstore like one of those dummies books. Then download and install the open-source MySQL database server along with the MySQL Administrator and Query Browser. It only takes a few minutes to install and then start playing. You can read about a LEFT JOIN or INNER JOIN but typing one in and observing the results is worth about 1000 words. At the end of an evening you’ll probably be very excited with all of your new found knowledge and be thinking of endless ways to employ it in your own field of practice. Happy SQLing!

Safety PLCs Provide Space Savings For OEMs

With a growing focus on safety and an increasing number of safety products installed on machinery to protect personnel, end users are finding a greater number of safety relays in their control panels. There is a great desire to reduce panel space and wiring, improve communications and increase the automation of all control systems — including safety. This has piqued the interest in safety programmable logic controllers (PLCs) in safety-related systems.

Safety PLCs provide all of the same functionality of traditional safety relays, but offer space savings and improved communications, while also providing the safety levels needed for the protection of personnel. Used primarily in large systems, safety PLCs can provide a greater concentration of safety I/O in a smaller footprint than safety relays, saving control panel space and related interwiring. All of the functionality of safety relays, from emergency stops to light curtains to zero speed control, are provided in safety-certified function blocks. While safety relays are typically rated up to category 4 per EN/ISO 954-1 only, safety PLCs generally include this rating, along with ratings up to performance level “e” per EN/ISO 13849-1 and SIL 3 per IEC 61508. These ratings will allow safety PLCs to be used in most safety circuits.

A variety of communications options are available with safety PLCs. Some communicate safety-related information via the backplane of the PLC rack and through the cables connecting the various PLC racks, but external communications are typically not safety rated. Others provide safety communications only between the safety PLC processor and remote I/O via a certified safety communications network, and external communications are also non-safety rated. Still others have communications networks that can carry safety and non-safety information on the same cable at the same time. The latter systems can either be used for safety only, non-safety only, or a combination of safety and non-safety-rated communications simultaneously. This allows the user to choose between using one network for both safety and standard control system communications, or separate networks for safety and control running independently from each other – in short, whichever method is the best fit for their application. All safety PLCs have communications networks available that are not rated for safety but are used for non-safety-rated communications such as diagnostics, allowing them to communicate to other standard PLCs in the system.

This flexibility is important, as many times a user will want to upgrade their safety systems but not disturb the existing control system which is running well. The control system may or may not communicate seamlessly with the safety communications of the safety PLC chosen for the upgrade. They may want to choose a safety PLC that can run an independent safety network amongst all of the safety components and then communicate the data and diagnostics separately to the system to keep the two systems separate. All of these networks can allow improved communications between the safety and control systems, as well as to other supervisory controls. Improved communications along with advanced diagnostics make these safety PLC systems easier to troubleshoot and monitor.

The safety PLCs’ software provides users opportunities as well. Some safety PLCs utilize the same software to program the standard control system as well as the safety-related portions of the control system. Users can appreciate the convenience of being able to program all of the control with the same programming language and software, as there is no new software for technicians to master. The same programming also allows the embedding of safety-related functionality into the rest of the automation and control system. The user does, however, need to make sure the hardware is “non-interfering” and does not have any negative impact on the safety-related components and instructions.

Some safety PLCs have programming software that operates separately from the rest of the standard control system, and for many users and OEMs, this is the preferred method for the safety system. They want to minimize interactivity between the safety system and the rest of the control system, and also want to make sure that if someone gains access to the standard control system and is able to make changes to it, they will be unable to make any changes to the safety system. Once they have designed the safety system, they feel there should not be any changes made to it, and a separate software system with a different software package helps ensure this.

While many are interested in safety automation and safety PLCs, implementing them can present challenges. Some small- to medium-sized systems may have safety circuits that are not large enough to justify a full safety PLC due to the number of I/O and installed cost – for these systems a safety relay or safety controller may be the most appropriate, cost-effective solution. For others, the standard control system is running well, and they cannot justify the cost of replacing all of the existing control with a safety PLC solution that integrates safety and control with the same software package and communications network. The solution here is a separate safety PLC system just for the safety function. Still, there are other PLC automation systems that can run standard control, but to which the safety component can be added at a later time while using the same software and some of the same hardware.

Control Systems Are Increasingly Replacing PLCs in Automation Solutions

Small, fast and cheap PLC-solutions usually offer few engineering options and often do not provide convenient visualisation. In contrast, distributed control systems integrate a host of components such as controls, engineering tools, HMIs (human machine interfaces) and numerous peripheral devices and tools.

The segment between PLCs and the world of control systems – the hybrid market – is currently being targeted by both sides. PLC components are becoming more powerful and they can therefore also process more complex tasks. ‘Lite’ control systems are being introduced and they are increasingly being installed in small to medium-sized applications with less complex automation tasks.

For small and less complex automation tasks with often only few signals standalone PLCs have been and are still used, because until now process control systems have been too expensive for these tasks.

In the process industry many control tasks, eg compressors, centrifuges or steam generators, have been automated as PLC-based package units, leading to variety of different control systems and tools.

Diminishing Returns
The use of different PLCs brings serious disadvantages for the users: different tools increase the training budget and lead to more complexity, but without adding value. Particularly during maintenance, minor changes can cause considerable expenses, as cross-influences from different systems require manual adjusting.

The differences in visualisation and operation as well as the individual alarm concepts used by the various manufacturers can, in extreme cases, even affect the availability and safety of the application and the total plant negatively.

Additionally, the flexibility of the maintenance personnel is reduced because not all users can be familiar with all tools. Often older PLCs can only be maintained by a small number of specialists, many of whom are due to retire over the next few years.

Procuring and storing spare parts for many different systems and products cause additional work and expenses. All these reasons result in higher costs for servicing and maintaining the plants.

In contrast to PLCs, control systems are primarily based on analogue control loops with slow monitoring and control functions but less on fast positioning or switching operations.

The process is operated and monitored in the control room. The systems and plants generally run continuously and often have very high demands when it comes to availability. Consequently, implementing changes must be possible in online project configuration.

Additionally, repairing and changing of components while operating the plant is essential. Applications are often specifically configured for one project and the processes concerned and therefore require powerful and efficient engineering-tools with extensive integration possibilities.

Compact Alternative
Driven by technological developments in the last years, manufacturers of process automation technology are nowadays able to offer control systems with higher scalability as an alternative to PLCs in process-oriented applications. The advantages are obvious: efficient engineering, easy operating and maintaining as well as increased productivity due to intelligent diagnosis.

It is now possible for smaller automation solutions, which to date have been dominated by PLCs, to benefit from the advantages of process control engineering, particularly in the process industry. There are opportunities for use in many industries, including chemicals, petrochemicals, oil and gas, metalworking, cement production, glass production, etc.

PCs and PLCs Have Grown Up

The question is whether or not I believe PC-based controls will replace PLCs, PACs or CNCs.

I’ve been around in the industry long enough to remember when both PCs and PLCs were in their infancy, and the “old-timers” still were designing their control systems around relay logic.

It still sends a shiver down my spine when I recall sitting in front of a multi-door control cabinet chock full of relays and motor contactors, trying to figure out which contact was bad, while I looked at a dog-eared, incomplete set of “as built” blueprints. Ah, those certainly were memorable days.

So, now that I’ve established my bona-fides, along with a few credentials in both age and senility, let’s address the question at hand: PC-based controls or PLCs?

This question has been around for a while, too, but it really got to be a hot topic in the ’90s. Prior to that, any process that required higher-order mathematics—trigonometry functions, for example—was handled by a PC because the PLCs at that time did not have the math co-processing chips. Also, PCs were networkable and could handle a lot of database applications.

However, PCs were notorious for failing in industrial conditions because their hardware wasn’t designed to handle heat, dust and vibration. Also, you were required to have specialized programming skills that the run-of-the-mill industrial electrician/technician did not possess, so if there was a breakdown that required troubleshooting beyond checking the I/O, it often required bringing in outside resources to fix the problem—good for OEMs and integrators; bad for production people.

PLCs were made specifically for industrial control applications. The hardware was ruggedly designed, and the programming wasn’t complicated as it was based on the electrical control wiring ladder diagram.

Joe the Maintenance Electrician easily could learn to program the PLC and then use it as a troubleshooting tool. Curiously, it was about this time that the maintenance mechanic’s life got a little harder. He no longer could just look at a machine for two seconds, declare it to be an electrical problem and walk away to drink coffee and play cards, while the electrician was left to prove that the solenoid valve or cylinder seals were bad.

In the past decade though, PLCs evolved such that they can perform the same functions as the PCs, and the PCs have become more rugged. The advent of soft logic-type programming for PCs virtually eliminated the need for specialized custom programming for most industrial control applications. Both the PC and the PLC CPU still require an I/O interface of some type, whether a PC chassis or PLC rack.

The Logical Platform

The PLC has moved well beyond its original discrete control function to become a multi-discipline platform for plant-wide automation. Mogan Swamy reports.

Customers increasingly need to make good business decisions based on information obtained from the plant floor. But the devices or methods used to enable this must be at an optimal cost, with the minimum ofdisruption in its execution or implementation.

Interestingly, these were the exact driving forces that gave birth to the programmable logic controller (PLC): it was envisioned as a controller to replace troublesome relay panels, to replace costly minicomputers and reduce programming time for various machine tool applications. In its conception, overall, it provided a simpler interface betweencomputers and machines at a relatively low cost.

The concepts upon which the PLC’s development was based, has not diminished, but has been further heightened with a need to define a vision for the factory of the future. This demands the provision of an architectural roadmap, based on hardware and software. Conceptually, the PLC design should depend on prevailing business drivers and emerging technologies and all evidence suggests that the PLC has been up to the task, without slacking on the goalsfor which it was originally envisioned.

In this sense, the PLC continues to play an important role in integrated automation. Theintegration of a PLC into the factory floor makes it not just a single controller, but an extension of thewhole enterprise computer system.

In the current context, it would most likely to be part of the technology mix in more collaborative discrete control systems, designed and built for a distributed manufacturing process and supply chain, but sensitive to a demand-driven market, and the need for real-time collaboration and response acrossthe manufacturing enterprise.

The fact is the PLC has become the workhorse of factory automation. Other technologies such as CNC, motor drives, motion control, robotics, automatic ID systems, and vision systems are now factoryfunctional because they are hitched to a PLC system. This implies that information from all these other domains are the engine that runs the production line, with the PLC taking an event-driven approach that allows for optimization of the production processes,by providing access to real-time events.

Event-driven information, potentially, can be the cornerstone of an effective production-to-business strategy. As this information is captured, as it occurs, it can be moved to enhance production management, improve manufacturing process visibility and streamline supply chain applications. But this can only be effective if the information is shared across theproduct lifecycle and the manufacturing enterprise.

The trend towards a unified and flattened, tiered, and a hierarchical discrete manufacturing environment, has helped the PLC define its own relationship between the different domains in the manufacturing environment, and move towards aproduction-to-business based architecture.This has resulted in PLC trends towards increased communication capability, smaller sizes, better software and implementation tools, and diagnostics. In addition, these developments have tried to address customer demands for open standards, multi-control disciplines, modular architecture, and comprehensiveautomation solutions software.

Quick & Simple PLC Programming

THE use of function blocks for programming of programmable logic controllers (PLCs) is gaining wider acceptance. Rather than the classic “contact and coil” representation of ladder diagram or relay ladder logic programming, function blocks present a graphical image to the programmer with underlying algorithms already defined. The programmer simply completes needed information within the “block” to complete that phase of the program.

The dual benefits of reduced downtime, and ease of use and training, have quickened the adoption of function blocks and the use of libraries of function block components. The adoption of function blocks has also been encouraged by the development of standards that make their use easier. The Internatiional Electrotechnical Commission’s IEC 61131 makes it easier to use function blocks, though some say the standard has reached the end of its useful life. Many manufacturers have turned to IEC 61499, which builds on its predecessor by providing an open architecture for distributed control systems.

The result is that function blocks are becoming widely used and simple enough for a non-programmer to use. Even so, some detractors claim that function blocks can sometimes slow down production development when the blocks allow developers to move ahead without thinking through the process completely.

Risk-averse

Function block technology actually goes back a few decades, but the process control industry was slow to pick it up because of an initial lack of standards and because the manufacturing industry typically doesn’t move quickly. Unlike most areas of technology, plant automation moves at a slow pace. “The controls industry is very, very risk averse. The attitude is, ‘If it isn’t broken, don’t fix it,’ ” says Ron Bliss, software manager of Logix, for Rockwell Automation Inc., of Milwaukee. “I never got fired for keeping things the way they were.”

Bliss notes that the slow pace of advancement in controls programming matches the long lifetime of plant equipment. “If you put in a piece of production equipment, it will be there for 20 years, and those things around it will be there for a long time as well,” says Bliss. “So when you have something there for a long time and you don’t have large budgets, and you have to train someone on new technology, you’re going to push back against that new technology.”

That attitude began to change as manufacturers faced globalization. With international competition becoming increasingly intense, fewer companies today view the status quo as acceptable. They are becoming interested in achieving “continuous process improvement.” While that’s an overused phrase, the concept does represent a shift in attitude at manufacturers, and that shift has encouraged the adoption of new technology.

The controls industry has also seen a shift from the concept of hard wire to flowcharts. Function blocks have been part of that transition. “One of the reason function blocks have begun to take over is that they replace the relay ladder logic that has been around for 40 years,” says Greg Dixson, product manager for Automation Worx at Phoenix Contact, in Middletown, Pa. Ladder logic mimics hard wire. According to Dixson, ladder logic is being replaced by flow logic. “When we think in yeses and noes, we’re thinking in flowcharts. It’s much easier to understand.” Dixson notes that young programmers take much more quickly to flow logic and that it is much more adaptable to personal computers (PCs).

For many plant operators, the continual pressure to improve operations while reducing downtime is partly solved by the use of function blocks for PLC programming. “Function blocks give you time savings and code portability,” says David Stall, electrical engineer at Grob Systems Inc., in Bluffton, Ohio. “Once you have a working function block and test it on a project, you can take it to the next project.”

While function blocks don’t eliminate the need to write code, they do significantly reduce the need to rewrite code. “Function blocks help because any time I have a piece of code, I throw it into a function block and I only have to write it one time,” says Stall. “Any time I have to interface into another piece of equipment, I do it with the function block.”

In some cases, the function blocks can represent actual pieces of equipment. “With a functional block, you’re encapsulating your process; you’re putting an object wrapper around a whole machine with its inputs and outputs,” says Bob Nelson, manager of PLC and I/O (input/output) products in the Discrete Automation Business at Siemens Energy & Automation Inc., in Norcross, Ga. “You can easily tie together pieces of equipment, and the end user doesn’t need to know what’s happening in the machine.”

That makes integration simple, because the function blocks can be put together like physical equipment. “We have customers who are building code that has a physical relationship to hardware architectures. You have a physical representation and code representation,” says Barney Keeton, business development executive at Schneider Electric, in Palatine, Ill. “You may have an OEM (original equipment manufacturer) who builds conveyors with barcode readers at transfer stations. The company could build a directive function block that matches how it links the conveyers together.” So, when the OEM puts the function blocks in the same connective arrangement as the conveyers, the conveyers are connected by software just as they are physically.

One of the biggest advantages of using function blocks is that they are quick, easy to use, and easy to learn. “The benefits of blocks include a more efficient use of time. They are easy to understand, easy to troubleshoot and easy to train people on,” says Dave Woll, vice president of consulting at ARC Advisory Group Inc., in Dedham, Mass.

Function blocks also appeal because they are stable, they reduce complexity, and they are reusable. As for stability, function blocks do not change significantly. In many cases, programmers can use the same function blocks in a wide range of applications.

Function blocks can greatly reduce complexity. A programmer can work with a function block without understanding how it works internally. Some manufacturers have marveled that you don’t need a programmer to make use of function blocks.

Function blocks are also popular because they are reusable. This attribute comes in handy whether a manufacturer is changing a product or migrating production from one plant to another. Once a function block has been developed and tested, it can become part of the manufacturer’s library of functions. “The directive function blocks are reusable from project to project,” says Schneider’s Keeton.

Legacy integration

A benefit not often mentioned in discussions of function blocks is the ability to integrate legacy equipment. “We’ve used function blocks to integrate legacy products in an open network,” says Joe Biondo, e-business manager at Bosch Rexroth Corp., in Hoffman Estates, Ill. “We build a software library that tells our software how to handle this legacy product.”

Not everyone believes function blocks are the answer to more efficient controls programming. ARC’s Woll notes that function blocks can sometimes create more problems than they solve, by designing automation incorrectly. “The biggest problem process manufacturers in North America have is operational failure. That comes from operators doing the wrong thing, or from automation designed the wrong way,” says Woll. “One thing I’m seeing is a trend toward state logic control and away from block-oriented languages.” He notes that with state logic control, engineers are “forced to give a lot of thought to the process and the control it needs.”

Some companies specifically avoid using function blocks, according to Woll, because it is more precise than using function blocks. “At Dow Chemical, they do their programming using state logic, and Boeing does the same thing,” says Woll. “It’s to ensure precision in the design and operation. It’s been a philosophy they’ve had for a long time.”

Other drawbacks to function blocks include the manual effort involved in copying and pasting code, the difficulty in either copying each tag individually or creating new ones from scratch, the need to rewrite code to utilize new tags, and the need to edit the new tags to contain the appropriate preset values.

Even with these limitations, it’s clear that for most manufacturers, the time-savings that comes from using function blocks far outweighs their drawbacks. The trend is still weighed heavily in favor of adopting function blocks and building libraries of this object-oriented code that can be used and reused with little time and effort.