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!