XML for Automation Devices

A Multi-Schema Approach

1. Domain background

1.1. Industrial production

Planning and designing the production process in industrial plants is a crucial factor in order to reach the production goals regarding costs, quality and delivery time. Especially in plants running in so-called high wage countries, the mix of production input factors is changing: Based on a mechanized production, for example realized with assembly lines, more and more companies migrate to partially or fully automated production processes. This means, that the production process follows a prefixed sequence and can be repeated as often as needed. Electronic components supervise and control the process directly, the human work consists mainly of supervising duties concerning the controllers and the design of the programs. Because the employment of new automation strategies is a crucial contribution to succeed on the market, the planning of the automation level became a very important task [SCK98].

1.2. Modern automation systems

The basic elements in automation are algorithms, programs, controllers and interfaces which are generally grouped in two classes: The automation application covers algorithms and programs, therefore the optimum control of the technical process. The controllers, field devices and interfaces deliver the automation infrastructure which is necessary so that programs can be executed. The theory of the technologies of the infrastructure items is also known as automation system technique. This is the main employment field of this paper.

1.2.1. Architecture of automation systems

In order to understand the problems in the domain of automation systems it is necessary to introduce their current architecture which is widely used.

During the 1960s and 1970s, all automation systems had central controlling entities, called process-controller, to which all sensor and actuator elements were directly connected. Mainly driven by the availability of new powerful microprocessors [RAV97], communication technologies and other Commercial Off The Shelf (COTS) hardware, the centralized functionality could be distributed and downsized, comparable to the developments in the office world. Since then, several trends dominated the automation systems:

• The development and standardization of open, field proven communication protocols (e.g. IEC1158 [IEC00]), so-called field busses, caused the opening of the up to then proprietary system technique.

• The integration of digital electronic components, e.g. RAM and microcontrollers, in the sensor and actuators elements allowed the creation of intelligent field devices instead of simple measuring and setting elements. The available calculating power within these intelligent devices allowed the implementation of local control routines and add-on functionality like self-monitoring, calibration and others.

• The development and functional upgrade of small to medium sized Programmable Logic Controller (PLC) [TAU96], [STR98] with standardized programming interfaces allowed a more distributed employment of control power and the realization of advanced control strategies

The addition of these trends led in general to the migration of functionality from the once very big central controllers towards smaller PLC and the field devices. This was promoted by the availability of open communication protocols [KLH97]. The result is the distributed automation architecture of today [PFL98],where an open system kit replaces the once monolithic and proprietary architecture and allows the end user to gain profit on the newest device and communication functionality without being bounded by device manufacturer restrictions. Knowing, that there is no unambiguous definition of the attribute openness, [SPE98] states that although nowadays everybody speaks about openness in the automation technique, the term is interpreted in a different way depending on the manufacturer and operation area. In general, it comprises automation components that offer tuning and combining possibilities to the user. Figure 1 displays a common architecture of today's automation systems (based on publications as [LAG99A], [EPP98], [PIN98] or [KON98]):

Figure 1: Today's automation systems architecture

The entities in the areas 2 and 3 are intelligent field devices which are interconnected via fieldbus segments. They can be grouped into fast communication and slower but intrinsically safe transmission technologies. The entity 1 is deputizing for the PLC level and builds a gateway towards higher hierarchy levels e.g. visualization stations (4), process planning, company information systems (5) or even Internet servers (6).

1.3. Field devices

The open communication led to the introduced open system kit and allows the installation of so-called multi vendor plants, enforcing the best-of-class principle. The end user gains profit of the device manufacturer independency and the exchangeability of the devices. In this paragraph the constituents of this kit, especially the field devices and their functionality will be described.

The term field device generally sums up the sensoric and actuatoric function carriers in the automation system technique according to [ZIE94]: Field devices are sensors, that convert process information like temperature or product information like a pH value into automatically processable informations (...). Furthermore, field devices are actuators, that, supported by a process control system, intervene in the process in order to control it in a sensible way. The principal mark of a field device is therefore the existence of a process interface and a system interface.

Figure 2: Functional structure of Sensors and Actuators

1.3.1. Basic field devices

The task of a sensor is to register the process values, e.g. temperature, pressure or flow, and to convert them into a processable format, which is generally an electric quantity like voltage or current. The electric signal can then be transmitted via the system interface to a controller unit. Dually, the function principle of an actuator can be characterized with its task of converting an electric signal from the controller into a mechanical process intervention (e.g. via motors or valves).

1.3.2. Intelligent field devices

The manufacturers of automation components, especially of field devices, pursue the strategy to enhance their products with extended and more flexible functionality in order to offer their customers more and additional usability and thus reaching an Unique Selling Position (USP). Additional functionality can be grouped in:

• Better measurement accuracy with local data processing, e.g. filtering, compensating, autoscaling and linearizing

• Add-on functions like local display, mixed sensor-actuator functionality in one field device, self controlling, self-calibrating, alarm enabling and delivery of maintenance informations.

Beside the use of new measurement principles adopted from the domains of physics, chemical or even biological research, system aspects are more and more dominating new functionality within field devices in order to reach the described features. The modularisation of field devices can be useful for the end user, because he can configure himself a solution which is exactly matching his problem, as well as for the manufacturer because he can use the modules several times for different field devices he offers. This is the base for the integration of functionality into the field device. In the case of vertical integration, functionality formerly delivered by higher level components moves into the field device, e.g. modern drives are increasingly equipped with freely programmable functionality in order to control drive relevant sensors (end switches, motor temperature watchdogs) locally. Horizontal integration deals with the grouping of functionalities formerly delivered from different sensors in one field device. Nearly all measuring principles show a transmission behavior which is variant to the temperature of the environment. The measurement value has to be compensated by a temperature value. The integration of a temperature measurement element and the internal compensation of the primary measurement value is an example for horizontal integration. The same is true if more than one primary values can be measured with one field device (e.g. 2 flows, 1 temperature is measured, 2 flows, the delta flow, the flow direction, the velocity of sound and the temperature are available at the system interface). Another system aspect is to extend the flexibility of field devices, so that they can be employed for different tasks. The extension of measurement ranges and the possibility to dynamically adjust the actual ranges within the maximum enables the end user to reduce the diversity of components in his plant and also in the spare part stock.

When summarizing the developments in the field device domain, one realizes, that the state of the field device functionality has reached a very high level. The range of the function set has exploded, the primary costs to be paid for each function are falling, which is necessary for the user who has to keep the hardware costs for his plant as low as possible.

2. Problems in open automation systems

2.1. Economic problems

The end users are expected to be happy about the situation in the field device market and to employ the modern, open and multifunctional components consequently. However it can be stated, that a lot of users act very hesitantly when new plants are to be equipped with field devices of the described class.

Even [SCH98A], representing a device manufacturer resumes his experiences with planers and operators: The state of the sensor technology for chemical plants is between satisfying and sufficient, but can not be described as good. This evaluation differs between the precision, the suitability for hazardous areas and the reliability of the digital electronics which on the one side are very positive and the hyper functionality, the complexity, the diversity of fieldbus systems, device functionalities, device descriptions and operating possibilities which count negative on the other side. This has a negative impact on the overall costs caused by each single field device during its whole life-cycle. A study of the NAMUR [DRT96] summarizes: The costs caused by field devices during their lifetime are significantly higher than their purchase price. (...). It is very difficult though to determine the single cost factors exactly, they can therefore hardly be taken into account when making a purchase decision. This is one of the main reasons, why users often hesitate to employ multi-functional field devices in their plants despite they could benefit from the new technologies.

2.2. Technical deficits

Breaking down the economical problems into technical deficits, it can be stated, that the field devices are

• multifunctional: One device can offer multiple functions, like measuring several physical quantities

• configurable: Measurement and setting functions can be interconnected within one device with the help of firmware modules. Further, extension modules can be physically plugged into device slots.

• flexible: The device can be tuned and parametrized in order to fit perfectly to a certain process area and physical range. Further there are country and language settings, alarm triggers and other functions that can be applied.

• programmable: Especially in multifunctional devices, the process values can be tied together with the help of freely programmable processor power and RAM.

As it easily can be seen, all these features, which ought to be positive, require a lot of tuning, parametrizing, configuring and programming. Regarding a single device type only, this could be handled by a specialist with reasonable effort. But the use of many devices coming from many different manufacturers (which one the other side is one of the largest benefits of open fieldbusses), causes the confusion. When the device vendors became aware of these facts and the extent of engineering effort it caused at the users, they tried to describe the device functionality in a uniform and formal manner, so that software tools can read these description and assist the user. The definition of vendor independent device description languages was a big step towards more device operability and was carried through at the fieldbus user organizations, which are responsible for standardizing, maintaining and marketing their fieldbus specification. Because the device manufacturers still had the freedom to implement their USP- functionality if they only describe it in a standardized way, the deficits seemed to be erased, both the vendors and the users had their benefit.

2.3. New diversity

From the view point of the end user today's situation is, that he has to employ several different communication systems in one plant, each suited to the actual process requirements. As end users [DRV99] realize: It would be desirable to employ only one fieldbus type in the whole plant. This can not be realized in practice. The main reasons are: Investments regarding the different functionalities of the busses concerning explosion safety, transmission speed, interoperability and the coupling towards already existing systems or plants. This is causing the need to deal with different description languages even if there are functionally identical devices operated at the different fieldbusses. Even worse, sometimes the user is forced to deal with several description languages for one fieldbus. With the steadily increasing device functionality, the frames of the description languages became soon too narrow. New languages were defined, without being compatible to the old ones. This, too, enlarges the deficit, which is shown for one device type using one fieldbus system in Figure 3:

Figure 3: Basic scenario: Diversity of device descriptions with one device type

Following [BEA00B], it can be assumed, that in larger plants more than 100 device types of approx. 10 different manufacturers are employed using at least 2 different fieldbus systems. Based on the scenario in Figure 3 the engineering effort explodes.

On the other hand, the device manufacturer has to deliver all the descriptions in the different languages and concepts. In the meantime he has to engage software engineers as some languages are carried in component architectures like ActiveX. If the vendor supports more than one fieldbus system, the effort must be multiplied.

Shortly said, despite great efforts have been invested in defining and standardizing open device description languages, the diversity is still a big problem for the end users and for the device manufacturers as well.

3. Solution idea

The solution proposed in this paper is the harmonization of the existing languages with regard to investment protection. The definition of an open fieldbus independent description language shall describe a common device model and decrease the engineering and handling effort on both sides, the producers and the consumers.

3.1. Basic requirements

First of all, several basic requirements are set up, that shall constrain the basic technology selection used for the description language.

• Platform independency: One of the main reasons for the device description diversity is that the available languages are tied to a certain fieldbus system. In order to exclude such problems for a harmonized solution, the resulting language shall be a priori platform independent. In that context it must be also assured, that the result is not tied to an operating system as it would be for example using ActiveX components as carriers.

• Extensibility: The harmonized language must be easily extensible. It is not possible to foresee future developments and the past has shown how fast static language frames became too narrow.

• Readability: The practical experience shows, that this point is very important. For example, if a tool is not running or available the commissioning person shall at least be able to read and understand a device description manually or with the help of a simple viewer/editor.

• Support for validation: There must be a procedure in order to validate device descriptions easily. The language has to be defined formally in a clear way. Misconceptions must be avoided. The experience with existing description languages shows, that despite having a formal definition of a language, there is still room for interpretation.

3.2. Additional Requirements

In order to define a harmonized device description language that will be used in the automation community there a further requirements to be fulfilled:

• Migration possibilities: To protect investments, already made by collecting know-how with existing languages, there must be a import/export path provided. It cannot be assumed that the introduction of a harmonized language will suddenly change the procedures of all users and manufacturers. Using the existing device description files through automated translation as well as generating old device descriptions out of the harmonized language must therefore be relatively simple.

• Integration: In order to be able to support the users and the manufacturers quickly with software tools for editing, viewing, importing existing descriptions and generating old descriptions, the language must be designed in a manner that it easily can be integrated into applications. Parser and generator support must not be left to specialists.

4. Solution using XML

To solve the problem and to fulfil the requirements an intensive analysis concerning description languages was carried through. First, it covered the domain of automation technique inspecting the existing languages. But as expected, none of the existing device description technologies could fulfil a reasonable percentage of the requirements. This is mainly because these languages were designed exclusively towards one specific platform (fieldbus).

The next step was to examine common programming languages like C++ or Java for their suitability to describe field devices. The result was, that these languages are too extensive to handle (e.g. the construction of parsers would mean too much initial costs). One must not forget, that the persons which have to deal with the language and the description files must be convinced of the language constructs and therefore have to recognize the terms of their daily work. The aspect of domain namespaces is therefore important at this point. Regarding this, common programming languages were dismissed.

The most suitable solution was the use of the extensible markup language (XML) because it fits nearly all requirements extremely well. Especially with the adoption of the XML Schema Candidate Recommendation on the horizon, http://www.w3.org/TR/xmlschema-1/ and http://www.w3.org/TR/xmlschema-2/, the XML family of standards has reached a certain maturity. The use of a stronger constraint mechanism, compared to the Document Type Definition (DTD) [KIE01], like it is provided with the XML Schema is absolutely necessary in order to describe field devices with are modeled strongly after the data, values and parameters they contain. The following table resumes the requirements and explains why and how XML meets them:

Requirement	Fulfillment
Platform independency	Inherent to XML
Extensibility	Inherent to XML
Readability	Inherent to XML
Validation support	XML schema
Migration	Importing through lexical analyzing; generation suing XSLT
Application Integration	SAX, DOM, JAXP, Xerces, Xalan ...

One of the most important aspects in this context is, at least in the automation domain, to have a clear definition of data types, especially if it is taken into consideration that the existing languages sometimes differ in the definition even of basic types like integer. The use of XML Schema and its data types offers a very good and independent solution.

5. Modeling the harmonized language

This chapter will show, by characteristic examples, how, based on the existing languages, a general and harmonized model for the new describing language was designed. During the analysis, which is shown first, the main elements of field devices and their description languages were detected, in order to harmonize them through abstraction. Following this process a target model was synthesized, having the potential implementation with XML in mind.

5.1. Analysis

5.1.1. Profibus Electronic Device Description Language (EDDL)

The EDDL represents a class of standards, that were developed based on the Highway Addressable Remote Transducer- Device Description (HART-DD). It was designed and standardized for the Profibus communication system in August 2000 [PNO00b]. Using the Unified Modelling Language (UML) in order to get a static analysis the following model for the EDDL was created:

Figure 4: EDDL analysis

An EDDL file is a mixed description covering

• the inner structure of a device,

• application functions for the user and

• help constructs.

Core of the description of the inner structure, and therefore the most important class is the variable construct which has attributes like type and label assigned to. Each variable has one format, specifying amongst others the MIN_VALUE and MAX_VALUE. The command construct describe the logical address of a variable which is, with the help of a block definition used for accessing the variable via the Profibus protocol. The class DEVICE_INFO comprise the identification data of the manufacturer and the device. The application functions are described using the METHOD, COLLECTION and VARIABLE_LIST constructs.

5.1.2. Profibus Device Data Base (DDB)

The EDDL, introduced in the above paragraph describes the parameters within a device, that are needed in order to tune the device functionality and to invoke measurement values into the control application(s). In order to get the communication running, another description file, covering the communication parameters like maximum response time or supported transmission rates, is needed in the Profibus world: The DDB file [PNO00a]. The extreme dedication to the inner behavior of the Profibus state machine is reflected by the overwhelming appearance of specific, communication-related blocks in the analysis model - in contrary to the EDDL, which is a rather generic language.

The main elements of the DDB are the COM-Parameter and the User-Parameter classes. Members of the first class, have fixed names, ranges and types specified in the EDDL-specification [PNO00a] and are grouped in several containers reflecting their meaning and their overall applicability. The User-Parameters have comparable but less attributes than the variables in the EDDL. The restrictions regarding their use and the limitations in expressing more complex data structures was one of the main reasons why the EDDL was created.

The classes Module, Headmodule, Extensionmodule and DEX-Format deal with the combination of data to be delivered cyclically between the device and its communication master and the physical configuration of a modular station.

5.1.3. CANOpen Electronic Data Sheet (EDS)

The EDS is a specification of the CANOpen user group for devices that conform to the CANOpen application profile built on the Controller Area Network (CAN) bus technology. It is a mix between the description of parameters designed for tuning/ application and communication settings. The analysis showed, that an EDS-file is a list of Objects which can be either mandatory, optional or manufacturer specific. Each Object has attributes the like of ParameterName, DataType or HighLimit. Object links are constructs which express dependencies between single objects. Additionally the EDS file has a Fileinfo block where data concerning the creation of the file can be assigned and a DeviceInfo block where the manufacturer data and the specific CAN communication parameters are described.

5.2. Analysis summary

In order not to be out of proportion, the analysis results of other fieldbus specific device descriptions shall not be displayed in this paper. The three examples showed, prototypically, the different kinds of the device descriptions that can be classified in:

• Generic language for parameters, values or variables

• Communication centric language with prefixed keywords covering explicitly the one fieldbus which it was designed for

• Mixed language which tries to integrate both aspects

The analysis has further shown, that the constructs of the languages can be sorted in two classes: fieldbus-independent constructs like data-type, maximum or minimum values on the one side, and fieldbus specific constructs like protocol- related addresses and state machine dependable timing parameters on the other side. Therefore the harmonization process focuses mainly on the fieldbus independent constructs, whose basic ideas differ only slightly: E.g. the construct variable with Type, MIN_VALUE and MAX_VALUE of the EDDL appears in the DDB as User-parameter with Data_Type, Min_Value and Max_Value and in the EDS as Object with DataType, LowLimit and HighLimit. The redefinition and unification of these constructs with the help of XML will result in the general device description schema that will be presented in the next chapter.

On the other hand, the fieldbus specific constructs have to be taken into account somehow. The solution idea here is to redefine the fieldbus specific keywords using the generic constructs of the harmonized variable construct and to deliver an anchor point for fieldbus specific addressing issues. This point will be solved by the introduction of fieldbus specific addressing schemas, that can be attached to the fieldbus independent description part. The goal of this procedure is to leave the gate open to the fieldbus user groups so they can implement their fieldbus specific schemas and insert them to the harmonized description.

5.3. Designing the harmonized model

According to the analysis results the design of the harmonized model will be presented in two parts. First, there will be the UML model for the fieldbus independent language features, then a generic model for the fieldbus specific schemas.

5.3.1. Communication independent classes

The Figure 5 shows that a device is modeled as a list of variables, VARLIST, which shall consist of so-called REALVAR constructs. The term was chosen in order to express that it shall describe device variables and not application variables, where variable shall be the super term for parameters, objects, user-parameters and values.

Figure 5: Classes of the harmonized model

In order to achieve a certain degree of unambiguousity regarding the relation between a VARLIST and a device, several general device informations, like the serial number range which the description shall be valid for are assigned to the the VARLIST class. Informations concerning the description file itself are tied to a FILEINFO class, which is adopted from the EDS model. Each REALVAR has general attributes which are members of the GENERAL_ATTRS class. These attributes build a superset of the attributes of the existing languages. Amongst others, they cover the DATA_TYPE, the SIZE, MIN_VALUE, MAX_VALUE and the STORAGE behavior of a REALVAR. On the other side each REALVAR possesses communication related attributes, in Figure 5 represented by the class COM_ATTR.

5.3.2. Communication dependent classes

The next step in the modeling process was the further dismantling of the communication attributes analyzing the existing languages and the important fieldbus standards. The result was the definition of the COM_ATTR class which comprise the definitions of the general communication architecture of the device, for example the name of the fieldbus supported or the application profile the device conforms to within this fieldbus system.

Figure 6: Fieldbus specific classes for Profibus

Further, the COM_ATTR class is the bracket for elements defined in fieldbus specific schemas which should be delivered by the fieldbus user groups. In Figure 6 the fieldbus implementations PROFIBUS and CANOpen are chosen as examples. Each of them are comprising their fieldbus details, e.g. for the Profibus world, the different addressing services DEX and ACYC. For other fieldbus systems there could be a totally different model below their deputy class, which is the reason the implementation shall be left to the fieldbus user groups.

6. The Varlist schema(s)

After the harmonized model was available, the implementation of the XML Schemas was a rather straightforward process. Using an example device, a temperature transmitter called TT59, the main features of the variable list schema, VarListV1_00.xsd, an example fieldbus schema adjusted to the Profibus system, ProfibusV1_00.xsd, and the device description instance TT59.xml will be presented. The description and schemas are designed using a self-written Java application that parses the XML code with the help of the Simple API for XML (SAX) functionality of the Xerces-J package of the Apache XML Project http://xml.apache.org .

6.1. Schema invocation

There are three files in the example, that have to be interconnected in some way. Figure 7 shows their relationship:

Figure 7: Schema invocation

The device description has to be valid regarding the main schema, VarList.xsd. In this communication independent schema, the fieldbus specific elements are referred to by inclusion of one ore more fieldbus schemas. In the example, only the Profibus.xsd is included, the inclusion of Canopen.xsd in the Figure 7 simply shows the simplicity of switching to another fieldbus system.

In order to tell the parser where the elements defined in the schema(s) can be found, the root element of the device description, VARLIST is bound to a namespace called http://www.itm.tum.de/2000/dekos. It is assigned the prefix vl. All globally defined elements of the invoked targetNamespace have to be qualified using this prefix. Further explanation of the targetNamespace can be found in [W3C00], its setup in the example can be seen in the schema definition below:

Codesample 1: Schema invocation and inclusion

TT59.xml:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!--root-Element is vl:VARLIST, with vl is defined by the given uri-->
<vl:VARLIST VENDOR = "itm" DEVICENAME = "xyz" SERNUMSTART="0" SERNUMEND="3" 
xmlns:vl="http://www.itm.tum.de/2000/dekos" 
xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance" 
xsi:schemaLocation="http://www.itm.tum.de/2000/dekos VarListV1_00.xsd">
...
		  

VarListV1_00.xsd:

<?xml version = "1.0" encoding = "ISO-8859-1"?>
<xsd:schema targetNamespace = "http://www.itm.tum.de/2000/dekos" 
xmlns:xsd="http://www.w3.org/2000/10/XMLSchema" 
xmlns="http://www.itm.tum.de/2000/dekos">
<!--Here, the example schema with the profibus constructs is included-->
<include schemaLocation="ProfibusV1_00.xsd"/>
<!-- Here, another fieldbus specific schema might be included -->
<!-- include schemaLocation = "XYZ-BusV1_00.xsd"/-->
<!-- Global declaration of VARLIST, the root element of the device description instance-->
<xsd:element name="VARLIST"> ...
		  

ProfibusV1_00.xsd:

<?xml version = "1.0" encoding = "ISO-8859-1"?>
<xsd:schema targetNamespace = "http://www.itm.tum.de/2000/dekos" 
xmlns:xsd="http://www.w3.org/2000/10/XMLSchema" 
xmlns="http://www.itm.tum.de/2000/dekos">
<!-- Declaration of the address structure for acyclic Profibus services-->
<xsd:element name="ACYC">...
		  

Further it is necessary to use the namespace of the XMLSchema-instance in order to access the schemaLocation attribute of it, where the parser can be told where to find the main schema file

As it can be seen in the codesample 1, the schemas fill the targetNamespace http://www.itm.tum.de/2000/dekos which the device description is using. When multiple schema are used with the help of the include element, all schemas have to have the same targetNamespace.

6.2. Details of the communication independent part

The VARLIST element has two subelements, FILEINFO and REALVAR which are defined globally in the VarList.xsd because there is the possibility that other description formats will use them in the future. Therefore they have to be prefixed with vl in the description instance. FILEINFO comprises some attributes that describe the state of the description file, the author and others and must appear exactly once in a valid description. REALVAR may appear in an unbounded number but at least once in every file. It is containing a description element DeKOSDESC which is, once again, defined globally for further use. The differentiation between the communication independent and the fieldbus specific components is mirrored in the declaration of the two sub-elements, GENERAL _ATTRS and COM_ATTRS, where the first one is covering topics like DATA_TYPE, the SIZE_IN_BIT and others. Codesample 2 shows the declaration and the instantiation of some general attributes:

Codesample 2: Some general attributes

TT59.xml:

...
<vl:REALVAR NAME = "TAG_DESC" VARNR = "VAR_1"> 
<vl:DeKOSDESC LANGUAGE="en"> 
<SPECDESC>Name tag of the device</SPECDESC> </vl:DeKOSDESC> 
<GENERAL_ATTRS> 
<VALUE>runtime</VALUE> 
<DATA_TYPE>string</DATA_TYPE> 
<SIZE_IN_BIT>256</SIZE_IN_BIT> 
<DEFAULT_VALUE>TT3</DEFAULT_VALUE> 
<ACCESS>readwrite</ACCESS> 
<STORAGE>static</STORAGE> </GENERAL_ATTRS> ...
		  

VarListV1_00.xsd:

...
<xsd:element name = "GENERAL_ATTRS" minOccurs="1" maxOccurs="1"> 
<xsd:complexType> 
<xsd:sequence> 
<xsd:element name="VALUE" type="xsd:string" minOccurs="0" maxOccurs="1"/> 
<xsd:element name="DATA_TYPE" minOccurs="1" maxOccurs="1"/> 
<xsd:element name= "SIZE_IN_BIT" type="xsd:unsignedShort" minOccurs="1" maxOccurs="1"/> 
<xsd:element name= "DEFAULT_VALUE" type="xsd:string" minOccurs="0" maxOccurs="1"/> 
<xsd:element name= "ACCESS" type="accessType" minOccurs="1" maxOccurs="1"/> 
<xsd:element name="STORAGE" type="storageType" minOccurs="1" maxOccurs="1"/> 
</xsd:sequence> </xsd:complexType>
</xsd:element>
<!--Definition of the type storageType, which describe the means of handling
variable values -->
<xsd:simpleType name="storageType"> <xsd:restriction base="xsd:string"> 
<xsd:enumeration value="dynamic"/> <xsd:enumeration value="static"/> 
<xsd:enumeration value="constant"/> </xsd:restriction>
</xsd:simpleType> ...
		  

The element storage is of an user defined type called storageType. The definition of this type as an enumeration based on strings is shown at the bottom of the codesample in order to give one example on how element content can be constrained easily and precisely with a schema definition.

6.3. Using fieldbus specific elements

In order to be able to use different fieldbus specific elements declared in the different fieldbus schemas, the definition of COM_ATTRS contains the generic element any. Its attribute namespace is used to constrain the set of elements to a certain namespace, in the example it equals the targetNamespace http://www.itm.tum.de/2000/dekos. The description instance in the example uses the element ACYC which is declared globally in the Profibus schema and describes the addressing structure of an acyclic service in the Profibus communication system which has to be used when accessing the REALVARs defined in the description file:

Codesample 3: Fieldbus specific element ACYC

TT59.xml:

...
<COM_ATTRS FIELDBUS="PROFIBUS"> 
<vl:ACYC PROFILE="PAV3.0"> 
<BLOCK TYPE="FB" NR="1" CLASS="AI"/> 
<SLOT>2</SLOT> 
<INDEX>13</INDEX> 
<PROFIBUS_DATA_TYPE>DS10</PROFIBUS_DATA_TYPE> 
</vl:ACYC>
</COM_ATTRS> ...
		  

VarListV1_00.xsd:

...
<xsd:element name = "COM_ATTRS" minOccurs="0" maxOccurs="1"> 
<xsd:complexType> 
<xsd:sequence> 
<xsd:any namespace="http://www.itm.tum.de/2000/dekos" minOccurs="0" 
maxOccurs="1"/> 
</xsd:sequence> 
<xsd:attribute name = "FIELDBUS" type = "fieldbusType" use = "required"/> 
</xsd:complexType>
</xsd:element>
<!--Definition of the type fieldbusType, has to be updated if new fieldbus 
specific schemas are available -->
<xsd:simpleType name="fieldbusType"> 
<xsd:restriction base="xsd:string"> 
<xsd:enumeration value="PROFIBUS"/> 
<xsd:enumeration value="CANOPEN"/> 
</xsd:restriction>
</xsd:simpleType>
		  

The sub-elements of ACYC describe the domain namespace of the Profibus system. E.g. the information about SLOT and INDEX allows a Profibus master to execute a read service on the variable, the PROFIBUS_DATA_TYPE is the data format that is used for the transmission over the physical interface. Codesample 4 shows the declaration of some elements in the Profibus schema:

Codesample 4: Declarations in the profibus schema

Profibus.xsd:

...
<xsd:element name = "ACYC"> 
<xsd:complexType> 
<xsd:sequence> 
<xsd:element name ="BLOCK" minOccurs="0" maxOccurs="1"> 
<complexType> 
<xsd:attribute name="TYPE" type="blocktypeType" use="required"/> 
<xsd:attribute name="NR" type="xsd:unsignedShort" use="required"/> 
<xsd:attribute name="CLASS" type="classType" use="required"/> 
</complexType> 
</xsd:element> 
<xsd:element name="SLOT" type="xsd:unsignedShort" minOccurs="1" maxOccurs="1"/> 
<xsd:element name="INDEX" type="xsd:unsignedShort" minOccurs="1" maxOccurs="1"/> 
<xsd:element name="PROFIBUS_DATA_TYPE" type="profibusdatatypeType" 
minOccurs="1" maxOccurs="1"/> </xsd:sequence> 
<xsd:attribute name="PROFILE" type="xsd:string" use="optional"/> 
</xsd:complexType>
</xsd:element>
<!-- Declaration of the Profibus data types -->
<xsd:simpleType name="profibusdatatypeType"> 
<xsd:restriction base="xsd:string"> 
<xsd:pattern value="DS\d{2}"/> </xsd:restriction>
</xsd:simpleType>
		  

The example showed, that the Profibus schema is not only useful for declaring elements to be used in a harmonized device description, but has also the potential to be re-used e.g. to re-formulate parts of the Profibus standard. Especially the type definition profibusdatatypeType where the pattern facet of the simple type xsd:string is used shows the precise and formal approach of the XML schema definition.

7. Use and Outlook

There are several Use Cases during the life cycle of a field device and a plant, where the presented technology can ease the tasks of developing and engineering, thus reducing the Cost of Ownership. The finishing chapter of this paper describes some of these use cases by example.

7.1. Firmware development of a new device

During the design and implementation of the firmware for field devices, the parameters and values which shall be set and obtained by the end user have to be defined in the RAM and/or ROM area. In this early stage, the firmware developer already can set up the variable list, declaring the variable names and the general attributes. He can do this simultaneously to the development process or even before the start of programming. In doing so, parts of the firmware, which today is generally developed in the C programming language could then be generated using the Extensible Stylesheet Language Transformations (XSLT) language. In both procedures, the variable list represent already a very big part of the device description which later is to be delivered with the field device. During the implementation of the fieldbus specific hard- and firmware the variable list is the starting-point for filling in the communication specific attributes like addresses and special data transmitting parameters.

7.2. Adaptation of a field device to another fieldbus

If a manufacturer wants to adapt an existing field device, equipped with a certain fieldbus interface to another fieldbus system, he has to replace the fieldbus hardware and firmware on the board. If designed according to the state of the art, the device function part can be preserved with minor changes. The person responsible for writing the new device description now can take the existing fieldbus independent part of the variable list, and, after referring to the new fieldbus specific schema, has to adapt the communication parameters and addressing schema according to the new fieldbus specification. The reusability of the general part leads to decreasing costs and increasing consistency.

7.3. Tuning of the device at the end user

The task of the end user in the commissioning process of his plant is to operate all the field devices of different types and manufacturers with the help of software tools. The description of the device capabilities in one open and harmonized format allows him to decrease his cost of ownership dramatically. Not only can he reduce the diversity of fieldbus specific tools, he can also reduce the effort on staff and training, which currently represents a massive share of the overall engineering and maintenance costs. Beyond these direct savings, the effort for administrating, storing and updating device descriptions can be massively reduced. Due to the simple format, the possibilities of searching and distributing XML files over the Internet, the full power of the proposed solution comes through.

7.4. Outlook

The solution proposed in this paper was implemented at the institute for information technique in mechanical engineering. It shows, that the harmonization of the device descriptions is a must if the new technologies within the field devices shall have the promised effect on the production costs. To simply define of a new description language, even if it would be with XML, would not be accepted by the users, manufacturers and fieldbus user groups. The concept of dividing the description in two parts, a device specific one and a communication specific one suits all three points of view: The users profit by receiving files that are valid to one harmonized format, the manufacturer has the possibility to use the language as a design tool and therefore to gain greater reusability without touching or opening his USP and the fieldbus user groups are assured they can insert their specific functionality and behavior which differentiates them from others. All groups are invited to apply this harmonized language.

Design and Development by deepX Ltd.