Using XML in Distributed Real Time Automation Processes in the Textile Industry

1. Introduction

Presenting an example taken from the textile industry we demonstrate some important aspects of XML technology which they have to industry. The textile market is considerably large: there are over 10 thousand dyehouses all over the world. The future market for such systems is over 10 billion dollars. The key idea is to connect different manufacturers, their data, tools and other products using XML. The picture below shows the different vertical levels of business fields for the production and usages of textile machines.

I will show, why and how XML is the connection technology for textile industry. The decision for a technology is a crucial step especially for small companies, as TLON GmbH is. Let me explain why TLON decided for XML and how we use this fascinating technology in all phases of the life cycle of a real time process automation system.

This life cycle consists of different phases: In the first one, the design phase, the architect engineer designs the system. Next the system integrator installs, binds, and configures all devices. The last phase consists of ensuring that the plant works, i.e. maintenance and diagnostics.

Many people are involved in these phases. They use different tools and the problem is, that the used tools are incompatible in most cases. So, everyone who must continue the work of the previous engineer must create new data and can't use the already created documents So, what can we do? The solution is XML! With this technology, TLON builds a framework, called 'Infranet Framework'. With the term 'Infranet' we describe the distributed networked control automation systems we use for process control and other control automation systems. This presentation shows how we connect all participating tools together by using XML.

But XML can do even more for us. We create a representation of the whole automation systems as an XML file, containing information about all used devices, their internal object structure (standard LonMark object types), their public attributes (called network variables in LonWorks terms) and configuration properties. It is a complete description of the structure of the system. This XML file is the key for all further work, as we can it e.g. for diagnostics and maintenance (protocol analyzer and other diagnostic tools), and for remote visualization and control access using HTTP, SMS and Fax services. We use a second XML file for the description of the dynamic behavior, containing e.g. logging information and statistical data. The Infranet Framework is absolutely unique in our business. I will show the usage and the structure of the framework on a dyeing machine for textiles. We deliver this control solution using LonWorks technology, which is out main business and the root of our company.

2. The strucure of a dyehouse

If we are looking at a typical dyehouse, we see a system, which consists of different levels. The upper level is the Internet, a technology for the communication between different dyehouses. They use the Internet for orders of material, invoicing and maintenace, customers contact, and marketing.

The mid level is the Infranet. It is used for the inter-company information exchange, like development and accounting. What about the lower level? This level contains the components which really do the job, the dying machines. These machines are connected using a system we call Infranet. This is an acronyme for Infrastructure Network and means, that we have components which are able to communicate with each other. In our company, we use the LonWorks® technology from the american company Echelon as the communications network. With this distributed intelligent networking concept each component device is given its own intelligence. See the figure below for the communication structure of a typical dyehouse.

As you can see in the picture, the three levels of the communication system mentioned before cannot work without exchanging information. Most information contained in the initial orders is also useful in the Infranet layer. On the other hand, errors occuring in the Infranet layer, e.g. the malfunction of a control system component, automatically trigger a process that consists in gathering the failure description, the faulty components' identification data, supplier name, exact location, time of failure, etc. and sending it to a service company via internet using XML-RPC.

3. The platform for manufacturing enterprises

TLON GmbH actively joins the European Communitys 'BURMA-X' project, which constitutes an integrating R and D effort, seeking to develop and validate a unique, knowledge based Web platform for extended manufacturing enterprises. Traditional organisational forms don't seem to support competitiveness of SMEs in the global market. The emergence of the Internet eases the creation of Extended Enterprises, which increases the competitive capabilities of SME's and creates value for all supply chain partners. The user consortium, a characteristic supply chain, has recognised the need of the extended enterprise concept in order to facilitate the following:

1. Development and production across company boundaries.

2. Provision of high level after sales services, even if components have been produced by partners.

3. Definition and easy execution of cross organisational business processes.

The BURMA-X consortium will support the operation of extended enterprises with an adequate communication platform that contains:

1. Integrated suitable technologies that makes up an Internet portal for the extended enterprise.

2. Additional functionality fitting the requirements for cross organisational collaboration

3. Suitable process interfaces for cross organisational business process interoperability.

The consortium focuses on industrial and de-facto technology standards in order to ensure the widest applicability possible. This way BURMA-X will result into a holistic business relationship management portal for extended enterprises. The efficiency of the research will be ensured by a sound organisational structure, which is supported by the newest project management methods and tools. This structure is well tested by amongst others CAS Software and perfectly fits R and D projects. Finally IT architectural issues have been resolved in preceding projects, especially when concerning distributed infrastructure. State-of-the art methods and tools however don't fulfil the requirements for the different collaboration phases in the extended enterprise like, development, production and organisation. In order to develop a fitting solution for the extended organisation the consortium has defined a number of partial, measurable objectives:

1. Development and validation of an interoperable collaborative internet portal (set of interoperable applications like scheduling, project management...). The portal will support essential business processes and maintain a Knowledge Base for the extended enterprise.

2. Development, validation and integration of a Management Information system (MIS) for the extended enterprise, including controlling, reporting and stock tracking functionality.

3. Development and validation of an organisational framework for effective networking of organisations.

4. Creating large scale validation and enabling future business opportunities by integrating an Interested User group.

The user consortium makes up a supply chain for manufacturing of dye-machines and consists of six companies in four European countries (D, FIN, UK, CH). Currently the participating companies co-operate succesfully, however they recognise business opportunities by implementing the extended enterprise concept. The developer consortium will develop the technological platform for business relationship management within the extended enterprise. In the figure below you see a typical supply chain on which the project is focused.

4. XML as the basic technology

In the previous sections we saw that the information exchange is fundamental for the connection of the different components in a dyehouse. As we have components from different manufacturers whith different functions and data, the question arises, how they can be connected to each other? We can gain tremendous benefit from using XML for the interconnection of these components. In detail, we use XML for the description of the functionality of the components and of the data they provide. This results in a collection of XML files, which are used by the components and are transfered between them using an XML message based protocol like XML-RPC (SOAP could also have been used for this purpose). The figure below illustrates this idea using an example from the Infranet level.

A dyeing machine consist of different components. These are e.g. the tanks and the fabric run. Each component also consists of components. In our example, the fabric run includes one or more frequency inverters. Each frequency innverter includes a winch and a blower. These components are connectible, i.e. they can communicate to each other. An XML based description of a component must include descriptions about:

• the hardware (processor type, electrical properties)

• the functions the components can fulfill (e.g. open, close, ...)

• the connections of this components

The last point means, that the components are bound to each other. They know the addresses of the components they should send information to and the structure of the data to be sent. The bindings are a LonWorks® unique feature and are created using an XML based LonWorks® network management tool like TLON Pathfinder. PathFinder is a generic network management tool for projecting, installing and maintaining LonWorks networks. It is built upon the network service layer of Echelons LNS network operating system and thereby offers optimized functionality. PathFinder has a quite easily usable GUI (Grafical User Interface) and uses Microsofts OLE standard (Object Linking and Embedding) for project administration, graphically visualized binding network variable browsing and adaption to user needs by writing device specific control plugins. Network variables are a LonWorks specific feature too. From the device programmers view they are a special kind of variables that are shared with other device programs, from the network integrators view they are the devices' public interfaces which can be arbitrarily interconnected to establish communication paths.

The following figure shows a part of the network.xml file. This file holds the description of all components in our network as well as of all connections.

I will explain the contents of the network.xml file more in detail. First, here is the description of the hardware of a component. In LonWorks® we call a component a 'node'.

<sNodeName>Kello_LJH</sNodeName>
<hNode>1</hNode>
<sLocationName>4c 4a 48 00 00 00</sLocationName>
<dFirmwareVersion>3</dFirmwareVersion>
<dUserFlags>0</dUserFlags>
<eStatus>CURRENT</eStatus>
<bNMAuth>DISABLED</bNMAuth>
<dNGRcvTimer>5</dNGRcvTimer>
<dNumSubnets>1</dNumSubnets>
<hNeuronId>01 00 4d e5 2b 00</hNeuronId>
<hChannel>2</hChannel>
<dPriority>0</dPriority>
<sProgramName>L501V2A1</sProgramName>
<eNeuronType>3150</eNeuronType>
<dMaxAddress>15</dMaxAddress>
<dMTSlots>0</dMTSlots>
<sSubnetName1>sub0</sSubnetName1>
<sDomainName1>Suonio7</sDomainName1>
<sSubnetName2/>
<sDomainName2/>
<dSubnetId>2</dSubnetId>
<dNodeId>7</dNodeId>
<dSubnetId2>-1</dSubnetId2>
<dNodeId2>-1</dNodeId2>

You see the name of the node, the Neuron Id (a globally unique address of the device), the proccessor type (3150) and some addressing information. The program name (sProgramName) identifies the program which runs on the node. Every byte has a special meaning for a functional object. These data describe almost everything which is important about a node. Every node can have up to 63 network variables (NV). The description of the NV is also a part of the description of the node.

<NV>
  <sVariableName>nciDefault_prc</sVariableName>
  <dIndex>48</dIndex>
  <dNumConns>0</dNumConns>
  <dSelector>16335</dSelector>
  <eServiceType>ACKD</eServiceType>
  <eDirection>INPUT</eDirection>
  <bOffline>0</bOffline>
  <bBindable>0</bBindable>
  <bCnfgService>0</bCnfgService>
  <bAuthentication>0</bAuthentication>
  <bCnfgAuth>0</bCnfgAuth>
  <bPriority>0</bPriority>
  <bCnfgPriority>0</bCnfgPriority>
  <bPolled>0</bPolled>
  <bSync>0</bSync>
  <bConfigClass>0</bConfigClass> 
  <dNumFields>1</dNumFields> 
  <eSnvtType>81</eSnvtType> 
  <dTypeSize>2</dTypeSize> 
  <dUnionSize>0</dUnionSize> 
  <eUserType>0</eUserType> 
  <bTurnaround>0</bTurnaround> 
  <dAddrTarget>0</dAddrTarget>
</NV>

Interesting information about the NV includes their name, type, size, and direction (input or output). And the last thing are the connections between the NVs.

<Connection> 
  <sName>pk16aika1_1</sName> 
  <ConnMembers> <ConnMember> 
  <hNode>1</hNode> 
  <dIndex>9</dIndex> 
  </ConnMember> <ConnMember> 
  <hNode>3</hNode> 
  <dIndex>18</dIndex> 
  </ConnMember> </ConnMembers>
</Connection>

Every Connection can have up to 25 members. It consists of a name and the collection of the connection members, each identified by the Id of the node and the connected NVs index on the node.

5. Bringing the information together - the Infranet framework

The Infranet Framework we built is a system for efficient data exchange. Several components use the information about the network and its behavior. The figure below shows the components of the Framework.

The center of the framework is the network.xml file. This file can be created in different ways. Network management tools, like TLON Pathfinder can create it. Converter tools can translate it out of legacy databases. Even long time existing networks can be explored using a scanner tool which creates the network.xml file.

The report tool creates a report about the network. It uses a script file, which is written in one of the available Windows Scripting Host scripting engines. The output of the report tool is either a XHTML file, a collection of XHTML files, a WinWord file or a Microsoft Excel file. But the opportunities are unlimited by using a scripting language. The contents and the design of the report are completely described in the scripting file. And the result is a file which can be edited further with the appropriate editor.

The next tool which uses the network.xml file is the protocol analyzer HSPA. It collects all packets transferred on the network. The problem is, that these packets don't include information about the sender and receiver except the addresses of them. If a NV is sent the packet has only the index of the NV but not its name. And here we use the information of the network.xml file. As we saw in the section above, the network.xml has the names of the nodes and the NVs. A converter tool converts the network.xml to a format the HSPA can unterstand.

We built a 2D/3D visualization tool. It shows the nodes and their connections via NVs. It is written in Java and therefore platform independend. You can zoom, move the nodes, and export the graphic into a SVG file. You can edit this SVG file with tool like Trajectory Pro from Jasc Software. The report tool can combine the Layout.xml file (SVG format) and the network.xml in its reports.

Another important XML file is the diagnostic.xml. It contains information about the actual status of the network, about alarm, events etc. This file is created by the HSPA and can be used for further diagnostics and status reports. Tools like the Traffic Calculator are based on this diagnostic.xml file tool and can be used for prediction of the network traffic, which is a very important information for diagnostics and maintenace.

6. Conclusion

We saw, that XML is the best technology for information exchange when all levels of networking must be covered. Descriptions of components as XML files allow tools and users in different departments and with different tasks an easy and flexible access to the information they need.

We have many tools which are interoperable since we are using XML as the basis for information and data exchange. In the future we will replace almost every data format which is used in our company with XML. Inspite this is a difficult step we plan to shift within one year. Since we have recognized XML to be the most promising approach for interoperability we are committed to this technology and use it wherever possible.

Design and Development by deepX Ltd.