XML in PLCs

J

Thread Starter

James

What does everyone think about XML and PLCs. Is this the start of a brave new world of interoperability that we have waiting for?

I have seen a lot of talk about XML and the benefits it could have. Certainly OPC has been a major step forward. How does OPC XML work and why not just XML?

Will the hardware guys be falling over themselves to include this in their new developments?

Or shall we all just sit back and have a nice cup of tea?

Comments welcomed.

James
 
A

Alex Pavloff

We'll all sit here and watch as XML gets added as a buzzword to the high end PLCs. XML parsing is non-trivial. Its easy to do on a PC or server with a real disk and a real amount of memory, but even the smallest XML parsers require a meg or more of RAM and disk space. We may also get some "XML-lite" implementations done on other PLCs, which will then be trumpeted to the world. Also, we'll see people make money off of writing XML translators in software or hardware that can take data from a PLC and make it XML! What fun!

But really, XML only gives you a way to easily structure data. You then have to drag manufacturers to the table and get them to agree on an XML schema and maybe a way to transfer these XML documents around.

On top of that, I'm hard pressed to come up additional benefits by pushing XML around. OPC made is possible so that any device with an OPC server could talk to any software with an OPC client. What benefits will XML give? I'm talking concrete benefits here, not marketing speak.

Alex Pavloff - [email protected] ESA Technology ---- www.esatechnology.com
------- Linux-based industrial HMI ------
-------- www.esatechnology.com/5k -------
 
J

Joe Jansen/TECH/HQ/KEMET/US

Why would XML provide a new level of interoperability? Just because you are able to send ascii data with lots of additional overhead? XML provides the ability to interoperate, it in no way mandates it. RS-232 gives you the same ability, and that sure didn't work....

XML doesn't belong in PLC's. Which means everyone should have it shoved in there for their next release. I can't understand why it would be better to bloat up your communication packets with all the additional overhead, when you can get the same data, through the same pipe, a lot faster using something different.

Once you are on the PC, XML is as good as anything else, I guess. I don't see anything that would make me get too excited, but it is another file format to store data in. ho hum. Whether any of the manufacturers support XML tags from any of their competitors should not be a difficult guess to make. Look how well they have all played together so far.....

--Joe Jansen

ICQ# 39 182 450
 
J
XML is a standard that just begs for more standardization. On its own XML really does not say much, it's just a platform. Vendors need to agree on XML schemas so that data can easily be passed from one application to another without mapping tags from one to tags in the other. Without additional standardization you don't get plug and play interoperability.

You need OPC-XML because it gives you the benefits of OPC over XML instead of DCOM. Just "plain" XML gets you nowhere.

XML is very inefficient as compared to binary communication such as DCOM. DCOM is not firewall friendly, but XML is. Therefore DCOM will still be used within the control system. OPC-XML will be used for linking to the MES and ERP levels of the enterprise.

Jonas Berge SMAR
==================
[email protected]
www.smar.com
 
James:

On September 4, 2003, James wrote:
> What does everyone think about XML and PLCs. Is this the start of a
> brave new world of interoperability that we have waiting for?

XML can be used for interoperability, or not. It's certainly designed to make interoperability easier if it's wanted, but if it's not wanted, XML won't be an obstacle. Just make an XML file that says "this is a piece of proprietary-format data" and then includes it verbatim; or make the DTD available under NDA only.

> I have seen a lot of talk about XML and the benefits it could have.
> Certainly OPC has been a major step forward. How does OPC XML work and
> why not just XML?

Well, XML itself is a wide class of formats - you still have to decide what the tags will be and what they will mean (DTD); and who will send what to whom when (the protocol).

> Or shall we all just sit back and have a nice cup of tea?

That's always a good idea :)

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

Lynn at Alist

Don't expect XML in most PLC - the information content to too low per byte. This means it takes 100 or even 1000 times MORE bytes to say the same thing as a binary protocol like Modbus or Ethernet/IP. Plus XML forces the PLC to convert binary values (ints, floats, etc) to/from ASCII strings - to things like 000023.45677. This is very inefficent and you'd end up needing to add an extra high-end CPU just to handle the added overhead of all this ASCII string conversion. This means the field device would need a list price $50-250 higher than a model without XML.

Yes, a niche market will evolve with XML at the end device. But a vast majority of users will stick to faster binary protocols in the field and do any XML work they need at the enterprise level (ie: server to server) and not at the controller level.

Plus XML isn't magic - you'll still need to know how to map a tag like <TEMP234.SETPT> to another vendors <DATAPOINT tag="TEMP234" attrib="set_point">. XML is just a format, not a "protocol". It won't make comms free & easy - you still need to pay XML experts to customize things. But you CAN customize things - that's why the enterprise people are so happy. No magic, but it can be MADE to work somehow. That's the XML value.

- LynnL, www.digi.com
 
M

Michael Griffin

One application I have been able to think of is exchanging information with business systems. Some OEM machines have web interfaces to allow users to view current status and production data. Some PLC manufacturers offer webserver modules which plug into the PLC rack. Adding XML to these systems to allow computer systems to automatically read this data and act upon it seems like an obvious thing to do.

XML has advantages over OPC in that it concentrates on what the data means rather than on where it happens to be stored in PLC memory. The translation from the machine specific format (memory address) to the functional format (what the data means) can take place close to the machine. People designing or modifying a machine can deal with it locally without having to coordinate their design with all the various computer systems that want to use the data. Managability becomes a very important issue when you have to connect things on a plant wide or company wide basis as opposed to worrying about communicating only within a single machine.

This doesn't necessarily mean XML in every PLC CPU. There could be local gateways which provide this translation service for an entire work cell. It also doesn't mean using XML for all types of communications. However, in future as microprocessors become more powerful and as TCP/IP networking becomes more common, the reasons for not incorporating this function into PLCs become less convincing.

--

************************
Michael Griffin
London, Ont. Canada
************************
 
On September 6, 2003, Alex Pavloff wrote:
> We'll all sit here and watch as XML gets added as a buzzword to the
> high end PLCs. <

:)

> On top of that, I'm hard pressed to come up additional benefits by
> pushing XML around. OPC made is possible so that any device with an
> OPC server could talk to any software with an OPC client. What
> benefits will XML give? I'm talking concrete benefits here, not
> marketing speak. <

Civilization advances by extending the number of important
operations which we can perform without thinking of them.
-- Alfred North Whitehead

XML gives us a way of transferring/storing hierarchical data "without thinking about it".

This is useful in cases where we have hierarchical data, which in PLCs we usually don't - except for things like (structured) programs. Doing at least some operations on programs in XML will probably be handy. For flat data, XML is excessive - but as computers progress, the overhead will be increasingly negligible. Already on desktop machines it's OK.

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

Curt Wuollet

I find that a very pessimistic view of what will be running on the enterprise servers. It's not even a good assumption now, and it's becoming less valid every day. Once MS no longer controls the market, I'm certain much more attractive methods will surface.

Regards

cww
 
R

Ralph Mackiewicz

> What does everyone think about XML and PLCs. Is this the start of a
> brave new world of interoperability that we have waiting for?
>
...snip...snip...
>
> Will the hardware guys be falling over themselves to include this in
> their new developments?

You may be interested to know that XML is being used in the IEC61850
specification for substation automation networks to described device
configurations. This feature is called the Substation Configuration
Language (SCL) and is covered in IEC61850-6-1. SCL uses XML to
describe the objects defined in a device. There are tools being
developed that will enable a user to configure the objects to be
supported in a device. The tool will generate SCL which will then be
fed to the device to configure it. An SCL file for one device could
be fed into another, even from another manufacturer, to duplicate
configurations.

XML does have effeciency issues as a data exchange protocol for
time-critical applications as was described in other posts. However,
the exchange of configuration information is an application where
these byte count issues are mostly irrelevant. XML would make an
excellent basis for a standard to describe I/O configurations,
register naming, and other configuration issues. Combined with
modeling standards like ISA S.95, IEC61970, etc. XML messaging is a
powerfully effective way of implementing application integration.
Its called model driven integration ( http://www.omg.org/mda ) and
XML plays an important part in this. Eventually, as
computing/networking capabilities increase and computing/networking
costs decrease the byte count issue will become more an more
irrelevant even for time critical applications. But we are not there
yet for a PLC comm interface.

> Or shall we all just sit back and have a nice cup of tea?

I'll take mine with a one lump please. I don't think that most PLC
vendors are highly motivated to develop the standards necessary to
enable interchangeability of configuration information. The reasons
for this can vary from an evil global conspiracy to a lack of
customer interest in such a capability.
 
J

Joe Jansen/TECH/HQ/KEMET/US

The problem, of course, is that having a web server in a PLC is patented <cough>. Therefore, even though this would seem to be a natural progression, it isn't allowed without a license....

--Joe Jansen
 
L

Lynn at Alist

Hear, Hear. I agree 100% with this. I'm working with some poeple to define an XML description for a Modbus slave such that an OPC tool could "import" the entire config & autodefine tags for all registers.

Not only is CONFIG data coded as XML useful, it allows wonderful Revision Control since ALL archiving systems could document that line X changed from "<setpoint>20</setpoint>" to "<setpoint>21</setpoint>".

In contrast, if this was binary info most archiving systems could only say "file changed", but not what changed. And considering the change may be just some "touched on date" field, this makes this notice worthless.

- LynnL, www.digi.com
 
M

Michael Griffin

Web server PLC modules are an off the shelf product from Siemens. You can buy them today. Adding XML capabilities to it (if it doesn't have it already) would be a minor revision. Adding XML is therefore a natural progression to
existing products which are offered for sale today.

A man in Australia has a patent on the wheel. I guess you're not allowed to drive your car to work tomorrow.

--

************************
Michael Griffin
London, Ont. Canada
************************
 
L

Lynn at Alist

Well, yes & no. That patent still has not "won" in court - the first test case dragged on for years, then kind of fizzled in a quiet settlement because 1 side convinced the judge they couldn't afford to fight anymore, not because the other side won. So no legal precidence has been set yet - it was not a loss or win.

Plus the patent isn't on a "PLC" - it's on a "modular controller". Legal teams from other large PLC companies claim their PLC+Web is safe because the web server is running on a coprocessor linked only to the main CPU. The web server doesn't "talk" to any control modules, ergo it isn't PART of a "modular controller" per the patent. It's merely a Web Server showing values read from the CPU's RAM & has no notion of "modular controller". The web server is merely an 'HTTP window' into one CPU's memory.

Personally, I'm still waiting to see if this patent survives or fails a legal challenge. I haven't heard of any new action after the Opto-22 suit fizzled. (Note; this is NOT the same as the OPC-issue!)

- LynnL, www.digi.com
 
C
That is the one bright facet of the Tower of Babel, they can't agree on anything _bad_ either. The unfortunate part is that they all march to the drums of Redmond and that's where some of the more odious ideas have come from as of late. This conformity is truly remarkable when viewed in context. Particularly with the number of hoops they have to jump through as MS careens from one short lived brainstorm to the next. There must be a vast quantity of code that never got released before the wind shifted. We seldom hear of the last 5 "big ideas" before .NET.

Regards

cww
 
C
A relevant link that illustrates my point:

http://www.business.scotsman.com/technology.cfm?id=1014442003

It would be a good idea to start planning for a competitive market rather than assuming the monopoly will prevail. The auto companies are a good indicator and a serious market for our sector all by themselves. Ford is committed, Daimler Chrysler seems like a natural (Linux is doing even better in Germany) and GM will need to be competitive. I wouldn't bet on selling MS only solutions into a Linux or even mixed infrastructure. Their very refusal to work except in an MS only environment will actually accellerate the change. (No pun intended) :^)

Regards

cww
 
C
I find I must apologize, Ford has now refuted that article. I'll bet their pricing on Windows has suddenly improved dramatically :^)

Regards
cww
 
I regard XML as a stop-gap measure popularized as the result of stagnation on the OS front: XML is a file-system, text-blob substitute for a relational database. An SQL conformant RDB could and should be used in place of a file system at the OS level. XML would cease to exist were this the norm.

jk
 
XML is handy because it plays well with the web, which is where its roots are. I use my SCADA software to generate reports in xml which then show up on my internal company website.

XML is handy becuase there are many tools available that understand its structure and can then manipulate and work with that structure.

XML is handly because it is only describes data and its hierachy strucute--no more--no styling or visual layout info, no database to manage.

XML is handly because it is EASILY transformable via XSL into other forms of text-documents, including documents that DO have style and layout information! HTML,SVG,PDF,dBase,anything...

XML is handy because the data is portable (from the perspective that it can be stored in individual files and not stuck in a database.)

XML is handly because it is easily read by human eyes, and can be applied to virturally any type of data storage.

XML is bulky though, and has its place only where it can take significant advantage of the preceeding positives.
 
J

Joe Jansen/TECH/HQ/KEMET/US

XML's place is not on a processor that needs to have millisecond scan rates to control systems. At the very least, a coprocessor should be used to handle communications and, if ever the need should become real, XML formatting. Better still is a PC connected to several PLC's that reads the data from the PLC, plugs all the XML 'fluff' around it, and then passes it around the -business- network in it's bloated, bandwidth consuming state. None of that extra stuff belongs on a network that is busy trying to control machines.

--Joe Jansen
 
Top