I was wrong - was Communications Protocols

R

Thread Starter

roger Irwin

......And OPC are right, and I must eat humble pie.

Well, perhaps just a little bit!

I remain unwavered in my opinion that defining COM wrappers for a non-descript connection to the field is a very limited and non universal scope that leads to ridiculous comprimises. I also remain unwavered in my position that DCOM, SOAP (and CORBA and anything alse that aims to satisfy IT client/server scenarios) is the wrong type of architecture for IA/SCADA because we have many
sources and few clients, the reverse of what is conventional.

But OPC say they are looking to XML for connection to field devices, and they could have a good point there.

I said that XML does not actually define a protocol, which is true, but of course it uses a simple TCP/IP protocol transport, which I think we all agree is correct. For the rest it is up to us to define what goes into an XML specification (or dictionary).

XML offers the scope of a universal language that decribes the parameters of PLC's, drives, positioners, and everthing else we have to deal with, and gives the possibility of an interface that could be both machine readable and directly human readable without special drivers or code.

BUT, I have some serious reservations:

Firstly, I do not understand how asynchronous event signaling would work under XML. OK, I am pretty ignorant on XML having never used it, but I have been discussing it with someone local who
is developing XML based solutions for comerce applications. Can anybody enlighten me on what current proposals are? I would hate to think we must continuously poll all field units.

Secondly, IMHO, the dictionaries must be very simple. IA and SCADA field devices are much smaller than typical desktop PC's, which is desirable, and the dictionaries must reflect this fact. Our applications do not actually require much sophistication, once again, KISS is a keyword. I would like to think that a standardised
interface to, say, a PLC, could be implemented by a process engineer if necessary.

Thirdly, and most importantly, how do the standards get defined. If we say 'lets define a COM object in XML' we are going about the thing in the wrong way. We should design an XML schema that meets IA and SCADA requirements and THEN think about making OS/application specific wrappers for it. IF OPC track record is anything to go by, they will let Microsoft say what they think and then all agree that it is a pretty good idea.

The logical 'source'for an XML based standard would be the XML organistation, http://www.xml.org . Visiting their site one finds a long catalog of standards groups from all sectors from Insurance through to music, who are working together to harmonise their respective XML requirements. The industrial automation section is miserably represented, musicians seem better off than we are!

There are only two entries, one is for a commercial site whose web page simply describes them as a company that will connect anything to the web, pity they cannot get the website working
properly.

The second entry is more interesting, it is an organisation called MIMOSA, http://www.mimosa.org . I had never heard of them (they have certainly not been nominated in all the protocol dicussions of late on the Automation List). Apparently they are standardising XML interfaces to machinery; corporate sponsors include SIEMENS and ROCKWELL automation, but as I have said before, big corporations tend to get involved with all standards groups. A PDF file has a letter from the president that laments the fact that take up of XML in automation has been slower than expected. Well if nobody knows what they are up to......

Noticeable by their absence was OPC. Presumably they intend to form XML standards behind closed doors whilst completely ignoring XML org and all the other standards groups from other sectors.

XML is very much in formation. Now is the time for people to get their heads together and although it may be egoistic to assume that everybody will adopt it universally, at least try and make such that it can actually satisfies everybodies requirements and is capable of doing what people need to do.

Surely OPC should get in touch with XML, and in turn with MIMOSA. They should also be working with the people who designed the Open PLC standards (perhaps they already are). They should also discuss their ideas on lists such as this and be prepared to accept feedback.

Then again, perhaps XML is not really suitable after all. Any which way I propose a good discussion on the application of XML on this
list, not in a standards group commitee, they exclude too many opinions.

Also, if OPC intend to simply concentrate on making an XML standard that is simply for transporting MS COM objects, then perhaps it would be the case to look towards other standards
groups to form the protocol (MIMOSA perhaps), and just leave OPC to stick MS app wrappers on it.

Anybody know anything more about MIMOSA? What about other people who are looking to use XML in IA/SCADA?

Or perhaps MODBUS/IP (or even my KISS;-) ) is a better solution.
 
G

Greg Goodman

> I said that XML does not actually define a protocol, which is true, but of course it uses a simple TCP/IP protocol transport, which I think we all agree is correct.

not my intent to pick nits, but we should be clear on what XML is and is not.

XML is a markup language. it's not a protocol, and it doesn't specify its transport. one of the XML design goals was that

1. XML shall be straightforwardly usable over the Internet

XML documents are commonly transported over TCP/IP, but the XML specification says nothing about how an XML document gets from one place to another.

all XML does is provide a standard format for the content of communications. and not a particularly optimal format, either. two more of the documented design goals for XML are

6.XML documents should be human-legible and reasonably clear.

10.Terseness in XML markup is of minimal importance.

meaning that any SCADA date interchange based on XML is guaranteed to be bulkier - and therefore slower to transport and process - than a purpose-built protocol designed with size/speed as considerations.

i personally don't have any problem supporting any protocol in a SCADA system that a client wants supported. but i don't really expect the entire SCADA community (or even a really big chunk of it) to get behind device i/o rendered as human-readable marked-up text documents.

greg goodman
chiron consulting

note: the numbered XML design goals were taken from section 1.1 of the XML 1.0 Working Draft,
http://www.w3.org/TR/2000/WD-xml-2e-20000814.html
 
M

Michael Griffin

At 16:36 15/08/00 -0400, roger Irwin wrote: (regarding XML)
<clip>
>The second entry is more interesting, it is an organisation called
>MIMOSA, http://www.mimosa.org . I had never heard of them (they
>have certainly not been nominated in all the protocol dicussions of
>late on the Automation List). Apparently they are standardising
>XML interfaces to machinery; corporate sponsors include
>SIEMENS and ROCKWELL automation, but as I have said before,
>big corporations tend to get involved with all standards groups. A
>PDF file has a letter from the president that laments the fact that
>take up of XML in automation has been slower than expected. Well
>if nobody knows what they are up to......

It looks to me as if MIMOSA is defining standards for monitoring the health of machinery. They are interested in bearing temperatures, vibration, lubricating oil condition, etc. I suspect that this is intended for applications such as generating plants and other facilities which have large machines which are instrumented for such purposes. Most people don't bother,
so this is a rather specialised area. If you *do* need to do things such as this though, it is no doubt very handy to have a standardised way of getting these data.

In general, we would need other committees to address various industrial automation subject areas. Each industry and subject area needs a committee. The real benefit of XML will come when I can buy 2 lathes from 2
different companies with 2 different controllers and extract the same information from them in the same way.
For some reason though, I expect the real result is going to be chaos, not order. The robot people are going to have data which overlaps with the machine tool people but this data will be defined differently and the two committees won't even be talking to each other.


>Noticeable by their abscence was OPC. Presumably they intend to
>form XML standards behind closed doors whilst completely ignoring
>XML org and all the other standards groups from other sectors.
<clip>

I'm not sure what OPC would have to do with this. They have no expertise to contribute to the monitoring of bearing temperatures. What they can do is define the OPC API calls to use to make an XML data request to an OPC server. The actual XML could originate in the application program or in the OPC server and should be identical regardless of whether an OPC server
is involved or not.
The overwhelming majority of devices involved with this system will not have OPC servers or Windows inside them.


>Also, if OPC intend to simply concentrate on making an XML
>standard that is simply for transporting MS COM objects, then
>perhaps it would be the case to look towards other standards
>groups to form the protocol (MIMOSA perhaps), and just leave
>OPC to stick MS app wrappers on it.
<clip>

I'm not sure what I would do with an XML standard that "transported MS COM objects". Perhaps this would be of use to someone, but I can't imagine what I would do with it.


**********************
Michael Griffin
London, Ont. Canada
[email protected]
**********************
 
Top