OPC etal. vs CORBA

C

Thread Starter

Curt Wuollet

Hi all,

Someone asked me off list to expound on these two alternatives to help select which would be better for a new project. First of all, I'm not a big OOP fan for systems software. I believe it is wrong to push either too far down into automation software. These should stay on a seperate powerful host that links to the control software with something far more efficient and suited for the task so the actual control software can be that much better in engineering terms. As far as which to use at the proper level, engineering dictates Open and cross platform, only marketing demands you serve the monopoly. It's as simple as that. You have to join the evil empire to play with them. And yes, that's a bad thing.

Regards

cww
--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.
 
J

James Ingraham

>You have to join the evil empire to play with them. And yes, that's a bad thing. <

Not necessarily. You can play with the evil empire by using someone else who was sold their soul. Examples: Wind River now has OPC connectivity for their VxWorks RTOS ( "http://www.windriver.com/products/html/vxopc.html":http://www.windriver.com/products/html/vxopc.html ), and you can get DDE connectivity in the QNX RTOS by using software from Cogent Real-Time Systems ( "http://www.cogent.ca/Software/Connect.html":http://www.cogent.ca/Software/Connect.html ).

The down-side of having a market dominator like Microsoft is you don't get choices. The upside is that everybody knows they have to be able to play nice with the leader. In this case, it means some people have already done the dirty work for you.

-James Ingraham
Sage Automation, Inc.
 
M

Mike Johnson

Curt,
I did not get the full reason why you oppose Object Oriented Programming. Is the problem of inheriting someone else's bugs or you do not the concept of encapsulation, the issue of exposing certain parameters and not others or making your own data types or is the override functioning or what? What is the issue with OOP extended to the
automation world? I am confused?

Mike Johnson
 
C

Curt Wuollet

Hi Mike

Be glad to explain. First, let me say that OOP certainly has it's place, indeed we deal with many things which by nature lend themselves to the approach. Second, I am talking about systems programming, that is, the stuff that directly interacts with hardware and the structure above. Third I mentioned that it shouldn't be pushed too far down. And my objections are far simpler than those that you mention. To do time critical control the software used should be fast, auditable, and of minimal complexity. Until fairly recently, this wasn't an issue, with the fastest processors available, you had to count machine cycles and profile extensively. There is a reason that embedded programmers perform miracles with processors that are not considered powerful enough for a keyboard encoder today. While Moore's Law has removed the need to resort to assembler, for example, that doesn't mean it's a good idea to write an operating or realtime executive system in JAVA to gain OO.
In my view, it means that a good design can do more, faster. As we layer up from that level, less efficient, perhaps more productive
languages and techniques become appropriate. At the far end of the spectrum are some "easy to use" languages whose behaviour and performance
are almost totally unpredictable. In short, I think it's a case where "If all you have is a hammer, everything begins to look like a nail".
In an appliance like a PLC, it's better to do less, faster and more reliably than to embed chunks of very general high level technology.
Control software should have no clouds in the diagram.

Regards

cww

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.
 
V

Vladimir E. Zyubin

Hello Mike,

Encapsulation is an OO jargonism... in order to name the well-known means of fighting against complexity. The means is also known as structuring, modularity, deconstruction, classification, hierarchirization, regulating...

The one OO-attribute is polymorphism (a lot of data types and a few operations). So the main technique of OO is to contruct classes, or in more clear words - to construct abstract data types (N. Wirth)... or just to create user-defined data types (V. Zyubin :) The automation tasks are not polymorphic... vice versa there are a few data types only and a lot of operations.

Best regards. Vladimir.
 
That's not really true - for instance, one could construct objects corresponding to parts of the machine (whether cylinder+limits or a whole machine section); corresponding to pieces of products; etc.

While classes are technically types, it is a mistake to think of them purely in those terms. Their applicability is (intended to be) much wider than that.

Probably the biggest problem would be that in most languages the relations between objects are largely imperative, while automation problems usually aren't.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
V

Vladimir E. Zyubin

Hello Jiri,

On Sunday, June 30, 2002, 4:58:41 PM, Jiri Baum wrote:

JB> Vladimir E. Zyubin:
>> So the main technique of OO is to contruct classes, or in more clear
>> words - to construct abstract data types (N. Wirth)... or just to
>> create user-defined data types (V. Zyubin :) The automation tasks are
>> not polymorphic... vice versa there are a few data types only and a
>> lot of operations.

JB> That's not really true - for instance, one could construct objects
JB> corresponding to parts of the machine (whether cylinder+limits or a
JB> whole machine section); corresponding to pieces of products; etc.

It is an interesting question. The topic leads to discussion about differences between science and technology... discussion about different views on the control systems (user' point of view - HMI,
developer' point of view - algorithm, technician' - mainteinance, electrician', engeneer', etc.)

>From the developer' point of view the system is a set of functions.

The short answer is you can try the approach, but you lose flexibility of the algorithm. Consider a set of valves and tubes with a complex topology. What is the rules to structurize (to construct a
class hierarchy) in OO? Where are the objects? I personally see only functions... as well as the developer. etc.

JB> While classes are technically types, it is a mistake to think of them
JB> purely in those terms. Their applicability is (intended to be) much
JB> wider than that.

For example?

JB> Probably the biggest problem would be that in most languages the
JB> relations between objects are largely imperative, while automation
JB> problems usually aren't.

Yes. Right direction. You dive in the methodology field. :) There are two classes of tasks: science (to research objects created by God)
and technology (to control of the object created by human beings (the artefacts)).

Also the question would be:
Is the OO technique has the limits, is it an "end of programming technique"?

--
Best regards,
Vladimir mailto:[email protected]
 
R

richard higginbotham

Vladimir:

> The short answer is you can try the approach, but you lose flexibility of the algorithm. Consider a set of valves and tubes with a complex topology. What is the rules to structurize (to construct a class hierarchy) in OO? Where are the objects? I personally see only functions... as well as the developer. etc.<

OOP should make perfect sense to anyone involved with processes. We talk about unit operations, we talk about the different pieces that make up a unit (valves, motors, etc.). We collect all these pieces together when we talk about them. We identify them with groups such as "distilation column" or "boiler" which are made up of other smaller pieces. Then we group those together to form a plant. Its done without even needing to think about it. Then we talk about the functionality of the equipment. The chiller feeds the water to the cooling coils. When running the chiller opens these valves and starts those pumps. In python, that would be like:
class Chiller():
def Start():
InletValve.open()
Pump.start()

For a good look at how to partition a control system in a OO way take a look at the structure of a valve in APT. Its a siemens product, originally Texas Instruments, thats been around for a long time. Theres a base class for a valve that other particular types of valves inherit from ( such as a single out put, single feed back valve- VSS). The "complexity" of OO design is shielded from the user by using "Devices" that aren't generally user modifiable. What does a valve do? It generally opens and closes. All that can be incorperated into an object easily enough and it makes perfect sense to say " Open(myvalve) ". All the "functions" that can act upon a valve are associated with the valve "type" or class in this instance. The standard OO methologies and benefits apply even in controls. The only time I've ever seen problems is when the programer didn't understand OOP. *That* is a valid concern, but another topic in itself.

regards,
richard higginbotham
 
Top