The integration of high level interpretive software with microprocessor based distributed control systems

THE INTEGRATION OF HIGH LEVEL INTERPRETIVE SOFTWARE WITH MICROPROCESSOR BASED DISTRIBUTED CONTROL SYSTEMS M.S. Willey and J.F. Hoffmaster Bailey Meter Company,

Wickliffe,

Ohio

AB"mR4?T 4i 1 i!:teg+atioc of sophisticated, distributed, microprocessor based control hardware, communication s:Js+ems,and process interface modules with a high l+vel inter-m _+_etive scftware language as a replacement for classical panel board instrumentation is discussed. Data acquisition and control functions are ch;7sicallv as well as functionally distributed while a high level softii3re environment is maintained for dis;Jlay system development and modificatlon. 'perator interface to the system is through a microprocessor based r -,' or CRT capable cf displaying a hierarchical set of plant operation dis-.-I p Lay s . The

T?e introduction of the microprocessor has led to a generally increasing a:ceptance, both in cbst and performance, of the distributed system architecture. Ph:;sicaldistribution reduces overall installed costs as well as fire hazards of multiple cable runs. Functional distribution of computing requirements among multiple processors provides both greater system capacity and a more continuous range of capacities than non-distributed architectures. Software in real time microprocessor based systems has classically been written in assembly language. This has primarily been due to the throughput requirements cf such systems, and the fact that high level software support for the myriad of microprocessors on the market has been minimal. A high level language that can significantly reduce software generation and maintenance efforts while meeting the cost and performance requirements is needed. DISTRIBUTED ARCHITECTURE The environment of the system is functionally divided into a three level hierarchical structure. An example is illustrated in Figure 1. The SITE encompasses all data acquisition and control requirements of the system. FI,A"TSare largelv independent subdivisions of the SITE, which are further subdivided into ?kOCESS UNITS. These divisions are based on the functional structure of the system being monitored and controlled. For example, a typical paper mill is organized into four plants; a groundwood mill (mechanical production of pulp), a kraft plant (chemical production of pulp),- a gaper machine, and a steam plant. There are three major elements in the data acquisition and control system c,perating in this environment; the Operator Interface, the Process Interface, and the Communication System. Figure 2 illustrates the system structure brhich corresponds to the environment of Figure 1. At the SITE level, the main communication link connects the SITE level Operator Interface NODE with each of the PLANT level Operator Interface YODEs. At the PLANT level, each 3OCESS I.JKIT is interfaced to a communications sublink by a Data Interface ~J~DE. A PT,4NTOperator Interface NODE performs the dual function of proIriding the PLANT level Operator Interface and interfacing the plant to the main communication link. "his particular distribution of funn,tions among NODES 'was chosen for clarity of presentation. Depending on the processing requirements, an actual system 99

M. S. Willeyand J. F. Hoffmaster

loo

may not have this correspondence of physical structure to functional structure. For example, a plant with limited process interface requirements might be served by a single NODE performing both the cperator and process interface functions. That plant would not require a communica%ion sublink. NODE HARDWARE Each NODE consists of one or more processor modules connected via a highspeed bus to some number of interface modules. The processor module consists of a microprocessor, semiconductor RAM .(Random Access Memory), and programmable ROM (Read Only Memory). Figure 3 illustrates a typical IJODE structure. Three types of interface modules exist; peripheral, communication, and process. Peripheral interface modules provide the interface to peripheral devices such as terminais and floppy disc systems. A single communication interface module exists which is the hardware interface to the communication system. Several modules of the process f.nter?acetype exist to provide interfaces to analog and digital signals with a variety of characteristics. The NODEBUS provides for the asynchronous, bit-parallel, word-serial transfer of 16-bit data words between modules at a rate of 6501: wordsisec. iK1 addition, a number of flag lines exist for signalling imminent less of power to modules, interrupting processor modules, and 'JODEBUSmanagement. Certain of the interface modules have the capability of interrupting the microprocessor on the processor modules. For example, the communication link interface module provides an interrupt to sianal message receipt or an empty output buffer. A NODE is anaiogous to a conventional minicomputer, with the processor module corresponding to the mainframe and the interface modules corresponding to peripheral interfaces. The modular implementation of the NCDE provides the flexrbility to tailor NODEs to meet system requirements by simpiy piugging in the required modules. It is anticipated that the primary limitation on a NODE's capacity will be the NODEBUS. Of course, the more complex NODE configurations, particularly more those involving multiple processor modules, require CCZT~SpOndiZlgly complex software In the processor modules. NODE SOFT!qARE NODE software resides in the processor modules and is divided into two categories; system and application. At present, there are three programs in the system category; the processor module Control Program, the Communication Software, and the Display Software System. The Control Program provides the facilities for the execution of multiple Tasks in the processor module. It includes facilities for task synchronization and communication as well as a software interface to the NODEBUS. The Comnunication Software works with the communication interface module to provide the communication system. The communication protocols are implemented in this software. All application software will run as tasks under the Controi Program. Software to monitor process variables, check for alarm conditions, convert process variables to engineering units, and report values and Status to the operator interface NODES fall inzc this ,category. COMMUNXATION

SYSTEM

Each communication link,bcth main and sublink, is cf a single type. The communication link uses a ring interconnection scheme with up to one mile of cable between adjacent !JODEs. The communication hardware circulates a number of 137 bit physical packets within which 72 bits are available for ~S~~~yXtr~"""B~~~;~~~tio~e~~~~~~~e. The ccmmunication is synchronous at links car be used to increase system reliability and throughput. At the hardware level, packets are addressed by XDEs. The software provides for the exchange of fixed length messages (43 data bits) between tasks. Three message exchange protocols are implemented; Blind Transmission,

Integration of high level interpretive software

101

Request-Response, and Critical. Tasks residing in processor modules use the three protocols to communicate with other tasks in the system. mhe Blind Transmission protocol provides transmission of a single copy of a message with no verification of delivery. In the Request-Response protocol the sending task is suspended until the destination task sends a reply. Under this protocol, the communication task maintains a timer and re-transmits messages not replied to before the timer expires. This protocol may result in multiple copies of the same message arriving at the destination. The Critical protocol is similar to the Request-Response protocol, the difference being that the communication tasks Involved exchange control messages to insure delivery o f a single copy of each message. Any response from the receiving application task is not involved in the protocol of the initial transmission. In both the Request-Response and Critical protocols, the originating task is eventually awakened with an error indication if the message cannot be delivered after a number of retries. DISPLAY SYSTEM One great advantage of using a distributed architecture and communications link is the availability of plant-wide process information for cent_alized display purposes. This type of CRT display system is becoming widely used and accepted as a replacement (or back-up) for classical instrument panel stations (see Figure 2). Ironically, however, there seems to be a demand to display process data in a format that replicates, to some extent, existing analog station meters and displays. In .fact, the variations in display formats seem to outnumber the different customers purchasing such eouipment. This trend in display format variations will continue until such time that a generalized system becomes widely accepted as a standard. The variety of format and display requirements places a particularly large burden on the vendor of such equipment because of the obviously large amount of engineering hours necessary to create various types of displays. In larger computer based systems, this "application programming" effort is reduced by introducing intermediate translators and formatting software packages. In stand-alone instrumentation display systems, the processor is usually a microprocessor element which is not capable of supporting such elaborate software. In fact, to date, all distributed microprocessor instrumentation systems have been coded in the assembler level language of the particular microprocessor used. The answer to this labor/burden dilemma seems to be to introduce a higher level microprocessor language that would not significantly increase system cost, but would allow significant reductions in application dependent software generation. Certain constraints must be considered when deviating from the assembler approach to coding these systems. The first is speed. It is generally accepted that in the real time control room environment, excessive delays in updating CRT display screens cannot be tolerated. Most of the reasons for this conclusion come not from process requirements but from psychological factors of the operator. An operator trained on the instantaneous displays of analog meter systems is not ready to accept 4 to 5 second delays in CRT information updating, even though the actual process time constants may be mlch longer. Tne second constraint is memory size. Higher level language approaches invariably mean increases in system memory size. Even though semiconductor memory costs have been reduced ii?recent years (see Table l), the addition milst be considered as an added system cost and must be offset by reductions of engineering labor. Taking the above constraints into consideration, an evolutionary approach to this display software generation may be considered. It is advantageous in the generation process to be able to interact with the software system. That is, to change, add, or delete software without recompilation in order to format CRT displays in the least amount of time. This

M.

102

S.

Willeyand J. F. Hoffmaster

interactive requirement tends to lend itself to the interpreted software approach. Interpreted display generation, however, tends to be .too slow to meet the display update speed requirements mentioned above. The optimum solution seems to be to generate the CRT display interactively, then compile the end result into a much faster much more memory efficient package. Table 2 shows some relative timings of the interpretive and compiled approaches assuming assembler language as a standard (1.0). Figure 4 shows an example of the types of operator displays generated in this fashion. SUMMARY A microprocessor based distributed system for data acquisition and control has been described. The ability to configure NODES and communication links provides the flexibility to tailor systems to the peculiarities of each installation. Characteristic of the distributed approach in general is the wide and continuous range of system capacity available. The volatility of displays at the Operator Interface creates a problem. The requirements of easy display generation and high performance display software are at odds. The solution chosen is to develop the display software in a high level language which is executed Interpretively during display development and compiled into machine lawwage for use in the system. REFERENCES James LI. Schoeffler and M. A. Keyes, Hierarchical Language Processing, Software Conference for I:omputerControl, Talinn, Estonia, April, 1976. Michael P. Lukas, A Distributed System Architecture for Utility and Process Applications, Third Annuai Advanced Control Conference, Purdue University, April 26-28, 1976. Satish Chandra and Dan E. Forney, Microprocessor-Based Data-Acquisition Subsystem, IECI 1377 Proceedings, - Industrial Electronics and Control Instrumentaticn, March 21-23, 1977.

Integration

of

high

level

interpretive

103

software

Lrl SITE I

,

.

PLANT

A

PLANT B

PLANT C

PLANT D

r L-J

I

,

I

’ II

LJLJLJLJ J

V

PROCESS UNITS Hierarchical Structure of Environment Figure 1

PLANT A OPERATOR INTERFACE NODE

PLANT c OPERATOR INTERFACE NODE

r

PLANT D OPERATOR INTERFACE NODE

\n L

v

DATA INTERFACE NODES System Structure Figure 2

J

M. S. Willey and J. F. Hoffmaster

104

,=7=-=+ HIGH SPEED SEMAL COMMUNICATlCiiii LINK COMMUNICATION INTERFACE MODULE

Typical Node Struchm Figure3

DlSTlLLATlON

REFLUX MPH

. . . . .

50

HTEXT DEG F

. . .

SETPOINT

OUTPUT

OUTPUT

Example

- GROUP 31

BOTTEMP DEG F

TOP TEMP DEG F loo

OUTPUT

COLUMN

of Analog RaplicamdCRT Display Figwe

OUTPUT

Integration

TYPE YEAR

of

high

level

interpretive

2lo2

2114

1KBTTRAM

4K BIT RAM

105

software

2116 16K 8lT RAM

7641 4K BIT RAM -

MI73

18.00

1914

10.66

46.00

1676

6.66

P.oD

1676

4.66

10.66

13n

2.66

16.66

1978*

1.66

8.00

31.66

6.00

ia30

4.00

*PROJECTED Tsble 1 Semiiwor

Memory Costa

flK Qwn~l

Relative Execution Timing for Assembled, Interpreted, and Compiled Code Table 2