Promise: Model-centric Advanced Automation Applications
In the process industries there is an ongoing trend from simple control applications to more advanced applications like asset optimization; planning & scheduling. These advanced automation applications are based on mathematical methods like simulation and optimization and require an integrated model of the whole industrial plant. XML is beneficial for storing this information and for transforming it to the needs of the individual applications. This talk presents our experiences with defining a plant model for usage in the process industries domain as well as with achieving interoperability of third party applications with ABB's advanced applications through the use of XML.
RC@S: Root-cause analysis as a Web Service (with Zaijun Hu)
Root-cause analysis (RCA) is a structured approach to tackle failures and mistakes in industrial pants. Since expert knowledge is not always easily accessible the web technology provides an opportunity to enable successful deployment of the RCA approach as an industry service. In this talk we present an XML-based information Web Server that is used as a model server providing the necessary models for the Root Cause Analysis service. XML-based building blocks are used for efficient data modeling. The Software Architecture exploits the Presentation-Abstraction-Control (PAC) Style.
Conference proceedings of the XML Days 2001, Munich are available here: XML Days 2001 (registration is necessary).
Some more background information about XML (taken from O'Reilly XML Newsletter):
One of the challenges that XML has evidenced over the last decade has been its very chameleon-like nature. Is it a way to describe a document or of encoding data? Is it the foundation of a language for performing remote procedure calls or a way of retrieving news feeds? Was it intended to be used for creating process or as a formal declaration of state? The answer to all of these questions is, of course, "yes." And therein lays the dilemma.
Ten years ago, XML started as a way of describing documents, which became an open invitation to bright people in any number of industry verticals to start creating their own formal vocabulary or taxonomy "documents." An invoice is a document - you can draw that invoice as a form with a name, one or two addresses, and a set of line-items, rendered as stacked 2" x 1/4" inch boxes with separate boxes for amounts, prices, and totals, and a few boxes at the bottom for the total, the tax, and total with tax. Yes, you could make exactly the same kind of structure as an OOP object, which could just as readily be considered data, but because XML-like language had been used to encode HTML (and because "real" invoices are written on paper), such an invoice was a document. End of story.
Except it wasn't the end of the story. A vendor of operating systems and office suites realized that their attempt to create a distributed marshaling proxy system was not working out, primarily because the only port that most people routinely kept open on their machines was port 80 - the port used by HTTP. Furthermore, attempting to send marshaled binary objects wasn't working well there either because it necessitated having something on the end being able to bind the proxy to a corresponding object. With some consideration, the vendor realized that XML was actually a pretty good tool for doing this... if you set up a standard so that other people would also agree to take these objects and convert them into formal entities. Thus was SOAP born, and in time the whole of the SOA web services stack.
Meanwhile, XML was showing up in strange places and making a fool of itself. Like some crazed mythical trickster, XML refused to behave like other languages. An XML instance could be twisted and transformed, could be validated against a growing number of conceptual schemas, could link to other resources and embed itself in other XML in a way that bore more resemblance to kudzu than to conventional C++. After a couple of tries, what emerged from the XML community was a growing methodology for how to work with XML, how to push the language and make it push back in ways that fell outside of distinctions between data and document altogether.
Those who became proficient in XML often came from very non-traditional backgrounds - typesetters and molecular biologists, topical domain experts and web page designers, most of them coming to the discipline not because programming was cool but because they had a problem to solve, and having found a solution in XML, they found themselves entranced and stayed in that domain. Many XML experts were not expert programmers in the normal sense - being able to work in the declarative paradigm typically required a perspective on development, a sort of zen-like fascination with the abstract and abstraction, that was often at odds with the detail oriented way of thinking that tends to define traditional programming. And many of them tend to become system architects and modelers.
Links to related patents and other publications: