Programming Software 2013

Why Machine Builders Say Software Needs to Be More Hardware-Aware

By Jeremy Pollard

I've been asking around about the state of the programming software union. I believe it's a boring arena now, with little innovation. What's valuable? What's missing? In general, "Hey, what do you think?"

Colm Gavin, engineering software product manager for Siemens Industry, believes the platform makes the difference. And, it had better be flexible enough to interface with cultural differences.

SEE ALSO: Programming With Old and New

Major influences consisted of mass operation functions (macros) in the instruction set, like function blocks in IEC-61131, mouse functions for one part of the world, and keyboard contexts for the other side of the world.

What's missing is a common HMI and PLC interface suite. This dovetailed with Jeff Payne, product manager for AutomationDirect, whose opinion is that a system-wide, common database is paramount in this mature market. Payne's view of a networked environment mirrors Gavin's in that devices across the system should be common and presented with commonality, regardless of what or where they are.

Andrew Stump, design software manager for Rockwell Automation, alluded that the "missing pieces" might be user-driven. Along with Payne, Stump believes that hardware is hardware, and the software needs to embrace all users with functionality and skill levels. Not to say that hardware is all the same, but I think the point could be that your user might not be as proficient in some areas as he or she might be in another area.

A common theme with all three contributors is the need for software to be hardware-aware. Payne likes the idea of auto discovery, and I can't disagree. "Tell me what's there" can be helpful for the maintenance guy. Oh, there's another component that isn't there.

Gavin endorses the system-hierarchy-type display that can educate the user quickly.

Not to say that hardware is all the same, but I think the point could be that your user might not be as proficient in some areas as he or she might be in another area.

– Jeremy Pollard

Stump's view of the hardware support is to place hardware-specific instructions and displays in the software for the programmer and designer, as well as the maintenance person. I can attest to the value, since we didn't ever have that in the Stone Age of early software.

Gavin identified a user absolute in software navigation. Payne and Stump agree. I suspect this comes from the marketing guys: the hardware must be supported in the best way possible. One might not care that a descriptor is only 10 characters, but not having hardware support "to the nines" isn't acceptable.

Payne touched on device structures, which are part of IEC-61131 data typing. Similar to structured languages, it can provide a compact view into a device.

Stump was also quick to suggest that commercial, third-party devices have to be incorporated into the design process.

So, it seems the main use for a vendor's programming software is to support its hardware. Novel idea for sure, and instruction sets will reflect that. The main issue for users that I got from all three was the view of the canvas. How does the picture look and, if you want to get somewhere, it better be easy.

I also asked Bill Lydon, managing director of PLCopen North America, a position I held until a few years ago. Lydon indicated that PLCopen recently extended the function block platform of motion control to fluid power, with definite-purpose functions to perform a specific task. I would imagine that Bosch Rexroth and others would be providing this with their hardware.

Also, a common platform point is the XML interchange between modeling and programming environments. Coupled with the common platform theme, Lydon expects more of the HMI and programming in the same room. PLCopen has been engaged with the OPC Foundation to provide exactly that.

While it's a pure plug for IEC-61131, he argues that software needs to provide productivity advantages. The suggestion is that programming and HMI software need to have a common database, ability to have application-specific instructions, which Stump also supports, along with a data-typing scheme with structures, etc.

And, this is where all things collapse. Lydon suggests that a standardized programming convention is needed to support future generations. While it might have merit, most would agree that it will never happen.

All of the contributors I spoke to believe that since their software is mainly there to support their hardware, and that each have their own marketing and design philosophies, PLCopen's standardized platform might only exist in parts.

Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.


  • <p>Jeremy:</p> <p>I think you are looking at the WRONG END OF THE EQUATION !!! Vendors will enhance their products they will. Owner Operators need to Change the Game!</p> <p>Step back and look at the BIG PICTURE!</p> <p>The number of separate systems is growing at a very fast pace and the pace will get FASTER!</p> <p>The Main Cost is related to Integration and Compliance followed by others Trusting Data from Your Application and being able to use it the way THEY NEED :)</p> <p>So, let's approach the need via Systems Engineering Concepts?</p> <p>Use one or more Standards to Drive the Configurations and Integration Message Structures of each MES and Control System? Yes, this implies an Agile, Centralized Governance System. But, it also Requires the Owner of each MES or Control System to Coordinate Changes. I'm NOT suggesting Configurations be remotely applied unless that is the design. I prefer to have the Human Responsible for each IT Silo, be it within MES or Control, coordinate the Two Phase Commit AND be the only one who makes changes to his or her Application.</p> <p>This SHOULD NOT be a Big Effort. ISO 15926 provides an Equipment Structure, ISA 95 provides a Message Structure, OPC UA may be good for the Configurations when coupled with something like FDT, etc.</p> <p>Just Grow It as Justified.</p> <p>Yes, this is a Quest of mine based on 30+ years participating in Standards Activities :) </p>


RSS feed for comments on this page | RSS feed for all comments