R
......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.
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.