Markup Languages Enhance Integration

 Maintaining a smooth flow of information from one software application to another needn’t be quite the hassle that it once was during upgrades. Just ask the automation engineers at Chevron Global Lubricants, the San Ramon, Calif.-based manufacturer of greases, oils, and other blended lubricants. As they discovered, a new generation of markup languages can streamline software integration by defining data structures for deploying the extensible markup language (XML) in manufacturing.

Chevron’s engineers learned about the power of incorporating these languages directly into their code when they embarked upon a worldwide modernization program. The multiphase plan was to replace a range of disparate control schemes, manufacturing execution systems (MESs), and enterprise resource planning (ERP) systems with common platforms.

Implementation of the plan would begin at the company’s plants in Port Arthur, Texas and Richmond, Calif.  Chevron would first replace the control systems at these locations with the same distributed control system (DCS), one that adheres to the ISA88 batch-control standard promulgated by the International Society of Automation (ISA) (www.isa.org) in Research Triangle Park, N.C. In the next phase, it would install a standard ERP system. Until then, the new DCS from Yokogawa Corp. of America (www.yokogawa.com/us/) in Sugar Land, Texas would have to communicate with the legacy ERP system through the old COBOL-based interface.

To establish a new communications interface that would not have to be rewritten a few years later, Chevron took the advice of Yokogawa’s experts and adopted the Business-to-Manufacturing Markup Language (B2MML). The WBF (www.wbf.org)—the Organization for Production Technology based in Chandler, Ariz.—developed this standard to implement in XML the data models specified by the ISA95 family of enterprise-control system standards. By defining common data structures, B2MML links business-level systems like ERP software with manufacturing systems like DCSs and MESs.

Using B2MML, Chevron was able to convert the old ERP transactions into XML messages that the new DCS can decipher. Not only did the standard simplify this initial integration, but it also made provisions for integrating the new ERP system later. It also makes maintaining the interface easier. Messages can be used for more than one production process, and adding new data into existing messages is possible without a major redesign.

Chevron is not the only company finding that markup languages can simplify and shorten integration, which can easily cost more than the software itself. “When B2MML was originally released, we had companies that were spending anywhere from one to two years integrating their business systems with their shop-floor MES systems,” reports Dennis Brandl, president of BR&L Consulting (www.brlconsulting.com) in Cary, N.C. and editor for WBF’s B2MML committee. “Once the standard was in place, those things were happening in about two months.”

Implementing industry standards

B2MML and other markup languages can streamline software integration because they define data structures according to the industry standards for the application at hand. Right now, the most popular ones in manufacturing are defining these structures in XML. In the case of WBF’s markup languages, B2MML uses the World Wide Web Consortium’s XML schema definition (XSD) to implement the ISA95 standard for exchanging information between business and control systems. WBF’s BatchML uses XSD to implement the ISA88 standard for batch control systems.
To help users visualize the relationship between standards and XML, Brandl compares markup languages with ordinary human languages like English. In spoken languages, a voice transmits a message according to the rules of the language. In the case of markup languages, XML is analogous to the system of sounds generated by the voice, and the markup language is analogous to any spoken language.

Like every spoken language, each markup language contains a set of rules and conventions, but these rules define data tags. “When you get right down to it, XML files are simple text files,” explains Brandl. “XML puts well-defined tags on each piece of text so you know not just what the data are, but what they mean.”  These tags fit together in a well-defined structure that Linux, Windows and Unix systems can interpret.”

Because the rules of individual markup languages are industry standards, each language is really an implementation-ready format for a particular standard. It, therefore, is much easier for an operating group within a company to enlist the help of the information technology (IT) department in moving data. While IT may not understand a 100-page manufacturing standard, it will know how to organize data based on XML, notes Dave Emerson, director of Yokogawa’s U.S. development center and chairman of WBF’s B2MML and BatchML committee.

Because B2MML and BatchML apply to specific tasks in various industries that focus on downloading and uploading production data, they are “vertical” languages, according to Stan Devries, director of solutions architecture at Invensys Operations Management based in Plano, Tex. Other vertical languages exist, such as the Security Assertion Markup Language (SAML) that ISA is developing to implement the pending ISA99 standard for manufacturing and control system security.

“What I call ‘horizontal’ languages are tuned toward understanding the horizontal flow of the raw material and product through the plant or value chain and asking questions about what happens to them,” continues Devries. An example is the Substation Configuration Language (SCL), an XML-based implementation of IEC 61850-6 substation standard for the power generation and distribution industry.  Another is Production Markup Language (ProdML), an XML-based standard promulgated for oil and gas production by the Houston-based Energistics Consortium (www.energistics.org).

Benefits of experience

Besides packaging data into industry-standard formats and replacing proprietary data interfaces, the structures provided by some markup languages also allow users to encode their business processes and workflows. This ability supports a kind of uncoupling of a business or production process from the technology implementing it. This uncoupling is desirable because technology tends to evolve more rapidly than the business structures and workflows it facilitates.
“Markup languages provide a means for defining the solution to a business problem so that the technology can evolve when the business doesn’t,” says Ivan Todorov, director of strategic technologies at Invensys Operations Management  (www.iom.invensys.com). “You can carry the definitions out to provide system continuity.” This ability provides a measure of reliability into the future as technology evolves and configurations change to accommodate growth.

By encoding procedures, the markup language can also serve as an enforcement mechanism for procedures in workflows. “We find that some users are counting on it to provide continuity with the aging workforce, the joint ventures, and traveling experts,” notes Devries.

Despite the fact that XML-based markup languages have made these benefits available for more than a decade now, their use in plants is still in its infancy and far behind their implementation in business computing. Emerson at Yokogawa attributes this lag to the longer process life cycles that typically exist in manufacturing. Manufacturers usually cost justify process equipment and the supporting automation over a 20- to 30-year time horizon. Even then, they invest in upgrades only when a business driver forces them to do so. Because production equipment is replaced less often than office equipment, it generally takes longer for technology to work its way into production.

Because a number of markup languages are popping up as more manufacturing facilities begin to use them, Emerson is offering users a word of caution about selecting one. “Anyone can create a markup language,” he notes. “You want to look at the support that the language and the standard behind it have. Is it just a little start up that two or three people threw together? Or has it really been adopted and used by a larger segment of industry?”

Because markup languages implement standards, he recommends vetting them as you would any industry standard. “Know the standards in your domain, and look at your need,” he advises. “Are you trying to pass data between systems? Or do you need help in structuring data in order to do something new within your system?” Once you identify the need and the specific requirements, find the appropriate industry standard that has a markup language associated with it.

“Best practice is not to try to extend or add to it, except as a last resort,” Emerson continues. “You’ll just make it harder for someone else to use.” Another of his best practices is to talk with others who have used it and try to reuse the technique that they have used.

Revivified HTML

Although most markup languages finding their way into manufacturing are implementations of industry standards in XSD, there is one important exception—the HyperText Markup Language (HTML5), a pending revision of the platform-neutral language underlying the World Wide Web. The purpose of the update is to incorporate the latest multimedia into the HTML schema for structuring and presenting content for display. Besides incorporating HTML4, the final form will also subsume both extensible HTML (XHTML) and document object model (DOM) level 2 HTML (DOM2HTML).

When finished, the upgrade should eliminate the need to have the right version of plug-ins like Adobe Flash Player in order to see visual content on Web pages. “With HTML5, this ability will be available to everybody in a platform-independent way,” says Todorov at Invensys. “This is truly revolutionizing the web.”

St. Louis-based Emerson Electric (www.emerson.com) is already experimenting with early versions of HMTL5 to deliver control-system content to users over the Internet. “We needed an open format that would work on most devices and browsers,” notes Mark Nixon, director of research. “Originally, we were looking at Silverlight and WPF, but decided that was too restrictive for an open web site because not everybody runs Microsoft products.”

Not only does he see the value of HTML5 for building web pages and delivering content over the Internet, but he also views the new display markup language as a means for linking information from various sources. “XML is a very convenient way to move content in an open format, and the display markup languages like Silverlight and HMTL5 are convenient for building displays rapidly,” he says. “It’s no problem change displays if you don’t quite like them.”

In one field test, his development team was able to use XML, Silverlight, and JavaScript Object Notation (JSON) to display the results of batch analytics for a group of operators so they could predict and detect developing faults. Not only did the languages allow collecting the data in one place for the operators to view on their Microsoft platforms, but they also permitted converting the information for plant managers to view on their iPhones. The experience with this project led the team to use HTML5 and XML for the control-loop foundation.

The team also used JavaScript to make calls to Emerson Electric's DeltaV digital automation system to retrieve the real-time data. “You can’t really do that directly with markup languages,” explains Nixon. “They can describe what you want to show and how to show it, but you have to issue an actual request to a backend server at some point. We’re just using standard web-services techniques.”

According to Nixon, the biggest challenge for these kinds of projects has been the perennial problem of defining the task succinctly. “Once you have identified the exact task, then you can go into a data modeling exercise,” he says. Because markup languages let you build these models more quickly, it is much easier to iterate on the initial designs to produce an optimal solution and to smooth integration projects.

BR&L Consulting (www.brlconsulting.com)
Emerson Electric (www.emerson.com)
Energistics Consortium (www.energistics.org)
Invensys (www.iom.invensys.com)
ISA (www.isa.org)
WBF (www.wbf.org)
Yokogawa (www.yokogawa.com/us/)

James R. Koelsch is a Contributing Editor to Automation World.