XML for Instrument Control and Monitoring From: http://www.ddjembedded.com/resources/articles/2001/0111i/0111i.htm See also listings: http://www.ddj.com/ftp/2001/2001_11/ixml.txt ------------------------------------------------------------------------ XML for Instrument Control and Monitoring Dr. Dobb's Journal November 2001 By David Cox David is a senior software engineer at ABB's Electric Systems Technology Institute in Raleigh, NC. He can be contacted at david.cox@us.abb.com. Objects are used for machine-to-machine communications. However, both Microsoft's DCOM object technology and the Object Management Group's CORBA are "multiport protocols," which means they don't work too well with firewalls that limit the number of open ports. So much for efficient machine-to-machine communications. Partly because of this, Microsoft introduced a third protocol -- the Simple Object Access Protocol (SOAP) -- that piggybacks on the single port protocol, HTTP. All three protocols -- DCOM, CORBA, and SOAP -- let client applications create objects that appear to be local, but really execute elsewhere on a network. In the near term, DCOM, CORBA, and SOAP will likely remain the preferred choices for distributed computing. Even in the world of instrument monitoring and control, for instance, COM and DCOM have been adopted as a standard for controlling instruments, at least in terms of the Open Process Control (OPC) Standard, promoted by the OPC Foundation (http://www.opcfoundation.org/). However, efforts are underway to use XML for electronic data interchange and all types of business transactions, as people begin exchanging everything from purchase orders to medical records as XML-formatted messages. The Instrument Markup Language In fact, a group at NASA's Goddard Space Flight Center is using a dialect of XML called the "Instrument Markup Language" (IML; http://pioneer.gsfc.nasa.gov/public/iml/) to control remote instruments. IML is being developed by NASA and Commerce One (http://www.commerceone.com/) with the goal of creating a very general and highly extensible framework that applies to any kind of instrument that can be controlled by a computer. The Astronomical Instrument Markup Language (AIML; http://pioneer.gsfc.nasa.gov/public/aiml/) is the first implementation of IML. Although AIML was created for the astronomy domain in general and infrared instruments in particular, both AIML and IML were designed to apply to just about any instrument control domain. The goals of IML are to: * Provide as much platform independence as possible. * Create a system that is easy to develop, modify, maintain, and extend. * Promote reusability by utilizing emerging technologies that enable reuse. * Reduce the implementation time for facility instruments used by scientists. * Define the interface between hardware and software engineers. * Facilitate multiple iterations of the instrument description during design and implementation by means of a software architecture that is readily adaptable to such changes. * Separate implementation (representation) from description. In short, IML is a specification for using XML to aid in the exchange of data and commands with instruments. XML itself is not sent between computer and instrument. However, XML is used to describe the commands and data that can be transferred. For instance, a software tool reads the XML, automatically creates an appropriate user interface for issuing commands, and finally sends the commands in response to user input. When responses come back, the same tool can -- using the XML specification -- interpret the incoming data and automatically present it with an appropriate user interface. The original version of IML was written as an XML Data Type Declaration (DTD). The most recent version is written as an XML Schema. Both define rules for naming tags and attributes, and how the tags can be nested. For the purpose of this article, I will present the DTD version of IML. The newer schema version changes IML in several ways. However, the DTD version is easier to understand and serves as a good background. A valid IML document will begin with an Instrument tag. This tag can stand alone or contain Instrument tags nested to any arbitrary level where nested tags represent subsystems. Intermingled with nested Instruments can be an arbitrary number of Ports. IML, therefore, has a basic structure like that in Example 1. Port s contain one or more Command records or one or more Telemetry records. A Command record is defined as a Command tag followed by a RecordFormat tag. A Telemetry record is defined as a Telemetry tag followed by a RecordFormat tag. You can, therefore, flesh out Example 1 so that it looks like Example 2. Command s are sent to instruments while Telemetry contains responses. Commands contain optional arguments and Telemetry will contain one or more fields of data. RecordFormats help to describe the format of the commands or data being sent. Going down yet another level, each Command can have zero or more Arguments. Each RecordFormat will have a Format tag for each Argument. Similarly, each Telemetry record will have one or more Fields (if there weren't any Fields, no Telemetry records would be sent). Again, each RecordFormat will have a Format tag for each field. IML also provides for arrays of Fields and arrays of Formats. Each Command Argument has two required and several optional attributes. The first required attribute is the Argument's name and the second is the Argument's data type. Currently, IML uses strings to specify a Java data type. The required attribute is optional and specifies if the argument itself is optional. If required is not given as an attribute, then the default value for required is False. The hidden attribute is also a Boolean that determines if the argument appears in the user interface. The default is False, making all Command Arguments visible as a user-interface control. The remaining optional attributes include class, style, docHelp, and title. These control various aspects of the user interface for the argument. Each Telemetry field also has two required and several optional attributes. Again, the first two are the Field's name and the Field's type. The remaining attributes include required, class, style, docHelp, and title. For instance, assume that Example 3 is XML code to help control the Canadarm on Space Station Alpha. (Canadarm is a robotic arm used for payload manipulation and retrieval on space flights. The device is best known for the successful repair work it did on the Hubble Space Telescope and its role in assembling the International Space Station.) In reality, Instrument and Port have some required and optional attributes, but I am leaving them out to focus attention on the Command, Telemetry, and RecordFormat tags, and the overall structure of the XML. In this example, the XML says that you have a Move command that takes two arguments. The first argument is a string for the command and the second is an integer. The RecordFormat shows that the string for the Move command will be "MOVE". The Distance argument will be an integer between 0 and 1000. Again, the RecordFormat shows that Distance will be sent to the device as a header, followed by the argument. In this case, the header is "DISTANCE=". The application software reads the XML and creates a slider control labeled Distance. Users can slide the control to the desired value. The Command argument is hidden and will not appear in the user interface. However, the Command argument is used to construct the command to send to the device. In this case, the command is MOVE DISTANCE=500. This ASCII message will be sent out of a computer port directly to the Canadarm. With a really good pair of binoculars, you can see it move 500 units along the space station. If you don't have any binoculars, you can rely on the Canadarm to send back a status response saying how far it really moved. Two fields will be included -- the time of the move and the distance. The time will come to you formatted as a string and the distance formatted as a Java Integer. Knowing this, the application will display the response, possibly using an odometer for the distance and a digital clock for the time. Advantages of XML By using XML to describe how commands and data move between computers and instruments, manufacturers will no longer need to create custom software, specialized device drivers, and/or distributed objects to communicate with their products. Instead, an instrument manufacturer will only need to provide an XML description of how the communication takes place. Tools that can parse and interpret the XML will be able to automatically generate the required user interface to control the instrument, automatically construct messages to the instrument, and automatically display the data that is returned. IML represents a first attempt at making this capability a reality. 2001 CMP Media, LLC. All Rights Reserved.