Object-Oriented Programming and Other Techniques


Thread Starter

Pires, Claudio

Just would to start a positive discussion about better programming techniques that's seen on IT (Information Technology) projects and not so often on AT (Automation Technology) projects. Are there PLCs that support object-oriented programming? How do we face professional HMI design development? How to we improve automation systems architectures? What are the best software test procedures that fit Automation field? How things are going with higher-level programming languages and the standardization of IEC61131? Where to go on Web-based functionallities? Certainly, many experienced concepts will rise in relation to these questions.

Rockwell is trying to think in this manner after talking with them for three years. Object Oriented methodologies should be based on properties, functions, and methods.

They got lost when I said that the object oriented methodology needs to be vertically integrated from their PLC to HMI and to other software. An object is simply a representation of a real work device. Each system (PLC, HMI, Historian, other) component should support different and interlinked properties, functions, and methods.

There is a lost white paper out there that I authored with another from Rockwell discussing this. We were limited to using their data structure in the PLC (properties) and the associated PLC logic (methods) at the PLC level. Connection to the HMI and historian was labor intensive. The development tools need to enable the OO environment and be OO themselves.

My opinion is that NextStep was there 10-15 years ago and the world did not pay attention. There is now new Three Letter Acronyms (TLAs) for the new technology that is sold but it really is just a re-packaging of the same thing.

Vladimir E. Zyubin

Hello [email protected],

There is a problem of OO-programming. It does not fit control algorithm description task.

The field of OO is the WIMP interface (windows/icon/menus/point devices-"mouses"). And it is the only task OO solves. WIMP is mainstream... so some people do not see other tasks and become to think that OO is Panacea. That is false.

BTW, there is the opinion that all so called OO-patterns
are just patchs to cover up OO-naked... er, places.

Best regards.
= Vladimir E. Zyubin
= Monday, December 05, 2005, 12:03:47 PM =

Curt Wuollet

This would be premised on OOP actually being better programming technique. And that would be strongly dependent on the task at hand. It is rather silly if the structure involves 90% of the code, which would be the case with many automation tasks. In this context, "professional" HMI design is by drag and drop and other
etch-a-sketch type techniques. And as far as I can see, that's the way automation folks want it. They want no part of computer science, and very little of actual programming as we know it. These are what I have gleaned from years of advocating C and other languages and more advanced methods for automation. One of the major objections is that the target would often be more like a PC than a PLC and that well's been poisoned by people's experience with Microsoft
products. They still believe the hardware is unreliable and are in denial on the MS software's suitability for the task. This has produced stagnation where virtually every vendor's products and methods follow the same pattern of logic on PLCs and HMI on Windows. This will end eventually as the big automation vendors break their chains of slavery to the monopoly and fledgling efforts are already in place to exploit the tremendous advantages of reliable alternative software that they can have far more influence in and control over. This will reach a tipping point early since there will be no competing with a reliable OS that is tailored for automation use. The door will then be open for innovation. Stay Tuned and watch Siemens and the other non-US vendors. They should surge ahead after just a short while swimming without the MillStone.



Brian E Boothe

Obvioulsy you're some sort of Ladder Control guy that doesn't understand Conceptual Software Development. You're deaming Object orientation as if it's lesser than a ladder? OO Covers a much broader Range than u think or understand.

Friedrich Haase

Moin Mr. Pires,
moin all,

The IEC 61131 has a very limited amount of OOP. It describes instances (of function blocks) but no classes etc.

OOP usually includes:
- information hiding,
- more then a single method for an object,
- inheritance between classes.

Information hiding is supported by IEC 61131. And a function block is quite similar to a class.

But there is only one method, which then obviously doesn't need a name. You might call it the Operate method. For a few function blocks some other methods could be meaningful. A Reset method could bring an object back into
it's initial state. Think of a simple flip-flop or a complete SFC. And for things like a controller (PID or else) a Design method could be handy. The accepted method for PLCs uses additional inputs for such tasks.

Inheritance is a strange thing in automation control. Rarely useful, so why confuse the users.

If a project really needs OOP, I would use C++ on an embedded controller.

Friedrich Haase

Ing.-Büro Dr. Friedrich Haase
Consulting - Automatisierungstechnik
email [email protected]
WEB http://www.61131.com

Francis Lovering

At least one Control system (call it PLC or DCS) is quite object oriented, namely ABB Sattline. For example, you can create a unit with its graphics and then instantiate it to make as many as you like. But some people get intimidated by it because it is strange to those used to conventional systems. For example there is no such thing as a global tag database.

My understanding is that ABB has adopted much of this in their Industrial IT, but I have no experience of it. You can of course do an object oriented design, even if you have to end up programming it using ladder, and it is beneficial to do so.


Vladimir E. Zyubin

Hello [email protected],

That is obviously to you. Alas, you made a false conclusion. Obviously to me I aware of the IEC 61131-3 standard and clear see both its advatages and disadvantages, and know when it can be used, what language can be used, and can explane why.

Also I do aware of a lot of so called enhancements and extensions of C++ and Java for control algorithms (that look like ettempts to interbreed grass-snake with hedgehog), and I suppose the number is a several times as much than you have ever seen.

So, we may discuss your suggestions which way the industry shell use C++. I promise you will need no explane me what is polymorphism, inheritance, information hidding and any other buzz-words from OO-field (except the cases when you will missuse the terms).

And I ought to confess I have a filling you have never seen any industrial control environment. Sorry.

Best regards.
= Vladimir E. Zyubin
= Thursday, December 08, 2005, 11:52:03 AM =

Pires, Claudio

Dear Mr. Brian Boothe,

I totally agree with you and that's my concern, why automation people do not try to use the best techniques that are well-known in IT developers field, such as object-oriented programming. Of course, it won't fit perfectly, but there are a lot of useful benefits and it does not apply only to HMI design. Looking at some poor PLC user programs, I might think that some programmers still do not know what structured/procedural programming stands for. I wish to hear more from the experienced users. Where the future will lead us in the Automation development field?

Claudio Pires

Michael Griffin

In reply to Claudio Pires - Structured or object oriented programming are not really answers in themselves. There are plenty of structured and object oriented MS-VB spagetti code programs around to prove that.

What will really make a difference is more code re-use, rather than writing each application from scratch. That will be difficult as long as each automation vendor sticks to its own proprietary language dialect and PLC achitecture.

The conclusion reached some years ago in the computer programming world is that there is no "silver bullet" that will solve all problems by itself. There may be incremental improvements in technique such as structured or object oriented programming, but the real gains are made by re-using working code via libraries or even better, entire frameworks.

These libraries and frameworks are possible because the computing market has largely turned away from proprietary languages towards more open ones not tied to particular vendors. The customers can now choose for themselves what they need, rather than have to accept whatever their particular vendor thinks they should have.

This isn't happening in the automation field because the platforms are still very proprietary and the vendors vertically integrated. People will tell you they write programs for particular models of PLC, rather than for particular problem domains. This discourages re-use of code. It is difficult to write non-trivial programs that work with different brands of PLC, or even with two different models from the same vendor. This is much like the mainframe or mini-computer market of the 1960s and 1970s.

If the entrenched PLC vendors continue to control the market, I suspect that the future will look much like the present, but with higher prices. For real change to occur, the PLC as we know it today will need to disappear and control be based on an open soft logic platform.
For the last 13 years the Grafchart Group at the Dept. of Automatic Control, Lund Isntitute has been working on OO programming and 61131. We had one version of Grafchart implemented in G2 by Gensym with inheritance. After this we made a Java version called JGrafchart, which can be downloaded for free from http://www.control.lth.se/~grafchart

There are several publication also available, e.g.,

Karl-Erik Årzén and Charlotta Johnsson: “Object-Oriented SFC and ISA-S88.01 Recipes.” ISA Transactions, 35, pp. 237-244, 1996.

The work on Grafchart has been oriented towards batch control and it has strongly influenced Procedure Function Charts (PFC) in the batch control standard S88.02.