THE PROJECT was nearly finished. The end was in sight after an incredible effort of long hours, weekends, battles, changes, and all of the normal challenges that accompany a large project. We had delivered roughly 80% of the automation software for a life sciences S88 batching application when a problem surfaced a big problem. Equipment modules and phases included commands to devices that could cross controller boundaries.
The code construct employed for these commands were non-deterministic when crossing controller boundaries by design. This meant that the destination may not receive the command. The problem appeared sporadically but rarely on our development system and we could never recreate the issue in a controlled environment. On a large plant-wide system with large IO bus networks, the problem was suddenly pervasive.
The code had to be changed. To change one instance was simple enough but we didn't know how many instances existed throughout the nearly 2,000 phases and equipment modules each containing many steps which in turn contain multiple actions. My initial ballpark estimate to manually modify and validate the changes was between one and two manyears. Of course the project didn't have money or time burning a hole in its proverbial pocket nor were qualified resources available to do the work.
A few years earlier this would have been a disaster for everyone involved. A few years earlier, we didn't know what was possible with XML and XSLT.
SAMPLE FILES
>> DV SampleOnce we understood the problem and the required code changes, we knew that only XSLT could help us make the necessary code modifications with minimal project impact. We created an XSLT transform to find every action with the faulty code construct, modify the code appropriately, and record each code modification in a change log file. The code was exported from the DCS system as structured text, converted to XML, transformed with XSLT to fix the problems, converted back to structured text, and imported back into the system. The XSLT transform was validated so that each change did not have to be individually tested. All of the changes were completed with less than a man-month of work, and no impact to schedule, and minimal budget impact.
Many in the world of automation have not bothered to learn about XML (eXtensible Markup Language) or XSLT (eXtensible Stylesheet Language Transformation) believing they are technologies for web developers, IT personnel, and consultants. The truth is that XML and XSLT are finding their way into nearly aspect of computer technology today. XML based technology has spread so pervasively and so widely across application domains that many are unaware of its impact in their own discipline or of the potential value it brings.
This four part article will introduce the basics of XML, introduce XSLT as a query and transformation language for XML data, and provide examples of how these technologies can be used in the world of automation. The three parts to follow are summarized below:
Introduction to XML
XML is a flexible general purpose data storage structure in human readable text format. Despite its name, XML is not really a "language" like HTML. Instead, XML provides a set of rules for anyone to create their own markup language. Anyone familiar with HTML will recognize many similarities with XML. These similarities made it easy for web developers to jump aboard the XML bandwagon. Its proliferation on the web has created some misconception of XML as a web-only technology. In fact Dictionary.com defines XML as: "A metalanguage written in SGML that allows one to design a markup language, used to allow for the easy interchange of documents on the World Wide Web."
However, XML has been used for much more than the easy interchange of documents on the web. so, a more appropriate definition might read: "A metalanguage written in SGML that allows one to design a markup language, used to allow for the easy interchange of data."
In this series, I'll introduce the basic rules of XML, terminology, and related standards. You'll learn how to read XML documents and how to create your own. The series will also discuss declarations, processing instructions, namespaces, well-formedness, validity, DTDs, schemas, and encoding. Finally, I'll point you to a number of resources and applications to help you learn more about XML and to help you work with your own XML documents.
XML Revealed
Here's an example of what SML actually looks like, and as seen in an XML reader called XML Notepad (See Figute 1 below):
- XMLSchema-instance SchemaVersion=3516>
FEED_OP-
\\BatchServer\BATCHCTL\AreaModel\RECIPES\AMCASCON.CFG
2006-02-27T09:40:33
JTSever
- -
DRAIN:1
DRAIN
UNIT500
-
FEED:1
FEED
UNIT500
FIGURE 1: XML READER
