Component Automation Enables Modeling and Control

KEY WORDS

Embedded control

Machine control

Software

Object technology

Programming

Sidebars: Here’s a function block example

Component automation uses object-oriented programming philosophy and techniques. Although ‘object oriented’ may have gotten an undeserved negative reputation in the automation industry through some software company start-ups that were perhaps a little ahead of their time, it is an important tool for the future of control programming.

The techniques are being implemented through two International Electrotechnical Commission (IEC) standards and Unified Modeling Language (UML). IEC 61499 function blocks can be considered to be primarily for discrete control, while IEC 61804 focuses on process industries.

In object-oriented programming, every programming task is considered in terms of objects and their relationships with each other. An object is a self-contained body of executable code. It contains the data required for its function and algorithms (called methods) that manipulate those data. An important feature of objects is ‘inheritance,’ that is, a new object can be derived from an existing object. A ‘class’ can be considered as a template for breeding new objects, to more quickly bring to life specific instances of objects with similar attributes.

For instance, refer to the diagram in this article showing motors. A programmer can create a class called ‘motor.’ This code contains the important inputs, outputs, and control code for the motor along with a description of the types of data needed for control or generated by its operation. As specific motors are selected for various automation projects, a programmer uses the motor class object to create a specific motor object. Once created and saved, this object can be used by the programmer or others whenever this motor will be used on a project.

In object-oriented programming, a class can be viewed as a template for a general object that is instantiated as a specific object as depicted by these motor objects.

One further feature is encapsulation. An object need not expose its methods or data to the world. It may provide just interfaces for inputs and data and events as outputs. Proprietary algorithms may be discretely hidden away.

Don Holley, National Instruments’ (Austin, TX) automation marketing manager, points to three benefits to using component-based design and implementation of automation systems: reusability, scalability, and maintainability. ‘A programmer can develop, test, and document a software component, then confidently reuse it in other applications,’ he continues. ‘Components’ ability to decouple and distribute pieces of an application make it easier to scale different parts of a manufacturing automation system. Finally, large, monolithic applications can be harder to troubleshoot and more costly to support and maintain.’

Adds Brian Martinicky, software development manager at Automation Intelligence (Duluth, GA), ‘Well-written software objects hide low-level details that enable a higher-level, more-organized approach toward solving complex control problems. Decades of control experience can be embodied into an object system that allows less-experienced controls engineers to create solutions like a seasoned pro.’

If objects are represented graphically, then a control engineer can visually map a project and link the map to code. This visual map is great assistance in overall project planning, as well as in commissioning and troubleshooting.

Or, as Kevin Tock, Wonderware (Lake Forest, CA) senior vp and general manager, says, ‘Plants are hundreds or thousands of components working together, so why not model a plant by configuring software components representing plant devices and functions?’

One modeling tool is UML. Using a programming tool, programmers graphically depict a control system, add functions, data, and other essential ingredients, then the program generates code, usually in ‘C.’

Software components can be the foundation for the entire model-based design of embedded control applications.

Chris Kobryn, co-chair of the UML Revision Task Force at the Object Management Group (OMG) and chief technologist at Telelogic (Irvine, CA), is a leader in the effort to develop a standard core technology infrastructure library. Such a library would enable implementation of these tools, also known as Model Driven Architecture (MDA), across different companies’ software.

Mr. Kobryn notes, ‘Model-driven development is a revolution in thinking similar to what has happened in other industries, for example going from CAD to CAM. The end result is driven by models from which you can generate production-quality code. The infrastructure library is a collection of reusable classes that we hope to present as a superstructure of end-user constructs for manufacturing and process control.’

Add some higher math to the model, and complex modeling and control can be accomplished. Mike Dickens, director of marketing at The MathWorks (Natick, MA) says, ‘Modeling and simulation tools are now widely used for the design of control systems in automotive, aerospace, and industrial automation applications. These tools are used to model the operating dynamics of a complete system, including both the plant and the controller.’

IEC 61804 funciton blocks are built upon IEC 61499 function blocks as depicted on the right 61804 blocks can be thought of as defining programming for process control, while 61499 blocks are for programming primarily discrete control.

Function blocks

The source for this discussion of IEC 61499 function blocks is Modelling control systems using IEC 61499: Applying function blocks to distributed systems by Robert Lewis, published by The Institution of Electrical Engineers (London, United Kingdom). IEC 61499 new standard on function blocks has not been implemented in products, yet. The ideas, however, are beginning to find their way into existing products a little at a time. Both Mr. Lewis and Ken Hall, Rockwell Automation (Mayfield Heights, OH) vp of architecture for advanced technology, confirm that Rockwell has implemented many of these function blocks in Java for testing and development.

Mr. Hall adds, ‘There is still some work to do on the 61499 standard. For instance, the footprint is still too large to be embedded in smaller devices. Of course, as microcontrollers add 32-bit engines like MIPS and ARM that are more powerful, the curves of footprint to power will cross soon. I expect to see 61499 appear first on intelligent output devices like actuators, clamps, slides, etcetera, on DeviceNet. It will gradually grow from there.’

Customer requirements for standardization are driving the movement toward components, according to Rockwell Automation Logix business manager, Tim Reckinger. ‘This is especially true,’ he says, ‘for large, global OEMs who need to reuse PLC objects. We’re testing 61499 objects within Logix engines, now. It may enable us to meet the ‘zero cabinets’ philosophy of many of our customers.’

‘Modelling control systems using IEC 61499: Applying function blocks to distributed systems’ by Robert Lewis, published by The Institution of Electrical Engineers (London, U.K.), explains that function blocks are an established concept in automation for defining robust, reusable software components. They allow algorithms to be encapsulated in a form that can be readily understood and applied by people who are not software specialists. IEC 61499 expands upon the work of IEC 61131, which defines four languages for programming industrial control (ladder diagram, function block diagram, structured text, and instruction list), plus a program organizing method called sequential function charts.

IEC 61499 function blocks provide for data and event inputs and outputs. For example, data may come into a block, say for example, readings from an analog device. Then, an event input arrives at the function block. Depending upon the scheduler timing, the block will begin to process the information with its internal methods (algorithms), such as a PID calculation. When the method is finished, it will set an event output and send new data to the data output.

Each function block type has a type name and an instance name. A type name could be ‘PID,’ while an instance of ‘PID’ could be ‘Loop 1.’

Multiple function blocks are connected in a system to complete an application. Function blocks under this standard may be implemented under any textual language. Examples in the book are done in Structured Text from IEC 61131, but companies can implement in Java, C, etc.

Meanwhile, an IEC committee is working on a function-block standard specifically for the process control industry. IEC 61804 builds on the IEC 61499 standard, as well as FOUNDATION fieldbus, ProfibusPA, and HART standards.

Terry Blevins, Emerson Process Management (Austin, TX) principal technologist and member of both standards working groups, notes, ‘The Electronic Device Description (EDD) defined by the standard for describing fieldbus devices is a superset of the FOUNDATION fieldbus DD language, the ProfibusPA EDDL, and HART DD. Thus, this standard is of real interest to the process industry, system suppliers, and fieldbus device manufacturers.’

The IEC 61804 function block defines process flow inputs and outputs with encapsulated algorithms (methods) and a set of parameters. It further defines three types of blocks. Technology Blocks represent the process attachment of a device (sensor or actuator). It contains the measurement of actuation principles of a device. Application Function Blocks contain application-related signal processing, such as scaling, alarm detection or control, and calculation. Device Blocks represent the resource of the device, which contains information and functions about the device itself, the operation system of the device, and the device hardware.

Mr. Blevins points to two systems that use the IEC 61804 specification to build consistent function blocks and allow proxy blocks for devices not yet within the specification: DeltaV system from Emerson Process Management (location), which uses FOUNDATION fieldbus function blocks, and PCS7 from Siemens Energy & Automation (Alpharetta, GA), which uses Profibus for networking.

Siemens E&A is also working with other members of Profibus International to develop a comprehensive component-based system under the umbrella of Profinet.

Egon Hillermann, Siemens’ global controller marketing manager, states, ‘The availability of a standard for technological modules with complete functionality consisting of the mechanical and electrical devices and associated control program would allow OEMs to focus more of their resources on adding value to machines without worrying too much about final integration issues. Profinet uses modern software component technology for specification of and communication between components.’

Within Siemens’ Step 7 programming editor is a ‘Generate Profinet Component’ function. It generates an XML (eXtensible Markup Language) that describes the components and associated data storage. A higher-level engineering tool, Simatic iMap, enables graphical creation of the communication relationships. Profinet uses Ethernet accessing other networks like Profibus through proxy. It is based on COM and DCOM at this time.

Object benefits

Benson Hougland, director of technical marketing for Opto 22 (Temecula, CA), reports a recently released software object from engineering-services company and Opto 22 solutions partner Turbocraft (Tukwila, WA) that is a good example of benefits accruing from an object-oriented software philosophy. Turbocraft has developed PID_Control Installer that installs a complete Factory Floor project for PID control. It includes a display interface that offers trending.

Sometimes a company can provide a complete software platform for project development. RTI (Real-Time Innovations, Sunnyvale, CA) has released Constellation, a commercial, off-the-shelf platform specifically for the design of unmanned systems. It enables building a control system using UML, porting to SimuLink from The MathWorks for simulation testing models, then generating working code.

Although primary discussion has covered programming for control, objects have been widely used in HMI development for some time.

Roy Kok, Intellution’s (unit of Emerson Process Management, Foxborough, MA) director of HMI/SCADA product marketing, notes, ‘Intellution’s FIX and iFix products have treated the plant floor as objects for program development for years. The idea is to create a process database of objects. We allow creation of these objects on the fly. For instance, if it is necessary to change an RTU, there is a driver that monitors the system, senses changes, and builds new objects.

Wonderware’s Mr. Tock says that the company’s new ArchestrA framework answers the question of how to represent and model a plant. ‘The concept behind objects is that you put all relevant information together. On the screen, there are tabs for description, security levels, etc.,’ he continues. ‘You can then move it, create instances, or replicate it. It even enables better version control.’

Mark Davidson, Wonderware vp of ArchestrA marketing, adds, ‘Customers are looking for plantlevel application modeling capability that can put all the disparate things into context. They want to be able to do this without changing the entire control structure of the plant. ArchestrA will enable this.

Rich Carpenter, CPM business leader at GE Fanuc Automation (Charlottesville, VA), reveals, ‘GE Fanuc has pursued component-based implementation at two levels. First, we use an object model to store captured user configuration and runtime data that are exposed through a component model. This allows information on any component to be discovered and manipulated by other applications within the system. Second, Cimplicity allows user-defined components to be created, classed, and instantiated. At the supervisory level, all components associated with a type of equipment can be combined into a higher level component describing its overall properties.’

Components already exist to help make life a little easier for control engineers. However, look for increasing developments to make modeling and control of automation systems easier and better.

Comments: E-mail gmintchell@reedbusiness.com

Here’s a function block example

This PID_Simple function block type is defined as a basic function block and is specified in terms of an execution control chart (ECC) and algorithms written in IEC 61131-3 high-level language Structured Text, as adapted from Modelling control systems using IEC 61499 by Robert Lewis, published by The Institution of Electrical Engineers (London, U.K.).

The ECC shows two states ‘INIT’ and ‘PID_RUN’ that exist when this block receives ‘INIT’ and ‘RUN’ events respectively. The initialization algorithm ‘ALG_INIT’ runs when the ‘RUN_PID’ state is active; likewise, the PID algorithm ‘ALG_PID’ runs when the ‘RUN_PID’ state is active. When either algorithm has completed, the ECC always returns to the initial ‘START’ state.

FUNCTION_BLOCK PID_SIMPLEEVENT_INPUT

END_EVENT

EVENT_OUTPUT

END_EVENT

VAR_INPUT

END_VAR

VAR_OUTPUT

END_VAR

ALGORITHM ALG_INIT IN ST:… (*Initialize PID variables*)END_ALGORITHMALGORITHM ALG_PID IN ST:… (* Code for the PID_Simple algorithm*)END_ALGORITHMEND_FUNCTION_BLOCK

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our CFE Media editorial team and getting the recognition you and your company deserve. Click here to start this process.