Print this article

Comment

1 August 2000

XML Reaches Factory Floor's Automation Islands

This language will impact interoperability so significantly, its use will skyrocket.

By John Bono

Internet-driven communication tentacles, like the next-generation foundation technology called extensible markup language (XML), reach all the way to the factory floor's automation islands.

Driven by e-commerce demands and the unstoppable Internet, vendors develop—literally overnight—next-generation industrialized business software, including its methodologies and best practices. Emerging industrial-automation standards and products embrace this new generation, which you can already see coming, even as users briskly deploy distributed-object platforms and component technologies into factory automation spaces.

XML eliminates the need for programmers to write yet another protocol parser when an off-the-shelf XML parser is used. Schemata written in XML provide the true ability for systems to interact. Those are now being made open and hopefully will standardize quickly.

E-technologies already greatly influence standard enterprise operations. Companies tightly tie the technologies into supply-chain operations and even core manufacturing processes. Business-to-consumer (B2C) and business-to-business (B2B) communications reach right into the heart of businesses and extract information such as the number of units of a stock item and shipping location of products enroute to consumers.

When dealing with new technology, though, risk is high and answers unclear. That would be the case regarding whether to implement XML today. But there is strong momentum pushing XML into the factory.

Times, They Change

Time has a way of providing easy answers to the right technology to implement as everyone implements the popular choice.

Once, you had to decide whether an embedded controller should support token ring, LANtastic, or Ethernet; now Ethernet is the obvious choice. On a project with an Ethernet interface, debate formerly ensued for support for DecNet, IPX, Named Pipes, or TCP/IP; now TCP/IP is the obvious choice.

On yet another project with Ethernet and TCP/IP, participants struggled with the decision to support File Transfer Protocol, proprietary socket communications, or Hypertext Transfer Protocol (HTTP); now HTTP is easiest.

More recently, I've been involved in a distributed common object model (DCOM) vs. common object request broker architecture (CORBA) "object war" discussion, where there is no 20/20 hindsight yet. (Surprise: It appears to be simple-object access protocol, or SOAP.)

Today's Typical Architecture

We have widespread use of Ethernet and TCP/IP in embedded systems now.

Process controllers encapsulate proprietary and/or serial buses to consolidate data and control operations into OLE for process control (OPC) servers. Those servers are exposed to the network and interfaced via DCOM. The OPC clients can show the operation of multiple process controllers aggregated into an end-to-end factory operation. Using Windows CE for the process controller and Windows NT for the data, the concentrating OPC client system makes for a well-integrated, standard way to produce custom manufacturing applications.

It's never been this easy, we think—until reality strikes.

Often, CE is too slow for the process control application. This forces you to select a different operating system (OS). Without Windows 98, NT, or CE, you can't do DCOM. Even with CE, versions prior to 3.0 don't support DCOM. That means you must use a third-party add-on such as Intrinsyc's deviceCOM, used by most OPC vendors.

Of course, you may already have non-NT systems doing process-flow management, so DCOM is out again.

When you do get hardware and protocols in place, you'll find out next that not all OPC clients are compatible with all OPC servers. Cross-vendor debugging is difficult, to say the least. The OPC specification is huge and very complex. If you need a custom OPC server, you would be way ahead to purchase a OPC kit from one of the OPC supporters such as Intellution, PC Soft, Rockwell, Iconics, or Intrinsyc.

So, yes, it's never been this easy—but it's still not easy.

E-Commerce Happenings

With the dot.com hype, it has been impossible to miss the ongoing Internet revolution.

Much of the underground revolution centers around the infrastructure of e-commerce's B2C/B2B process improvements. However, while getting less press, there is also a strong application-to-application process change under way called enterprise application integration. All this adds up to automating business inside and outside the company walls.

Examples abound of XML-based initiatives. SAP introduced its distributor/reseller management package for supply-chain management, stating that XML is the integration key for all of its e-business efforts. Microsoft supports the BizTalk-protocol initiative and launched its Web Programming initiative. The United Nations and Open Access Same Time Information System (OASIS) are developing ebXML, an international e-commerce standard. Electronic data interchange (EDI) is moving to XML, thanks to the efforts of the XML/EDI Group. RosettaNet is implementing supply-chain e-commerce for electronic components. IBM is backing trading-partner agreement markup language (tpaML) for electronic contracts.

The new Microsoft BizTalk 2000 server product recognizes that companies' information technology (IT) systems cannot change overnight. The product provides sophisticated remapping among different protocols, such as EDI, flat files, and BizTalk. The BizTalk server could tie supply-chain e-commerce protocols to factory-automation protocols.

Schema Repositories

You can easily produce XML schemata that describe how other companies communicate with your device or system. Schemata exist for inventory counts, pick lists, bill of materials, receivables, product inspections, and more.

To make it easy for others to find your schema and vice versa, Web sites have sprung up to hold and index these personal schemas. Additionally, standards organizations encourage companies to standardize on one particular schema for a given transaction type. For instance, there is no need for each company to produce a different schema for each purchase order when they will all have 99% of the same functionality.

At www.biztalk.org, you can publish BizTalk-compatible schemata. You can also download any other schema someone else has published (downloading existing schemata saves time compared with developing them). Presently, more than 375 schemata reside there, including a large set from the Open Applications Group.

OASIS hosts a huge schema repository at www.xml.org. IBM uses it for its tpaML schemata. The Machinery Information Management Open Systems Alliance, or MIMOSA, an organization advocating open interfaces for equipment-condition monitoring, also participates.

Future IT Architecture

Why will XML play a major role in the future of IT systems, and why will the e-commerce use of XML drive down onto the manufacturing floor?

Looser coupling of products. E-commerce embraces XML because it makes it easier to integrate systems among companies. Within a company using products from different vendors, the same integration benefit exists. With XML as the protocol, you debug communications problems more easily. The document-type definition, which defines the particular XML schema, often pinpoints a protocol violation by simply running the real data message through a validating XML parser.

Lower prices. Changing from one manufacturer's product to another will not necessarily require changing the communications protocol. That encourages competition. Also, because you don't need to use a specific OS for a device, selection cost trade-off is open for consideration.

More flexibility. Unlike DCOM and OPC, XML is OS independent, so any embedded controller with an Ethernet connection can output XML. A process controller can change manufacturers, OSs, programming languages, and more, and as long as the XML content stays the same, the new system fits just like the old one. Also, there is more architecture flexibility when you route a given XML message to single or multiple data-collecting systems.

Easier data access. All major SQL database products are changing to accept XML-based queries and produce XML-based results. This means a simple embedded device could reach into the heart of a corporate database and extract information it needs without having structured query language and Open Database Connectivity drivers. Or in reverse, reporting software could reach into a process controller to determine when a tool needs replacement and roll that data into top-level financial reports.

New applications. With access to corporate data, lowest-level factory devices can now run new applications not possible before, such as tracking personnel time allocated to production use vs. maintenance of a machine.

Automated maintenance. Using XML and other e-technologies such as Web servers and browsers, you can perform maintenance functions routinely. For instance, you can download new specifications to a tool to handle a new type of material with slightly different properties or download a new control program when changes require substantial operational control differences. Another possibility: The controller periodically generates operational statistics that go directly to a central corporate database, bypassing layers of protocol-conversion computers and making them unnecessary.

Object Conversion

An OPC Foundation committee works to provide OPC communication functionality on top of XML. This means devices using OPC would not need to support DCOM, even though they still do remote object access.

The same thing in more general form is being proposed with SOAP, first drafted by Microsoft. IBM helped draft and publicly endorses Version 1.1 of SOAP.

That protocol does object-oriented remote procedure calls using XML. Both DCOM and CORBA require their own byte-level formats, but SOAP specifies object connections in XML. That means a COM object could interface to a CORBA object using SOAP as the neutral protocol between them.

Using SOAP, any device can call any other device's services to retrieve information or set parameters. Because these are XML transfers, the devices' OSs, programming languages, and internal structures don't matter. For this reason, SOAP will become a very hot technology in the next generation of devices and process monitors.

Some people claim SOAP marks the end of the component conflicts. Maybe, but it doesn't provide everything available through the direct use of DCOM or CORBA. Nevertheless, SOAP will likely be a major factor for automation due to its operating system, object model, programming language, and processor independence.

Challenges to XML Ubiquity

Several things need to occur before XML-based architectures become universal.

Schema standardization. The OPC/XML group started work, but many other non-OPC protocols also need definition. With many groups developing e-commerce standards, there's a shakeout period coming.

Support tools. Embedded systems will need XML tools to make protocol use easy. For CE systems, BSQUARE produced a CE XML developer's kit and a CE Transaction Builder for BizTalk. Microsoft produced a free XML jump-start kit for developing XML on NT, specifically targeting BizTalk development. Also, Microsoft made a major commitment to XML in the next generation of tools and products to support its Next Generation Window Services initiative. Other freeware/shareware tools exist, such as XML editors that highlight XML syntax as you write schemata from scratch.

Discovery standards. Discovery is the process whereby a device announces its presence and what services it provides. Universal Plug and Play uses the proposed e-standard simple-service discovery protocol. Java systems would typically use the Jini discovery mechanism. Salutation is an independent protocol that supports discovery.

Maintainance standards. Universal plug and play allows remote control of a device using a Web server in the device and a remote browser as a user interface. Intrinsyc also provides a similar product for CE called deviceRMS. For automatic software updates of deployed systems, BSQUARE has CE Remote Updater, which is an XML command-driven product.

Meeting these challenges makes XML, while not solving the whole interdevice communications problem, a permanent and widespread fixture on the factory floor. IC

Author Information

John Bono is the engineering director for enterprise products at BSQUARE Corp. in Bellevue, Wash., a firm specializing in Windows-powered embedded systems.