[MAT-devel] Re: RTOSes, PLCs and control

R

Thread Starter

Robert Schwebel

Peter,

Peter Wurmsdobler wrote:
> Just a thought: you have a protocoll between all your clients and
> servers, very sophisticated if I remember correctly. And I guess, it
> does everything what OPC does, too, or even more. Could your protocoll
> be some basis or even THE open control process protocoll, called OCP ?
> What would be necessary to do this? First, maybe make it open source,
> second put it on an open discussion platform for control systems?

do you know ACPLT, the "Aachener Prozessleitsystem"? It is some kind of a
middleware for process controll stuff. You'll find the homepage on

http://acplt.plt.rwth-aachen.de/welcome.html

and I assume Harald Albrecht will be very willing to answer all your questions here on this list... :)

Robert
--=20
+--------------------------------------------------------+
| Dipl.-Ing. Robert Schwebel |
| Linux Solutions for Science and Industry |
| Braunschweiger Stra=DFe 79, 31134 Hildesheim, Germany |
| Phone: +49-5121-28619-0 Fax: +49-5121-28619-4 |
+--------------------------------------------------------+


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
P

Peter Wurmsdobler

Chiron et aliis,

> philosophy is "control on Linux, pretty pictures on Windows". He's got no
> particular interest in OPC, no interest in pulling process data into
> Access with ODBC, etc... he just wants easy-to-build, easy-to-use screens
> for his operators, and he's settled on WonderWare as his tool of choice.

So you have established communication between WonderWare and PuffinPLC? Did you write and interface for Wonderware?

Just a thought: you have a protocoll between all your clients and servers, very sophisticated if I remember correctly. And I guess, it does everything what OPC does, too, or even more. Could your protocoll be some basis or even THE open control process protocoll, called OCP? What would be necessary to do this? First, maybe make it open source, second put it on an open discussion platform for control systems?

Once such a protocoll is established, all suppliers, system integrators or other control entities can use it, suggest add-ons, etc. It would be open. Those who want to connect to OPC, have to write a Windows driver running on the Windows host with two interfaces: OPC and OCP.

peter
--
Peter Wurmsdobler
Control.com Inc.
508-621-3611 fon
508-621-3614 fax

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

There seems to be a lot of Linux control development going on in that part of the world. It would be great if there was a site that listed
the interesting projects in English. My grade school German is not up to the challange. Does such a site exist? Are there many Open Source projects? I've looked at VisiPro and AutomationX, but I haven't seen much in the way of Open Source.

Regards

cww


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
H

Harald Albrecht

Curt Wuollet wrote:

> There seems to be a lot of Linux control development going on in that
> part of the world. It would be great if there was a site that listed
> the interesting projects in English. My grade school German is not
> up to the challange. Does such a site exist? Are there many Open
> Source projects? I've looked at VisiPro and AutomationX, but I haven't
> seen much in the way of Open Source.


Depends on the particular area/domain in Industrial Automation you are looking at. There was a funny panel discussion at Interkama Fair about Open Source in Industrial Automation (albeit not a big one). Participants were Dr Niemann from ABB, Dr Hähniche from Endress+Hauser, and Prof. Epple (my boss). The Moderator was Prof. Steussloff from Fraunhofer IITB. While Dr Niemann could not find anything appealing in Open Source when applied to Industrial Automation, Dr Hähniche and Prof.
Epple had a different view -- although expressed in varying shades.
Regarding code and security quality problems they both opted for Open Source to improve quality and time to market for new standards. Dr Niemann did not agree at all. He even mentioned FDT/DTM (Field Device Tool, Device Type Manager) as a working example without the need for Open Source (fyi: FDT/DTM is based on COM). His view was not exactly shared by both other participants.

On the other hand, looking back at GMA Congress earlier this year, particpants from ABB research center in Switzerland had a totally different view on Open Source and regarded it as the solution for improving code quality and time to market. They had a nice discussion with their German collegues from the other side. Plurality@work(tm) -- or to stay in proper marketing speech, "Pluralize IT".

When looking at Industrial Automation especially for Process Industries it seems to be a long way to go before we get a decent culture in the
industrial community -- but maybe we need even a civilization first... Surely quite some people don't intend to stroll at all.

But there's still hope, especially regarding embedded Linux development. Robert can surely tell more details about the current situation in
Germany and the area around Hannover/Braunschweig.

Just my E.02

Harald

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

Thanks Rick

But how would I know about the other projects?

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.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Peter:
> Could your protocoll be some basis or even THE open control process
> protocoll, called OCP ?
...
> Those who want to connect to OPC, have to write a Windows driver running
> on the Windows host with two interfaces: OPC and OCP.

Please, do not have two protocols with the names OPC and OCP. That'd be just too terrible.


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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
> I've looked at VisiPro and AutomationX

For automationX it was a lot of work to convert the German to English and we did most of it here in our office, over the years. First an automated rough translation, then some work by English speaking German Tech writers and then finally by us to Americanize the wording. We've done the software itself, the classes and online documentation, Demo CD, System and User's manuals,
and marketing material. It was quite an effort, not really fun work either.

On our website we have an Online Web Client DEMO working. It uses a Canadian Product by Hummingbird to extend a browser's functionality to full X Windows. This means automationX works with wafer thin clients.
www.mnrcan.com and select the web demo link.

Also we have a system on Ebay right now you can purchase:

http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=1646623190
Vielen Dank!

Paul Jager
www.mnrcan.com

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
R

Robert Schwebel

Hello Curt,

On Mon, 8 Oct 2001, Curt Wuollet wrote:
> It would be great if there was a site that listed the interesting
> projects in English.

Well, I've done that:

http://www.linux-automation.com/index_en.html

:)

Feel free to send me more links if you have some.

Robert
--
+--------------------------------------------------------+
| Dipl.-Ing. Robert Schwebel |
| Linux Solutions for Science and Industry |
| Braunschweiger Straße 79, 31134 Hildesheim, Germany |
| Phone: +49-5121-28619-0 Fax: +49-5121-28619-4 |
+--------------------------------------------------------+


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
Excellent!

I hope we can promote more cooperation.

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.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
P

Peter Wurmsdobler

Jiri,

> Please, do not have two protocols with the names OPC and OCP. That'd be
> just too terrible.

You are right, it was rather for fun. The message is: Would it be possible to establish an "open" protocoll which is not based on proprietary technology, but on open one which is for me POSIX,
TCP/IP and maybe other ones.

peter
--
Peter Wurmsdobler
Control.com Inc.
508-621-3611 fon
508-621-3614 fax

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
R

Robert Schwebel

On Thu, 11 Oct 2001, Peter Wurmsdobler wrote:
> The message is: Would it be possible to establish an "open" protocoll
> which is not based on proprietary technology, but on open one which is
> for me POSIX, TCP/IP and maybe other ones.

Do you know details of what the IDA / IAONA organisations are doing? There are plans to develop an application layer protocol for automation.

On the other hand, does anybody have experience with OPC/XML? I'm no expert in this field, but as far as I know the problem with proprietarism
of OPC is that it's based on DCOM. But there also seems to be a variant out there which is based on XML. Perhaps this might be worth further
investigation. IMHO, the last thing the world needs is yet another protocol, how open it ever might be.

Robert
--
+--------------------------------------------------------+
| Dipl.-Ing. Robert Schwebel |
| Linux Solutions for Science and Industry |
| Braunschweiger Straße 79, 31134 Hildesheim, Germany |
| Phone: +49-5121-28619-0 Fax: +49-5121-28619-4 |
+--------------------------------------------------------+

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
H

Harald Albrecht

Hi Robert,

(come to terms with Interkama, eh?!)

Robert Schwebel wrote:

> On Thu, 11 Oct 2001, Peter Wurmsdobler wrote:
>
>> The message is: Would it be possible to establish an "open"
>> protocoll which is not based on proprietary technology, but on
>> open one which is for me POSIX, TCP/IP and maybe other ones.
>>
>
> Do you know details of what the IDA / IAONA organisations are doing?
> There are plans to develop an application layer protocol for
> automation.

On the danger of getting dressed-down for my views I would like to help with some information...

There's a quite comprehensive white paper available from IDA's web site which appeared first at HMI 2001. It is also available in printed form. Unfortunately I havn't had yet time to read it, but it contains more details than the usual whitepapers.

From what I remember the IDA object model bases on COM. For real-time communication of process values they provide local COM interfaces and
make use of Real-Time Innovations' (RTI) proprietary Real-Time Publisher-Subscriber protocol RTPS. RTI is a spin-off from Stanford
University. So far I do not know whether RTI holds any patents on its RTPS -- RTI representatives could not answer this question when I asked them after their presentation at the Ethernet TCP/IP in Automation workshop in July.

It is somehow puzzling that IDA got granted a deployment license from RTI (or needed to do so). So if someone implements IDA from scratch he is probably without a license to use RTI. When asked by other participants of the workshop, the RTI representatives did not answer this question. Curt, this should probably please you ;)

> On the other hand, does anybody have experience with OPC/XML? I'm no
expert
> in this field, but as far as I know the problem with proprietarism of
OPC is that it's based on DCOM. But there also seems to be a
> variant out there which is based on XML. Perhaps this might be worth
> further investigation. IMHO, the last thing the world needs is yet
> another protocol, how open it ever might be.

There are two things to clearly separate -- well, actually quite some more.

Let's start with DCOM: Microsoft so far never mentioned DCOM and XML together, so the future of DCOM is unclear. In my very personal view,
probably a legacy protocol for application integration within the Microsoft hegenomy.

Then there's COM. It will stay, as it is Microsoft's component infrastructure within a Windows machine. There is no good reason why COM
should be dropped for local deployment within a Windows machine.

Then there's .NET. As far as I understand it, it consists of many vapor and some clear parts. There's a common runtime and a set of .NET
libraries, much in the spirit of the Java bytecode, VM, and set of libraries. The libraries effectively provide many, many .COM interfaces
for all things within .NET -- like GUI, XML parser, et cetera.

One important part of the .NET is their XML parser (and more) integration: when type information about COM interfaces is available,
the runtime environment is able to automatically marshall .COM calls forth and back to XML protocols.

Now SOAP comes into play. Despite its name "Simple Object Access Protocol" it is not a DCOM protocol replacesment. Neither it is an RPC
protocol. First, SOAP is just a messaging protocol which describes how arbitrary XML messages are wrapped into a XML envelope. Then it
describes which information about the destination and the way to it can be scribbled on the envelope, so arbitrary environments are able to
process SOAP messages -- note that they do not need to understand the message's contents. The RPC part of SOAP finally builds on top of SOAP
messages and states that there are SOAP RPC call messages, which are accompanied by SOAP RPC reply messages.

SOAP does not talk about whether multiple SOAP RPC messages can be send to the same destination at the same time, et cetera, so it does not talk
about environment (implementation) details. That's up to the particular implementation, like for instance with .NET.

So far it is unclear to me how deep .NET induces proprietary interaction and semantics dependencies on the otherwise independent SOAP.

The OPC people from their booth at Interkama told me that there will probably a .NET-based implementation of XML-based OPC-DA. For ISA Expo
in Houston the OPC Foundation announced a .NET-based demo too. The openness will depend on the degree of entanglement with .NET. If they just use .NET to get a kick-start with XML parsers and DTDs, then this could be okay as long as they avoid any .NET proprietary XML protocols.

However, it has still to be seen whether OPC's functionality is appropriate for the desired tasks. Event driven notification of process
value might seem important for signal-oriented applications. But signal-orientation isn't the whole story. There's information behind the
signal-oriented curtain. Especially OPC's ability to represent diverse plant information models is below par (now let's see how this comes out
after machine translation ;) ).

As an afterthought: XML-based OPC still does not solve the problem having a heterogeneous environment on the field level with diverse PLCs
and DCSs. But to cite a visitor from a large automation company at our booth at Interkama: "Your work is completely unnecessary. Customers don't have heterogeneous systems, they only have one system all in their plants". Later he added: "That's why customers buy their complete automation from us, so they all get it from the same company." Right, five years ago customers struggled and quarrelled with five different vendors and customizers, each one passing the buck of responsibility to the other partners. Now, customers struggle and quarrel with five different departments from the same company, each one passing the buck. Thanks to SAP you can now clearly see where your money was lost, but that does not help you as a customer in any way. Big deal.

But then, I'm just again an uninteresting voice in the wilderness. So I'm strolling back, hiding behind my little cactus.

--
Harald Albrecht
Chair of Process Control Engineering
RWTH Aachen University of Technology
Turmstrasse 46, D-52064 Aachen, Germany
Tel.: +49 241 80-7703, Fax: +49 241 8888-238

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
P

Peter Wurmsdobler

Scott,

From what I understand, the new standard is a xml wrapper, but underneath you have still DCOM. So you translate binary data into XML, then xml to binary (DCOM is binary I guess), transfer DCOM over the net, make it xml, and extract your information. A lot of overhead. Maybe the DCOM interface can be replaced by other technologies.

peter
--
Peter Wurmsdobler
Control.com Inc.
508-621-3611 fon
508-621-3614 fax

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top