CALCUTTA: PROPOSED PACKAGE OF OBJECT COMPONENTS FOR DEVELOPERS OF INDUSTRIAL SYSTEMS AUTOMATION APPLICATIONS

Introduction

The use of components is a widespread practice in developing applications, especially for business applications. The use of reusable components promotes generality and simplicity within organizations, perhaps even across organizations. Reusable components reduce the effort spent in system level testing for the application. They allow for consistency in documentation and provide a level of application stability that is far more expensive to achieve if applications are developed, so to say, from scratch.

The above advantages of reusable components bear a greater significance for mission-critical applications, and industrial systems automation applications form the bulk of such applications. While industrial automation projects often need a high degree of reliability they are often unable to bear the high cost involved in achieving the same. The availability of a package of object components specially suited for automation projects may provide for such a solution at a significantly reduced cost of development. Unfortunately, most component libraries available today focus on business applications, completely neglecting the domain of industrial applications. The use of components in industrial applications is seen to a limited degree in the proprietary software packages developed by some of the automation giants like ABB, Siemens, Toshiba and Voest-Alpine. However, no such library seems to be readily available that is readily portable across all platforms and interfaces hardware components of a large cross-section of the industry. The proposed Calcutta Suite aims to fill this gap.

The name, Calcutta, was chosen for two reasons. Firstly, it is the author’s home and the author has a special attachment to it. Secondly, Calcutta, which is a city in India, is the focal point of a very large number of manufacturing industries that are possible users of the proposed Calcutta Suite. This paper describes the architecture of the Calcutta Suite and describes briefly the many components more pertinent to industrial automation applications. This paper also contains a case study on the automation of the LD process for manufacturing steel in a typical steel factory. The author has used his experience in a similar automation using Digital VAX as a central processor, and proposed a new implementation using Calcutta Suite and CORBA as part of this case study.

Problem Statement

Most industrial automation applications involving supervisory control have three distinct capabilities. They need to interact with instruments (acquiring data and issuing control instructions), interact with human operators and interact with enterprise level systems to send or receive broader policy directives.

The interaction with instruments is by far the most important and mission-critical of the three capabilities that are sought from automation applications. Data acquisition is expected to be fault tolerant. Applications may not skip the processing of data that is being fed synchronously from an instrument nor may it ignore an event that is triggered asynchronously, that is via an appropriate interrupt from an instrument. The application is expected to deliver control signals to instruments in a timely fashion. A failure to do this can result in significant damage to life and property in several situations. Any component package specially catering to the automation industry, therefore needs to provide fault tolerance and redundancy in all facets that deliver this capability.

The interaction with human operators, although not as mission-critical as the interaction with instruments, is nevertheless a significant capability, and a very high degree of reliability in such interaction is imperative, if not mandatory, for the component package that is within the scope of this paper. The application is expected to be able to acquire information from various instruments, either by repeated or on-demand requests (interrupts), or from reading from a buffer where the data is being stored since the instrument is delivering it to the application synchronously. The application is then expected to be able to provide this data to the operator, in a form that is readily comprehensible to the operator. The application is also expected to have the capability of sounding alarms when this data indicates abnormal and potential hazardous states. A good example of such capability includes the ability to sound an alarm when the temperature in a certain area becomes abnormally high or low. The mission critical nature of the capability of interaction with human operators is highlighted when it comes to the application’s ability to translate instructions from the operator into control signals for instruments. Failure to do so may result in significant damage to life and property in several situations.

The third capability, the interaction with enterprise level systems, is the least mission-critical. This capability usually allows the application to obtain direction from enterprise level systems that may be conveyed to the operator and used by him/her to make certain policy decisions. This capability also allows the application to send data to enterprise level systems that may be interpreted in various ways, chiefly in the form of reports and spreadsheets. This capability does not need fault-tolerance or redundancy. However, this capability lends the application for interfacing with enterprise wide applications and always is an added plus.

The Technical Analysis section covers how these three capabilities are built into the proposed Calcutta Suite and some other component suites that are currently available.

Technical Analysis

Based on the three desired capabilities identified in the Problem Statement section, components in any package for industrial automation may be divided into the following three groups:

· Instrument Data Handler Components

· Operator Console Components

· Enterprise Interface Components

Instrument Data Handler Components

The generic instrument data handler (IDH) component consists of an event handler and a virtual instrument. The event handler remains in a wait state until it receives a message from either the virtual instrument associated with it or from an operator console component. The event handler may send a message to either its associated virtual instrument or an operator console component. The event handler contains a finite state automaton that remembers its state and calls one of its array of functions (which relate directly to the current state of the event handler) to handle an event. The execution of this function may possibly change the state of the event handler.

The generic instrument data handler (IDH) component definition provides for an interface for the virtual instrument. A virtual instrument object, which is essentially a wrapper around the functions that communicate directly with the physical instrument, implements this interface, thereby implementing a host of functions that will satisfy commonly used instrument data handling functions. Some of these functions may be dummied out to emulate the necessary asynchronous or synchronous nature of the instrument. Additional functions may be built to provide for special cases that are specific to a certain instrument.

A possible definition of the IDH Virtual Instrument interface is as follows:

public interface VirtualInstrumentEssentials

{

public returnValue getDataSync();

public returnValue getDataAsync();

public returnValue putDataSync(instrumentData i);

public returnValue putDataAsync(instrumentData i);

}

A possible implementation of the IDH component interface for an instrument that needs to be interrupted for reads and writes can be as follows:

public class asyncVirtualInstrument

extends PhysicalInstrument

implements VirtualInstrumentEssentials

{

public returnValue getDataSync()

{

return(ReturnValue.convertFromText(“No sync. Comm.”);

}

public returnValue getDataAsync()

{

/* Carry out necessary functions for asynchronous

communication */

}

public returnValue putDataSync()

{

return(ReturnValue.convertFromText(“No sync. Comm.”);

}

public returnValue putDataAsync()

{

/* Carry out necessary functions for asynchronous

communication */

}

As mentioned in the Problem Statement section, the IDH components are the most critical in the entire package and require a certain degree of fault tolerance and redundancy in certain cases. Many instruments come with redundant interfaces and it should be possible to have multiple virtual instruments, in other words, a virtual instrument for each redundant interface. This calls for a specialized IDH that has an event handler capable of simultaneously handling multiple virtual instruments. When sending information to the instrument, the event handler may do the following:

· It may send information through one virtual instrument only, unless it encounters an error or failure when it would switch to using another virtual instrument.

· It may randomly send information through any virtual instrument. This process may only be implemented if it is known for fact that the physical instrument is able to consume information written unto its buffer, faster than it can be written, failing which it can lead to ambiguous data. This problem is usually not encountered because larger instruments like distributed process control systems often include (and expect) time stamps as part of their data packets.

· It may maintain a database on the reliability of various virtual instruments and route its packets accordingly to the most reliable virtual instrument. This is by far the most expensive of the three methods and should be used only where an extremely high degree of reliability is required.

In the case of an event being transmitted by an instrument to the event handler, special care has to be taken to ensure that events are received and processed by the event handler in the right order. This raises a question that if events are received in incorrect order, how does the finite state automaton react? Let us say event E2 was received when the event handler was expecting event E1. It may be assumed that E2 would be either incorrectly processed or rejected all together, sending the finite state automaton into an unpredictable state. A possible, but extremely complex workaround may be to retain rejected events, but such level of complexity in the event handler is very likely to fail besides the fact that it would slow down the process due to the significant larger volume of computation. We can therefore surmise that such an event cannot be handled by the IDH with a single event handler and multiple virtual instruments, unless it can be safely established that the event handler is able to receive and consume data faster than it can be written by the physical instrument. In most industrial systems, this case is true and the complex IDH may be easily employed to provide redundancy.

Operator Console Components

Operator consoles for industrial automation systems have special needs that are not necessarily met by general-purpose graphical user interface components. This is largely due to the different nature of the hardware used for operator consoles.

Unlike users of regular business applications, operators of industrial processes do not have the luxury of being able to sit at one place and use a terminal with a mouse to click at buttons, radio buttons or use drop down menus. Operators often find it convenient to use touch screen controls and voice operated controls.

Calcutta Suite provides for a variety of GUI components that are typically suited for touch screen operations. There are special classes that allow for touch screen vertical and horizontal scroll bars, radio buttons and buttons. These classes are essentially extensions of their counterparts in the Swing suite with special methods to incorporate touch screen functionality. These components have, in addition to the existing events defined in the Swing suite, methods like fingerTouched and fingerMoved, that provide for added functionality to these classes.

In addition to these components, Calcutta Suite provides for some other components that are typically used in industrial automation systems. A good example is the AnalogMeter, which provides a virtual analog meter, a display form that is sometimes preferred over a digital display for certain types of data.

A skeleton implementation of the AnalogMeter class is as follows:

public class AnalogMeter extends OperatorConsoleComponent

{

StringBuffer name;

StringBuffer unit;

Double minimum;

Double maximum;

Double alarmLow;

Double alarmHigh;

MeterSize size;

Double currentValue;

/*Default constructor */

public void AnalogMeter() {};

{

}

/*Generic constructor with individual elements */

public void AnalogMeter (StringBuffer _name,

StringBuffer _unit,

Double _minimum,

Double _maximum,

Double _alarmLow,

Double _alarmHigh,

MeterSize _size)

{

}

/*This constructor sets the low and high alarms outside the range of the meter thereby deactivating them. Methods to set alarms may be used to change or activate these alarms */

public void AnalogMeter(StringBuffer _name,

StringBuffer _unit,

Double _minimum,

Double _maximum,

MeterSize _size)

{

}

/* This method may be used to set the value of the meter */

public void setMeter (double _currentValue)

{

}

/*This method is used to set the lower limit alarm */

public void setAlarmLow (double _alarmLow)

{

}

/*This method is used to set the higher limit alarm */

public void setAlarmHigh (double _alarmHigh)

{

}

Enterprise Interface Components

Tertiary users of industrial systems include enterprise-wide users, possibly upper management, who do not have to interact with either the machine or directly with the actual manufacturing process but are interested in processing so-called production data to generate information that can be used in comparatively higher level policy and decision making. The most common output from such processing is usually a bunch of reports in most enterprises.

Largely most application development frameworks usually support this functionality, especially because this functionality is indeed the least unique of all functionality in industrial systems. Usually there exists a database object that is a repository of “production” information populated with information that is received, either automatically or on demand, from operator console components or instrument data handler components. This database is then used to generate reports, charts and graphs, and also used to generate broad directive messages that may be transmitted to operator consoles.

The Calcutta Suite framework allows for the use of a wide variety of databases like Microsoft Access, Microsoft SQLServer, Oracle, etc. using Enterprise Java Beans (which inherently uses JDBC). The data in this database can be used to produce reports and spreadsheets that may be exported to commonly used text-processing utilities like Seagate Crystal Reports, Microsoft Excel and Lotus SmartSuite.

Enterprise Interface components may also be used to produce reports and messages for mobile instruments using Wireless Application Protocol (WAP). This is of special interest to mobile enterprise wide users, for example truck and train crew within large factories who may need information on the move to effectively transport material across the plant.

Case Study: Automation of a steel melting shop using the Calcutta Suite

This case study is based on an automation project that the author had the privilege of working on very intimately between 1992 and 1994. The computer of choice at the time was a Digital VAX 3400 cluster which had remote terminals spread out within a radius of a mile to effect the automation and interfaced with a large number of instruments like a Toshiba TOSDIC 287 Distributed Process Control System, ABB Programmable Logic Controllers, ABB Crane Weighing System, Voest-Alpine TTCMG (an instrument that reported the temperature and carbon content of molten steel), Philips x-ray spectrometers and interacted with an enterprise-wide local area network for reporting purposes. This case study assumes that all the field instruments remain identical, but the VAX 3400 cluster has been replaced by a system consisting of Windows NT workstations and a Sun Microsystems SPARC server over an enterprise-wide intranet.

The steel melting shop of this steel plant uses the LD Process for manufacturing steel from molten iron produced in the blast furnaces. The LD process entails blowing oxygen through a pipe called a lance, into the molten iron that is contained in a vessel called the LD converter. The oxygen reacts with the carbon, phosphorus and sulfur in the impure molten iron producing carbon dioxide, phosphorus pentoxide and sulfur dioxide. The oxygen is blown until the right level of carbon is achieved for the specific grade of steel. This process is extremely exothermic and therefore some coolants like lime and scrap steel are added. Lime reacts with the oxides of sulfur, carbon and phosphorus and floats to the top as slag, removing all impurities. Also, Ferro-alloys are added to achieve compositions of specific grades of steel. This process is extremely fast and economical and produces very high quality of steel. However, the speed with which the process is executed makes it very difficult to control. This is exactly where the need for a fully automated manufacturing process becomes imperative.

The two main raw materials for this process are the molten iron, referred to as hot metal, and stored in a series of mixers much like the asphalt or concrete mixers that keep turning to keep the metal from solidifying, and scrap steel which are kept in a scrap bay. The storage area for both materials therefore need operator consoles that may be built using the operator console components and some instrument data handler components.

The mixer bay has three instrument data handlers – one for the ABB Crane Weighing System that measures the weight of the hot metal being tipped into what is called a ladle, one for the Voest-Alpine DigiTemp instrument that periodically measures the temperature of the hot metal in the mixers and one for capturing the result of the periodic analysis of the hot metal that is performed by a Philips x-ray spectrometer. The console provides graphical display of various mixers and allows for the accounting of the mixer bay inventory. The operator console also receives instructions from the Production Planning & Control room as to what quantity of hot metal may be required.

The scrap bay has one instrument data handler for the ABB Crane Weighing System that measures the weight of scrap steel being carried by the magnetic cranes either from wagons and trucks into the scrap bay or from the scrap bay into the scrap boxes that are loaded and eventually emptied into the converter. The console provides graphical display of the various chutes that are used for storing the different kinds of scrap steel and allows for the accounting of the scrap bay inventory. There are also graphical displays of the scrap boxes the information of which is shared between the scrap bay and Production Planning & Control.

The most vital console in the entire process is in the converter control room. The operator here controls the movement of the converter itself. The converter moves between four different positions, for loading, blowing (term for when the oxygen is actually “blown” into the hot metal, de-slagging and unloading. Also the converter has a large number of hoppers above it which are used to add lime and other additives and also for the addition of ferroalloys. The Toshiba Distributed Process Control System directly controls the converter. Therefore, there is an instrument data handler for the Toshiba DPCS. The console receives information regarding

· the converter position,

· the oxygen blowing status (oxygen pressure and volume and the depth of the “lance” which impacts the quality of the steel produced),

· status of the additive hoppers and sends the so-called “blow regime” which is a series of instructions to the DPCS to blow oxygen at a certain pressure at a certain depth for a certain duration.

The console sends instructions to

· open and close various hoppers

· move the converter

The following steps are performed by the operator console in the converter control area.

· The operator receives instructions from Production Planning & Control for producing a certain grade of steel. This information is displayed on the console screen.

· The operator console transmits this information to an object that uses a statistical model to predict the raw material requirements for this grade of steel.

· The operator console receives the raw material requirements from the statistical model object.

· The operator console then prompts the operator to select the most appropriate loaded scrap box by displaying all loaded scrap boxes which it obtains by interacting with the operator console in the scrap bay and helps decide on a certain amount of hot metal that needs to be ordered.

· The operator selects the orders and the console transmits the order to the console objects in the scrap bay and hot metal bay.

· The converter console receives notification of the raw materials released by the scrap bat and the hot metal bays. The scrap bay and hot metal bays dispatch the requested raw materials by rail, which are received in the converter area.

· The raw materials are then loaded into the converter and the event is transmitted to the converter console.

· The converter console again transmits all the information about the raw materials loaded to the statistical model object.

· The statistical model object then transmits the blow regime and the additive regime back to the operator console. Once the regimes are available, the console prompts the operator to initiate the blow.

· As soon as the operator initiates the blow, the console transmits the regimes to the DPCS, which sends the appropriate signals to various stepper motors and other switches to actually initiate the mechanical process.

· While the “blow” is on, the console object closely monitors the DPCS signals and displays all relevant data on the console screen. If any value reaches alarming proportions, the relevant audio or visual alarms are sounded.

· The console halts the blow when it is about 90% complete, and sends instructions to the DPCS IDH to de-slag, then it instructs the laboratory analysis probe IDH to take a sample and transmit it to the Philips x-ray spectrometer IDH, also it initiates the Voest-Alpine TTCMG IDH to measure the temperature and oxygen content in the contents of the converter. Then it waits for this information to be transmitted back.

· The console receives the information from the spectrometer and TTCMG and sends the same for a third time to the statistical model object and receives corrected regimes for the remaining 10% of the blow.

· At the end of the blow, it again requests the laboratory probe IDH and TTCMG IDH to analyze the composition of the steel produced, and if it falls within the range of the desired grade, it sends request to the DPCS IDH to unload.

· If the desired grade is not achieved the console requests the statistical model object to transmit another regime and continues with additional blows until the desired grade is achieved.

The DPCS communicates with the supervisory system (in our case, the DPCS IDH) by way of data tags. The tags are transmitted by the DPCS either periodically (synchronous) or on demand (asynchronous). The DPCS IDH is therefore designed to handle both synchronous and asynchronous communication with the DPCS. The DPCS IDH receives the following tags from the DPCS instrument:

· Lance depth (synchronous)

· Oxygen pressure (synchronous)

· Oxygen volume (synchronous)

· Converter position (synchronous)

· Hopper weights (asynchronous)

The DPCS IDH sends the following instruction tags to the DPCS instrument:

· Move converter

· Send hopper weight

· Set lance depth

· Set oxygen pressure

· Reset oxygen volume counter

The DPCS occasionally sends incorrect information or tags out of order. The DPCS IDH is capable of trapping false events and rejecting them.

The other consoles used in this application are as follows:

· The Continuous Casting console, which interacts with the converter console to decide how the molten steel produced should be cast into solid steel. This console uses a good number of enterprise interface components as well.

· The Laboratory console provides for a method to control the x-ray spectrometers by interacting with their respective IDH, and also provides for a method of manual analysis entry in the event the IDH fail.

· The Argon Rinsing Unit Console interacts with the ARU IDH and the laboratory and converter consoles and also interacts with the statistical model object to determine how much argon should be blown into the steel produced from the converters to remove bubbles.

The Production Planning & Control is a GUI application that is developed largely out of the enterprise interface components. Enterprise interface components are also used for designing modules for various agencies within the enterprise linked by the intranet. WAP applications using the enterprise interface components are used to provide communication links with crews operating trains that bring in raw materials and remove finished products from the factory.

Conclusion

This paper describes the general idea of the Calcutta Suite as a framework for automation applications development. The actual design of the framework and the various components within this framework are largely outside the scope of this paper. The author intends to continue with his concept of the Calcutta Suite and through the course of other relevant term papers during his tenure as a graduate student and, hopefully, as part of his doctoral thesis, develop Calcutta Suite as a fully functional framework with widespread commercial use.

Summary

Industrial automation applications require high reliability and have largely repeatable processes, lending themselves to be developed using patterns, and therefore components. Since industrial applications largely mimic real world instruments, they are appropriate candidates for object-oriented design. Industrial automation applications however use specific components that are usually not provided by general-purpose application development frameworks and therefore the necessity of specific frameworks that cater to these needs.

The Calcutta Suite is such a framework, which provides a variety of components for instrument data handling, operator consoles and enterprise-wide reporting modules within automation applications.

CALCUTTA SUITE: PROPOSED OBJECT COMPONENTS PACKAGE FOR DEVELOPERS OF INDUSTRIAL SYSTEMS AUTOMATION APPLICATIONS

Ashutosh Chatterji

Abstract