- Email: [email protected]
A class of high level languages for process control
63
Forum
A Class of High Level Languages for Process Control Jason Gait *
1. Introduction
Department of Computer Science, School of Engineering, University of Mississippi, University, Mississtppi, 38677, USA
An abstract notational system can serve as a model for the investigation of high level programming languages that explicitly support the monitoring and control of parallel events, provide data types at the bit level and allow real-time interaction between user and process. Run-time mechanisms that support the execution of programs in the notational system chosen on specific hardware can also be identified. A software tools environment can be designed to provide high level languages and runtime support for process control in a way that encourages portability a m o n g different hardware configurations.
Keywords: Distributed systems, high-level languages, process automation, process control, real-time, run-time systems, software tools, state-set notation, process control languages.
Jason Gait is Associate Professor of Computer Science at the University of Mississippi. He has a P h D from Wesleyan University and has been employed as a Computer Scientist at the National Bureau of Standards.
The development of software for increasingly complex process control applications is generally recognized as a difficult and expensive activity [3,10,17]. This is true even when well-specified and standardized high-level languages are used, but is especially vexing when the language available is inappropriate to the application or when the only programming language available is a limited-purpose vendor-specific language provided with the hardware. Modern principles of software engineering dictate the use of a high-level language drawn from a spectrum of languages each of which is appropriate to a specific programming activity. While software for process control is becoming increasingly important, high level languages specifically designed for this application are not yet well-known. This deficiency can only be remedied by studying the language features required to support the process control environment, for example explicit parallelism of events, not supported in current languages; the specification of a language to support these features and the eventual publication of the result and its distribution to the research community. 2. Description of Problem
Our interest is directed to the design and implementation of general-purpose, public-domain programming languages to support the special features and activities of the industrial process control environment. * Correspondence should be sent to: P.O. Box 732, Portland, O R 97207, USA.
North-Holland Computers in Industry 4 (1983) 63-67
2.1. High Level Process Control Languages
A programming language suitable for process control applications is a high level computer pro-
0166-3615/83/$03.00 © 1983 Elsevier Science Publishers B.V. (North-Holland)
64
Forum
gramming language, characterized by explicitly defined parallel tasks, that is tasks that must be performed simultaneously, and is used for realtime, that is effectively instantaneous response, process control, man-machine interaction and data acquisition. Our specific area of interest is the applicability of such languages in the environment of industrial manufacturing. Previous attempts to devise industry oriented programming languages have tended to concentrate on specific problem areas, such as robotics at IBM [18,27], machine tools [24] or has been too closely tied to an existing (and unsuitable) high level language [7,14]. Innovations in software technique can have major effects on process automation [7]. Software development tends to be an increasing cost component for process control in general. At one site, where 11 minicomputers are used, " t h e single most expensive ingredient is software development, estimated at 62% and growing" [7]. Process control takes place in a distributed environment [6], which determines the nature of the IO interfaces through which the process control language talks to manufacturing processes. A prototype process control language for basic control and recording purposes can be founded on the general state set notation [13,19,20] which is easily adapted to completely describe and display the critical features of industrial procedures and data acquisition. In a manufacturing context, the state set notation can facilitate communication among engineers of complex industrial procedures, making it practical to replicate procedures in exact detail. Some examples of programs based on this notation can be found in [ 15,16,26]. The most important feature of the Mealy-Moore notation system is that all the elements of a procedure are described in terms of discrete states, corresponding to outputs that are active at any given time. The outputs and the requirements for output changes are defined within a system of states, state sets and state transition requirements. A state is considered to be part of a procedure, containing all information pertaining to the outputs that are present and the requirements that have to be met in order for transition to another state to occur. Each state is part of a state set and within each state set one and only one state is active at any given time. Several state sets operate in parallel independently: in this way, the state notation can explicitly describe cooperating paral-
(~,mputut-, ,,n I~Mu~zt-,
lel processes. Environmental events and time act as inputs to states whose outputs reflect the inputs and the present state only. The advantages of using the state notation as the basis of a process control language are discussed in the following sections.
2.1.1. Generality An abstract notational system, provided it is sufficiently rich, complete and detailed to adequately specify all procedures that might be required for applications, has the advantage that it provides generality across different scientific and industrial control problems. In this way procedures that are written to solve one control problem in a specific industry are capable of being transferred to the solution of an apparently distinct, but actually equivalent, control problem in quite a different industry. We can envisage libraries of procedures written in the notational system that can be drawn on by programmers in many different industries in the same way that F O R T R A N libraries are mined by programmers in distinct scientific disciplines for code that is applicable to problems never dreamed of by its creators. The development of process control software in all industries is thereby made less expensive, and the software needed for a particular application can be made available more quickly.
2.1.2. Simplicity The simplicity of the notational system leads to the simplification of training procedures for programmers, and in fact should make most procedures accessible to process engineers with very minimal training. Easy to read procedures lead to improvements in the correctness and maintainability of software, analogous to the improvement observed wherever high level languages have been introduced.
2.1.3. Efficiency Efficient use of machine resources is a necessary goal in process control applications because of the prevalence of real-time activity. The notational system supports low level machine interactions at-the same time that it supports high level user interactions, combining the ability to do things, or power, with the ability to be easily programmed to do things, or high level linguistic capability.
Computers in Industry
2.1.4. Level of Complexity The state set notational system has sufficient power to describe complex parallel processes, and sufficient coding efficiency to execute them in real-time. Thus highly complex procedures involving multiple parallel events can be described by the notational system and effectively performed using small-scale resources in both laboratory and industrial environments. 2.1.5. Wide Applicability The Mealy-Moore notation has found a role in numerous application areas outside industrial process control, e.g., • operant conditioning [25] • conditioning of bio-electrical potentials [4] • autoshaping under classical conditioning procedures [8] • simulation of finite Markov chain models [1]. It is because of this success in several different laboratory application areas, serving essentially as testbeds for the notational system, that we are able to extend the usefulness of the notational system to non-laboratory environments. 2.2. Development System vs. Target System A general aim is that of portability across target systems. At present control procedures tend to be locked into existing hardware and when the time comes to upgrade the hardware it often seems that upgrading the software is the most expensive, time consuming and error prone part of the task. Our approach is to develop software on a standard system, or development system, providing hardware and software interfaces to a variety of target systems as required. This allows central control of software development and maintenance, while still being consistent with the ability to use a variety of target architectures for different applications.
2.3. Run Time Systems for Process Control In terms of the state-set notation a run-time system for process control is an executive program that monitors the progress of individual state tables and distributes inputs and outputs between interface connectors and the appropriate state tables. Several independent state tables, representing separate procedures, are in this way serviced simultaneously. Additional services provided by
J. Gait / Languages for Process Control
65
the run-time system include monitor interactions, data-logging, manipulation of states within state sets and communication between distinct state sets. Typical run-time systems are described in [22,23].
2.4. Real Worm Interfacing In order to communicate with the environment outside the computer, we need to provide the physical capability to receive and display data from apparatus of different types and to control, via relays and line driver circuitry, the progress of processes. This interface consists of the hardware needed to transform real world events to and from computer events. The computer signals are not themselves capable of activating external equipment which is typically non-digital. The interface must contain devices, such as drivers and relays, which are capable of operating equipment, capable of being directly addressed by the computer and which are able to cause interrupts under program control. The run-time system interacts with target physical environments through this interface. Since the real-world interface can be extremely complex, especially for robotic applications, the software that controls the interface must be sufficiently sophisticated to deal with even very complicated environments [2].
2.5. Tools for the Process Control Computer Environment A variety of hardware and software tools are oriented toward the process control environment. They are so constructed as to take advantage of the key features that are characteristic of process control languages, e.g., explicit parallelism, bit level data types, direct addressing of l0 interfaces and dynamic, real time interaction between the user process and the apparatus. We can identify the following required tool-kit items: • a downline loader from the development system to the target system that allows all software development to be carried on in an efficient high level language. • a translator from the assembler of the development language to the target assembler which bridges a gap between the output of the compiler and the code needed to operate on the targetmachine, • a tokenizing compiler for the notational system
66
Forum
chosen running on the development system that operates as a software testbed for various potentially useful language features as well as providing token-threaded code for downline loading to the target, • a general run time system for the target that supports the features needed, i.e., explicit parallelism, bit level data types, etc., • a threaded code interpreter for the notational system to run under the run time system, • a simulator for an artificial process control environment that provides an execution environment for testing programs and an environment for operator training [21], • an extensive set of procedures to completely test the compiler and the run time system, • a set of device drivers and IO interfaces at the target to allow interaction with physical environments. Process control languages have a number of distinctive features, already mentioned, that are not as a rule found in other high level programming languages. The tools described enable researchers to investigate such features in the following ways: 1. Evaluate aspects of the notational system chosen to represent procedures in the light of how well the language as defined implements these features, for example F O R T R A N makes no provision for the support of parallel activities and thus is poorly featured in terms of implementing explicit parallelism, 2. Evaluate the interactions between features special to process control languages and other high level language features not defined or poorly defined elsewhere, such as "if0else", "while()", "during()", " u n t i l 0 " , 3. Evaluate a variety of structures that could be used in the run time system to support the required explicit parallelism, for instance it is possible that parallel events could be interfaced to separate microprocessors having a common shared run-time system, 4. Evaluate the nature of the real-time interaction between users of the system and controlled apparatus, 5. Discover a minimal set of procedures that completely test the compiler, the run time interfaces and the simulator, 6. Evaluate interface options, e.g., parallel vs serial, in the distributed environment,
(~'omputer~ tn ]ndu~lrv
7. Evaluate notational options for explicitly describing the synchronization of parallel actions in process control, 8. Evaluate varying degrees of environmental awareness, that is of ability to inspect the state of the system and make appropriate alterations in state variables, for the run-time system, 9. Investigate the degree of time invariance, that is aspects of a process environment whose alteration must be prevented by the run-time system, present in process control applications, 10. Explore mechanisms to make procedures and support software portable across different target environments.
3. Conclusions A high level process control language is a great convenience in a laboratory environment, a tool that makes a variety of tasks that were once difficult easy. In an industrial environment such a language is not just a convenience, but it can be a tool for increasing productivity by controlling machines, improving operating functionality, speeding up operator training, automating assembly lines and controlling warehousing and distribution functions. The new software tools approach a natural and potentially very fruitful application area in the setting of industrial process control [5]. At the present time the programming languages available for process control in industry are generally vendor specific, e.g., the G T E proprietary process control system MECA uses the proprietary process control language SYBIL [28], or some more or less inappropriate variant of BASIC or F O R T R A N , and are typically bundled into the hardware purchased for the application in hand. The severity of the problem is apparent even when one restricts attention to programmable controllers, which support hosts of variants of several different special purpose languages [9]. It seems that much duplication of effort takes place in devising ad hoc process control languages which then remain proprietary to their developers and which inhibits convenient porting of procedures to other target environments [11]. Standardization of a particular general purpose process control language and standardization of the features of the language will tend to make the development of computer controlled processes a straightforward
Computers in Industry
m a t t e r of i m p l e m e n t i n g the notation. G e n e r a l purpose, n o n v e n d o r specific p r o g r a m m i n g languages have historically b e e n very successful, as evidenced b y their current widespread use in the appropriate a p p l i c a t i o n areas in preference to v e n d o r specific l a n g u a g e s , e.g., F O R T R A N for s c i e n t i f i c processing, C O B O L in business, P A S C A L for educational purposes a n d C for systems p r o g r a m m i n g applications. W e are convinced that the availability of high level languages explicitly designed for process control will have the same positive effect in the i n d u s t r i a l control e n v i r o n m e n t , where generally rather primitive methods are now being used [12], as properly designed high level languages have had in other application areas.
References [1] R. Atkinson et al, Introduction to Mathematical Learning Theory, New York, Wiley, 1965. [2] J. Bejczy, "Sensors, Controls and Man Machine Interface for Advanced Teleoperation", Science,208 (1980) 1327-35. [3] O. Bjorke, "Software Production-the Bottleneck of Future Manufacturing Sytems", Ann CIRP, 24 (1975) 543-8. [4] F. Butler, "Analog SKED", Behav. Res. Meth. and Instru., 7, (1975) 239-42. [5] D. Dallas, "The Advent of the Automated Factory", Manufacturing Engineering, Nov. 1980, 66-76. [6] R. Dessy, "Computer Networking, A Rational Approach to Laboratory Automation", Anal. Chem., 49 (1977) 1100-08. [7] R. Dessy and M. Starling, "Fourth Generation Languages for Laboratory Applications", Amer. Lab., Feb 1980, 21-32. [8] R. Dingier et al, "SKED Program for Modified Sternberg Procedure", Behav. Res. Meth. and Instru., 7, (1975) 249-50. [9] G.C. Hartwig, "PC Status Report", Manufacturing Eng, (Oct 1981) 61-3. [10] J. Hatvany, "Software Costs", Soft Pract and Exp, 3 (1973) 307-8.
J. Gait / Languages for Process Control
67
[11] J. Hatvany and J. Janos, "Software Products for Manufacturing Design and Control", Proc. IEEE, 68, (1980) 1050-3. [12] W. Holdeby, "Current Techniques in Factory Data Collection", Comp. Des., (Dec 1980), 92-100. [13] D. Huffman, "The Synthesis of Sequential Circuits", J. Franklin lnst., 257, (1954) 161-90 and 275-303. [14] F. Krull, "Experience With ILLIAD: A High-level Process Control Language", CACM, 24 (1981) 66-72. [15] J.V. Landau, "State Description Techniques Applied to Industrial Machine Control", IEEE Computer, (Feb 1979) 32-40. [16] J.V. Landau, "Hardware-oriented State Description Techniques", in Microprocessor Applications Handbook (ed: D. Stout), McGraw-Hill, 1982, New York. [17] E.J. Lerner, "Computer Aided Manufacturing", IEEE Spectrum, (Nov 1981) 34-39. [18] L. Lieberman and M. Wesley, "AUTOPASS, A Very High Level Programming Language for Mechanical Assembly Systems", IBM Jr. of Res. and Dev., 21 (1977) 231. [19] G. Mealy, "A Method for Synthesizing Sequential Circuits", Bell System Tech Jr., 34, (1955) 1045-79. [20] E. Moore, "Gedanken Experiments on Sequential Machines", Automata Studies, Prince. U. Press. 34, (1956) 129-53. [21] T.L. Myron, "Digital Technology in Process Control", Computer Des, (Nov 1981) 117-128. [22] M.S. Pickett and H.A. Shutz, "Interpretive Execution of Real-time Control Applications", ACM SIGPLAN, 11 (1976) 78-87. [23] W.D. Pierce, "Process Control Methods EffectivelyRegulate Home Functions", Comp Tech Rev, (Winter, 1981) 40-46. [24] D.T. Ross, "Origins of the APT Language for Automatically Programmed Tools", ACM SIGPLAN, 13 (1978) 61-99. [25] A. Snapper et al, "Mathematical Description of Schedules of Reinforcement", Theory of Reinforcement Schedules, Appleton Century Crofts, New York, 1970, 247-75. [26] A. Snapper, "Use of a Notation System for Digital Control and Recording", Beh. Res. Meth. and Inst., 5 (1973) 124-9. [27] P. Summers, R. Taylor and J. Meyer, "AML: A Programming Language for Automation", COMPSAC 81, Chicago, Nov. 198i. [28] Electronic Design, Oct. 1980, p. 24.
Forum
A Class of High Level Languages for Process Control Jason Gait *
1. Introduction
Department of Computer Science, School of Engineering, University of Mississippi, University, Mississtppi, 38677, USA
An abstract notational system can serve as a model for the investigation of high level programming languages that explicitly support the monitoring and control of parallel events, provide data types at the bit level and allow real-time interaction between user and process. Run-time mechanisms that support the execution of programs in the notational system chosen on specific hardware can also be identified. A software tools environment can be designed to provide high level languages and runtime support for process control in a way that encourages portability a m o n g different hardware configurations.
Keywords: Distributed systems, high-level languages, process automation, process control, real-time, run-time systems, software tools, state-set notation, process control languages.
Jason Gait is Associate Professor of Computer Science at the University of Mississippi. He has a P h D from Wesleyan University and has been employed as a Computer Scientist at the National Bureau of Standards.
The development of software for increasingly complex process control applications is generally recognized as a difficult and expensive activity [3,10,17]. This is true even when well-specified and standardized high-level languages are used, but is especially vexing when the language available is inappropriate to the application or when the only programming language available is a limited-purpose vendor-specific language provided with the hardware. Modern principles of software engineering dictate the use of a high-level language drawn from a spectrum of languages each of which is appropriate to a specific programming activity. While software for process control is becoming increasingly important, high level languages specifically designed for this application are not yet well-known. This deficiency can only be remedied by studying the language features required to support the process control environment, for example explicit parallelism of events, not supported in current languages; the specification of a language to support these features and the eventual publication of the result and its distribution to the research community. 2. Description of Problem
Our interest is directed to the design and implementation of general-purpose, public-domain programming languages to support the special features and activities of the industrial process control environment. * Correspondence should be sent to: P.O. Box 732, Portland, O R 97207, USA.
North-Holland Computers in Industry 4 (1983) 63-67
2.1. High Level Process Control Languages
A programming language suitable for process control applications is a high level computer pro-
0166-3615/83/$03.00 © 1983 Elsevier Science Publishers B.V. (North-Holland)
64
Forum
gramming language, characterized by explicitly defined parallel tasks, that is tasks that must be performed simultaneously, and is used for realtime, that is effectively instantaneous response, process control, man-machine interaction and data acquisition. Our specific area of interest is the applicability of such languages in the environment of industrial manufacturing. Previous attempts to devise industry oriented programming languages have tended to concentrate on specific problem areas, such as robotics at IBM [18,27], machine tools [24] or has been too closely tied to an existing (and unsuitable) high level language [7,14]. Innovations in software technique can have major effects on process automation [7]. Software development tends to be an increasing cost component for process control in general. At one site, where 11 minicomputers are used, " t h e single most expensive ingredient is software development, estimated at 62% and growing" [7]. Process control takes place in a distributed environment [6], which determines the nature of the IO interfaces through which the process control language talks to manufacturing processes. A prototype process control language for basic control and recording purposes can be founded on the general state set notation [13,19,20] which is easily adapted to completely describe and display the critical features of industrial procedures and data acquisition. In a manufacturing context, the state set notation can facilitate communication among engineers of complex industrial procedures, making it practical to replicate procedures in exact detail. Some examples of programs based on this notation can be found in [ 15,16,26]. The most important feature of the Mealy-Moore notation system is that all the elements of a procedure are described in terms of discrete states, corresponding to outputs that are active at any given time. The outputs and the requirements for output changes are defined within a system of states, state sets and state transition requirements. A state is considered to be part of a procedure, containing all information pertaining to the outputs that are present and the requirements that have to be met in order for transition to another state to occur. Each state is part of a state set and within each state set one and only one state is active at any given time. Several state sets operate in parallel independently: in this way, the state notation can explicitly describe cooperating paral-
(~,mputut-, ,,n I~Mu~zt-,
lel processes. Environmental events and time act as inputs to states whose outputs reflect the inputs and the present state only. The advantages of using the state notation as the basis of a process control language are discussed in the following sections.
2.1.1. Generality An abstract notational system, provided it is sufficiently rich, complete and detailed to adequately specify all procedures that might be required for applications, has the advantage that it provides generality across different scientific and industrial control problems. In this way procedures that are written to solve one control problem in a specific industry are capable of being transferred to the solution of an apparently distinct, but actually equivalent, control problem in quite a different industry. We can envisage libraries of procedures written in the notational system that can be drawn on by programmers in many different industries in the same way that F O R T R A N libraries are mined by programmers in distinct scientific disciplines for code that is applicable to problems never dreamed of by its creators. The development of process control software in all industries is thereby made less expensive, and the software needed for a particular application can be made available more quickly.
2.1.2. Simplicity The simplicity of the notational system leads to the simplification of training procedures for programmers, and in fact should make most procedures accessible to process engineers with very minimal training. Easy to read procedures lead to improvements in the correctness and maintainability of software, analogous to the improvement observed wherever high level languages have been introduced.
2.1.3. Efficiency Efficient use of machine resources is a necessary goal in process control applications because of the prevalence of real-time activity. The notational system supports low level machine interactions at-the same time that it supports high level user interactions, combining the ability to do things, or power, with the ability to be easily programmed to do things, or high level linguistic capability.
Computers in Industry
2.1.4. Level of Complexity The state set notational system has sufficient power to describe complex parallel processes, and sufficient coding efficiency to execute them in real-time. Thus highly complex procedures involving multiple parallel events can be described by the notational system and effectively performed using small-scale resources in both laboratory and industrial environments. 2.1.5. Wide Applicability The Mealy-Moore notation has found a role in numerous application areas outside industrial process control, e.g., • operant conditioning [25] • conditioning of bio-electrical potentials [4] • autoshaping under classical conditioning procedures [8] • simulation of finite Markov chain models [1]. It is because of this success in several different laboratory application areas, serving essentially as testbeds for the notational system, that we are able to extend the usefulness of the notational system to non-laboratory environments. 2.2. Development System vs. Target System A general aim is that of portability across target systems. At present control procedures tend to be locked into existing hardware and when the time comes to upgrade the hardware it often seems that upgrading the software is the most expensive, time consuming and error prone part of the task. Our approach is to develop software on a standard system, or development system, providing hardware and software interfaces to a variety of target systems as required. This allows central control of software development and maintenance, while still being consistent with the ability to use a variety of target architectures for different applications.
2.3. Run Time Systems for Process Control In terms of the state-set notation a run-time system for process control is an executive program that monitors the progress of individual state tables and distributes inputs and outputs between interface connectors and the appropriate state tables. Several independent state tables, representing separate procedures, are in this way serviced simultaneously. Additional services provided by
J. Gait / Languages for Process Control
65
the run-time system include monitor interactions, data-logging, manipulation of states within state sets and communication between distinct state sets. Typical run-time systems are described in [22,23].
2.4. Real Worm Interfacing In order to communicate with the environment outside the computer, we need to provide the physical capability to receive and display data from apparatus of different types and to control, via relays and line driver circuitry, the progress of processes. This interface consists of the hardware needed to transform real world events to and from computer events. The computer signals are not themselves capable of activating external equipment which is typically non-digital. The interface must contain devices, such as drivers and relays, which are capable of operating equipment, capable of being directly addressed by the computer and which are able to cause interrupts under program control. The run-time system interacts with target physical environments through this interface. Since the real-world interface can be extremely complex, especially for robotic applications, the software that controls the interface must be sufficiently sophisticated to deal with even very complicated environments [2].
2.5. Tools for the Process Control Computer Environment A variety of hardware and software tools are oriented toward the process control environment. They are so constructed as to take advantage of the key features that are characteristic of process control languages, e.g., explicit parallelism, bit level data types, direct addressing of l0 interfaces and dynamic, real time interaction between the user process and the apparatus. We can identify the following required tool-kit items: • a downline loader from the development system to the target system that allows all software development to be carried on in an efficient high level language. • a translator from the assembler of the development language to the target assembler which bridges a gap between the output of the compiler and the code needed to operate on the targetmachine, • a tokenizing compiler for the notational system
66
Forum
chosen running on the development system that operates as a software testbed for various potentially useful language features as well as providing token-threaded code for downline loading to the target, • a general run time system for the target that supports the features needed, i.e., explicit parallelism, bit level data types, etc., • a threaded code interpreter for the notational system to run under the run time system, • a simulator for an artificial process control environment that provides an execution environment for testing programs and an environment for operator training [21], • an extensive set of procedures to completely test the compiler and the run time system, • a set of device drivers and IO interfaces at the target to allow interaction with physical environments. Process control languages have a number of distinctive features, already mentioned, that are not as a rule found in other high level programming languages. The tools described enable researchers to investigate such features in the following ways: 1. Evaluate aspects of the notational system chosen to represent procedures in the light of how well the language as defined implements these features, for example F O R T R A N makes no provision for the support of parallel activities and thus is poorly featured in terms of implementing explicit parallelism, 2. Evaluate the interactions between features special to process control languages and other high level language features not defined or poorly defined elsewhere, such as "if0else", "while()", "during()", " u n t i l 0 " , 3. Evaluate a variety of structures that could be used in the run time system to support the required explicit parallelism, for instance it is possible that parallel events could be interfaced to separate microprocessors having a common shared run-time system, 4. Evaluate the nature of the real-time interaction between users of the system and controlled apparatus, 5. Discover a minimal set of procedures that completely test the compiler, the run time interfaces and the simulator, 6. Evaluate interface options, e.g., parallel vs serial, in the distributed environment,
(~'omputer~ tn ]ndu~lrv
7. Evaluate notational options for explicitly describing the synchronization of parallel actions in process control, 8. Evaluate varying degrees of environmental awareness, that is of ability to inspect the state of the system and make appropriate alterations in state variables, for the run-time system, 9. Investigate the degree of time invariance, that is aspects of a process environment whose alteration must be prevented by the run-time system, present in process control applications, 10. Explore mechanisms to make procedures and support software portable across different target environments.
3. Conclusions A high level process control language is a great convenience in a laboratory environment, a tool that makes a variety of tasks that were once difficult easy. In an industrial environment such a language is not just a convenience, but it can be a tool for increasing productivity by controlling machines, improving operating functionality, speeding up operator training, automating assembly lines and controlling warehousing and distribution functions. The new software tools approach a natural and potentially very fruitful application area in the setting of industrial process control [5]. At the present time the programming languages available for process control in industry are generally vendor specific, e.g., the G T E proprietary process control system MECA uses the proprietary process control language SYBIL [28], or some more or less inappropriate variant of BASIC or F O R T R A N , and are typically bundled into the hardware purchased for the application in hand. The severity of the problem is apparent even when one restricts attention to programmable controllers, which support hosts of variants of several different special purpose languages [9]. It seems that much duplication of effort takes place in devising ad hoc process control languages which then remain proprietary to their developers and which inhibits convenient porting of procedures to other target environments [11]. Standardization of a particular general purpose process control language and standardization of the features of the language will tend to make the development of computer controlled processes a straightforward
Computers in Industry
m a t t e r of i m p l e m e n t i n g the notation. G e n e r a l purpose, n o n v e n d o r specific p r o g r a m m i n g languages have historically b e e n very successful, as evidenced b y their current widespread use in the appropriate a p p l i c a t i o n areas in preference to v e n d o r specific l a n g u a g e s , e.g., F O R T R A N for s c i e n t i f i c processing, C O B O L in business, P A S C A L for educational purposes a n d C for systems p r o g r a m m i n g applications. W e are convinced that the availability of high level languages explicitly designed for process control will have the same positive effect in the i n d u s t r i a l control e n v i r o n m e n t , where generally rather primitive methods are now being used [12], as properly designed high level languages have had in other application areas.
References [1] R. Atkinson et al, Introduction to Mathematical Learning Theory, New York, Wiley, 1965. [2] J. Bejczy, "Sensors, Controls and Man Machine Interface for Advanced Teleoperation", Science,208 (1980) 1327-35. [3] O. Bjorke, "Software Production-the Bottleneck of Future Manufacturing Sytems", Ann CIRP, 24 (1975) 543-8. [4] F. Butler, "Analog SKED", Behav. Res. Meth. and Instru., 7, (1975) 239-42. [5] D. Dallas, "The Advent of the Automated Factory", Manufacturing Engineering, Nov. 1980, 66-76. [6] R. Dessy, "Computer Networking, A Rational Approach to Laboratory Automation", Anal. Chem., 49 (1977) 1100-08. [7] R. Dessy and M. Starling, "Fourth Generation Languages for Laboratory Applications", Amer. Lab., Feb 1980, 21-32. [8] R. Dingier et al, "SKED Program for Modified Sternberg Procedure", Behav. Res. Meth. and Instru., 7, (1975) 249-50. [9] G.C. Hartwig, "PC Status Report", Manufacturing Eng, (Oct 1981) 61-3. [10] J. Hatvany, "Software Costs", Soft Pract and Exp, 3 (1973) 307-8.
J. Gait / Languages for Process Control
67
[11] J. Hatvany and J. Janos, "Software Products for Manufacturing Design and Control", Proc. IEEE, 68, (1980) 1050-3. [12] W. Holdeby, "Current Techniques in Factory Data Collection", Comp. Des., (Dec 1980), 92-100. [13] D. Huffman, "The Synthesis of Sequential Circuits", J. Franklin lnst., 257, (1954) 161-90 and 275-303. [14] F. Krull, "Experience With ILLIAD: A High-level Process Control Language", CACM, 24 (1981) 66-72. [15] J.V. Landau, "State Description Techniques Applied to Industrial Machine Control", IEEE Computer, (Feb 1979) 32-40. [16] J.V. Landau, "Hardware-oriented State Description Techniques", in Microprocessor Applications Handbook (ed: D. Stout), McGraw-Hill, 1982, New York. [17] E.J. Lerner, "Computer Aided Manufacturing", IEEE Spectrum, (Nov 1981) 34-39. [18] L. Lieberman and M. Wesley, "AUTOPASS, A Very High Level Programming Language for Mechanical Assembly Systems", IBM Jr. of Res. and Dev., 21 (1977) 231. [19] G. Mealy, "A Method for Synthesizing Sequential Circuits", Bell System Tech Jr., 34, (1955) 1045-79. [20] E. Moore, "Gedanken Experiments on Sequential Machines", Automata Studies, Prince. U. Press. 34, (1956) 129-53. [21] T.L. Myron, "Digital Technology in Process Control", Computer Des, (Nov 1981) 117-128. [22] M.S. Pickett and H.A. Shutz, "Interpretive Execution of Real-time Control Applications", ACM SIGPLAN, 11 (1976) 78-87. [23] W.D. Pierce, "Process Control Methods EffectivelyRegulate Home Functions", Comp Tech Rev, (Winter, 1981) 40-46. [24] D.T. Ross, "Origins of the APT Language for Automatically Programmed Tools", ACM SIGPLAN, 13 (1978) 61-99. [25] A. Snapper et al, "Mathematical Description of Schedules of Reinforcement", Theory of Reinforcement Schedules, Appleton Century Crofts, New York, 1970, 247-75. [26] A. Snapper, "Use of a Notation System for Digital Control and Recording", Beh. Res. Meth. and Inst., 5 (1973) 124-9. [27] P. Summers, R. Taylor and J. Meyer, "AML: A Programming Language for Automation", COMPSAC 81, Chicago, Nov. 198i. [28] Electronic Design, Oct. 1980, p. 24.