- Email: [email protected]
Process Control and Information Systems
© n
.\C ~'dl 11 i\"I1111 .d \\"ol1d COll!.:1 \""" Bud,tpnl. Ilun g.ln. 1QS·I
Cn!'\ fI).{ln
PROCESS CONTROL AND INFORMATION SYSTEMS G. Farber
Abstract. Industrial process control systems are no longer isolated data processing island s: They need a strong interconnection to the company wide information system. Actual information concern ing the production process has to flow to the control system, and new planning and priority data have to be received in the other direction. This paper discusses the state and some future trends in process control computing , and analyses the possibil ities for the technical interconnection to management information systems. INTRODUCTION
INDUSTRIAL PROCESS CONTROL SYST EMS
Indu stria l applications of computer systems comprise process contro l and information management tasks. They have been developed in very different organisational environments: - Technical groups that have been responsible for conventional instrumentation or even installation are now planning and installing process control computers. They are still reporting t o the production-oriented management within the corporate organisation. - The data processing department started with simple administrative jobs ("pu nched card-era") and took over more and more responsibilities. With today's integrated management information systems it gains strong influence on top management.
Functions and Devices
Now both types of computer applications grow together and overlap: On the one hand they have to exchange data, on the other hand there is a certain competition in taking over new tasks.
Many of these functions can be standardized and parameterized; additionally there are usually application-dependent data processing tasks.
For process control appl ications it is easy to identify classes of functions that have to be performed by the computer-based devices . Examples are: - Data acquisation and data logging - Supervisory functions - Sequence contro l (as in storage programmed control - SPC) - Digital control (c l osed loop systems) - t~an-machine communication (including interaction and data presentation) - Data management (as in database systems).
Figure 1 shows the relationship between process control and informati on systems. Within a plant l ocal control systems provide the interfaces to the instrumentation at the technical process; several local control systems are coordinated by an area control system.
TO/FROM OTHER SUBSYSTE MS
The plant control system that integrates all areas in a plant may orig inate from the process control world and then would be typically based on a midicomputer. It may also be an extension of the company's information system: A powerful node in a distributed processing system. However, there is an interface between information and process control systems - either before or after the pla nt control instance - that has to interconnect both worlds.
51
~I 8 Oh Oh W
This interconnection is not an easy task, it generates technical problems as well as responsibility problems between groups that have been quite independent in the past.
U
~
The paper intend s to give an overview of the state of industrial process systems (chapter 2) as well as of recent trends to interconnect these to management information systems (chap ter 3). Some of the difficult gateway-problems are discussed here as well as the requirement for communication standards. Fig. 1 Hierarchical structure of production control systems . 1679
C. Farber
1680
These functions can be implemented in general purpose devices as in the conventional process control computer. Identical hardware (typically microprocessor-based) is used to perform different functions that are realized in software. That approach typically results in high costs for individual developments . A tendency toward dedicated devices can therefore be observed. To reduce system complexity only one class of functions is implemented in a device. Often dedicated and optimized hardware architectures are used and supported by application-oriented software development systems. Examples are the SPC's for sequence control, special data loggers or distributed control systems (e.g. TDC 2000). These dedicated devices are very usefull in lowcomplexity applications. Very often all the functions mentioned above arise in combination, therefore the individual devices have to at least exchange data. Unfortunately their communication capabilities are only weakly developed. Integration into Systems It is an important task therefore to integrate the isolated stations into common systems. The resulting network is able to exchange data and allows the sharing of instrumentation devices (e.g. sensors ) between different functions . It is obvious that one needs an interconnection network that allows the physical transport of information. Process control applications tend to use bussystems. Figure 2 shows that today's distributed systems do not rely on one bus type only : A hierarchy of busses interconnects all intelligent stations (Wiemann and co-workers, 1981 - 1984 ff) : - A lot of discussion and standardization effort has been spent on the process data highway (PROWAY (Walze, 1978)), that connects local frontend computers to the more powerful process control systems. - A plant data highway with higher bandwidth may connect these process control systems with each other and to a plant control computer. Data rates of up to 100 Mbit/s will be available in the near future; today ETHERNET could be a useful solution (10 Mbit/s (IEEE, 1981)) . - At the lowest level a very local bus (see subchapter 4) will replace todays expensive cabling
1., ,,50 MBIT/ S
'=~..::.:.~:.:..:..::::::.:::..:-++
____
0,1 " "
1 MBIT/ S
FRONT END COMPUTER
0,01 ,,"
2 MBIT/S
AM
ADAPTER MODUL
IS
INTELLIGENT SENSOR
PRODUCTION PROCESS
"
Fig. 2 Hierarchy of bus systems.
between the automation system and process instrumentation (Farber, 1983). The data rates may vary from 10 kbit/s to 2 Mbit/s that are now technologically possible (MacWilliams, 1984) and allow even very high data rates between sensor and front-end computer. Beside these serial bussystems all devices have internal parallel busses that interconnect the local modules. Still more important than the physical interconnection is the ability to exchange data that can be correctly interpreted on the other side. Here the 7-Layer-OSI-Model (open systems interconnection) is widely accepted (Mier, 1982). The layers up to the transportlayer (layer 4) are already subject of standard-proposals - unfortunately there is no common proposal for information systems- and process control-networks. Even more difficult is the definition of layer 5 and 6: - The session layer (5) establishes a common control language that is understood by different operating systems. - The presentation layer (6) is responsible for the internal representation of structured information (e.g. of an array of sensor values or text), and for the presentation of the data for the application programs. Today the application programmer is still responsible for the interpretation of all transmitted bits, he has to worry about operating system-commands and the structure of the data. In the future a common standard may help the programmer to use data and commands from other systems in the same way as on the machine he is attached to. The distributed process control systems available today still have only limited capabilities: They are applicable to the intended purpose, but it is difficult to program, e.g . sequence control algorithms on a TDC 2000 system. Teleperm M (Siemens (Janetzky and co-workers, 1983)) already offers more flexibility, and some new announcements (e.g . TDC 3000 from Honneywell) seem to meet all requirements for an integrated system - with the important disadvantage that only devices from one supplier can be tied into the network. Programming and Functional Distribution Programming conventional process control computers still happens mostly in a wellknown environment: - There is a real time-operating system that allows multitasking and provides for short reaction times after external events. - Programs are written in conventional languages like Fortran or Pascal; the languages usually are extended to support multitasking and I/O to process interfaces. Some newer languages have already standardized these features like PEARL (DIN 66253, 1981, 1982); ADA and - as a less complex and more elegant alternative - Modula-2 provide the basic mechanisms for multitasking and also support low-level functions. There is however not a significant advance since the application still has to be programmed in the well-known very detailed algorithmic way. The same environment is also available for multicomputer systems . Figure 3 shows an example of how local operating systems calls (e.g. interprocess communication) can be extended to a global service: In a RPC-layer ( remote procedure call) each system call is identified to be local : It then is directed to the local operating system and executed locally
Process Control and Information Systems
COMPUTER 2
COMPUTER 1
~
~---~
~
~ ---~ RPC - LAYER
RPC - LAYER
RTOS
TS
RTOS
TS
HARDWARE
TH
HARDWARE
TH
- -- 1
----t-
technical process. Subprocesses (requiring very different functions) may be bound to computers, all processing related to a subprocess takes place on one system - data transmission is minimized. Fault tolerance is also easier to obtain : A failure e.g. in a SPC-system would kill all sequence control functions in the process, whereas a failure in a computer dedicated to a subprocess would only affect that subprocess. It is also much simpler to provide redundancy if the redundant components are all identical . Future Trends
1
PHYSICAL TRANSMISSION
Fig. 3
1681
Distributed system architecture.
- or remote: Using Transport Software (TS) and Transport Hardware (TH) the call is directed to a remote operating system and the results are transmitted back and routed to the local caller. For the programmer the remote execution remains hidden, the system behaves like a single computer (transparency) . The distributed process control systems have also introduced application-oriented software packages that allow the use of prewritten functional modules (like control algorithms, sensor data acquisation etc.). These modules can be reused in many applications and therefore tend to become more and more reliable. For the programmer it looks like a block diagram language where functional modules may be invoked as blocks in a graphical environment (Korn, 1977): Blocks are generated, interconnected and parameterized; the system generates a runnable program automatically. New modules may be written in a conventional language and added to the module library. Whereas the first generation of these programming systems have been restricted to a single application (e.g. sequence control), new systems allow also the mixing of different functionalities . Figure 4 shows how, in mUlticomputer systems, different functions may be distributed among the single systems. Whereas the conventional monoprocessor system takes over all functions, - the horizontal distribution dedicates computers to executing only one class of functions (e.g. SPC's, DDC-systems etc.), and - the vertical distribution supports all functions on all computers and distributes the load among as many computers as required by the application.
The motivation for new developments in process automation systems is usually cost reduction. Some important aspects for future systems are: - Reduction of cabling and installation costs that may contribute 50% to total system costs. - Reduction of software development costs by providing better programming tools and an efficient programming support environment . - Reduction of costs that arise due to system failures : The addition of redundancy (hardware always becomes cheaper) reduces the probability of failures by an order of magnitude and saves the expense caused by these failures. To reduce installation costs semiconductor technology allows replacing expensive cables by powerful intelligent hardware modules . Figure 5 shows an example of a 'very local bus' that transports data and electrical power to adapter modules that provide very local process I/O. They may be mounted directly at process side, and cabling is reduced to a 2wire-bus . The basis of the adapter module is a single-chip microcomputer that performs the communication task and the process-I/O including all local supervisory and diagnostic functions. Preprogrammed chips (e.g. MOSTEK SCU 20 (Mostek, 1982)) are available with transfer rates up to 9600 bit/so New announcements (Intel 8044 (MacWilliams, 1984) ) indicate that the transfer rate restriction will disappear soon: Up to 2,4 Mbit/s will be available. In the long run perhaps these modules will be integrated into the sensors ('intelligent sensor') and the actuators, so cabling is reduced to interconnecting these devices by a 2-wire-cable. A standardization for the 'very local bus' then becomes very urgent. A short note should be given to the personal computers that are becoming cheaper and cheaper and that are also used in data logging applications. Their
AM: ADAPTER MODUL
BA: BUS ADAPTER
The first approach is much easier to understand and to implement, and hardware may be specialized for the individual task . But the vertical distribution allows a much better adaptation to the required performance and to the structure of the controlled
: } PROCESS : SIGNALS
CENTRAL! ZED FUNCT! ONS
DATA ACQUISITION SUPERVI SORY
DISTRIBUTION HOR I CONTAL VERT I CAL
[~~~~-~1 ! I~R I Cl
C 2
I - -I ~~ .
}
I NTELL I GENT SENSOR
M .C. •
CONTROL MAN MACHINE
Fig. 4
SYSTEM
CM
Horizontal and vertical distribution of functions in multicomputersystems.
VERY LOCAL BUS (DATA Al!Il POWER)
Fig. 5
Very local bus systems.
C. Farber
1682
stability (high-volume-production) makes them very well suited for small general purpose process control applications as well. Bus-compatible processI/ O-boards are already available and the keyboard as well as the display (with graphics and colour) provide a good man-machine interface. One requirement to master the famous 'software crisis' is a comfortable programming environment. A computer system providing that comfort normally cannot meet the real time requirements of process control systems. Figure 6 shows a syst~m configuration with 2 types of interconnected systems that can resolve that conflict (Ritchie, 1978): - A general purpose system based on a comfortable operating system (like UNIX) is used for the development including debugging of realtime programs. These programs are linked and loaded down to real time systems where they are executed under real time-constraints. The general purpose system als o performs 'slow' functions like file access, man-ma chine interaction or the execution of background tasks. - One or several realtime systems are based on effi c ient real time-operating systems and perform actual process-I / O as well als all time-critical t as ks. These tasks have been down-loaded from th e general purpose system; if an access to a f ile i s required or an operator intervention, corresponding (slow) tasks in the general purpo se sy s tem are activated. The conventional monolithic process control operating systems disappear and are replaced by standard systems on the one side ( identical to the systems used in commercial applications) and specialized small real time-executives on the other . The combination of both offers a homogeneous and easy to use surface for the applications programmer. GENERAL PURPOSE SYSTEM: COMFORTABLE OPERATING SYSTEM (E.G. UNIX)
=-C='==-T=R=AN=-S=P=OR=-T-=SY=S-T=EM='=
-
DEVELOPMENT DEBUGG I NG F I LE SYSTEMS MAN MACHINE INTERFACE BACKGROUND-TASKS.
-~
-
+--
REAL -T I ME-SYSTEM: - PROCESS 1/0 - REAL TIME-REACTION - TIME CRITICAL TASKS.
'~----~v~---_-J/
PROCESS INTERFACE
Fig . 6
General purpose- and real time-systems.
New software development methods are also entering the field of process control programming. Software engineering methods and tools are being adapted (e . g. EPOS (Biewald and co-workers, 1979), and new programming techniques applied to process control. Data base systems optimized for realtime requirements simplify the implementation of many applications; functional or logical programming (e.g . PROLOG (Clocksin, Mellish, 1981)) unloads the programmer from the burden of detailing how a given problem has to be solved : He has only to specify what the problem is. Expert systems will help as well in the specification and planning phase as for man-machine communication . Finally, higher level functions have to be added to process control systems. There are short-term and mid-term pl anning functions that require communic-
ation with the corporate management information system : Long-term planning programs are usually running on that system, and their output should be used as input to short-term planning. The functions may even overlap and require detailed coordination - that is a political problem too. INTEGRATION INTO INFORMATION SYSTEMS Information Systems Architecture The hardware- and software-architecture of commercially-oriented information systems is dominated more and more by IBM and its history. Half a dozen other original system architectures have been displaced by the 370 and its modern successors (4300, 308X). Only a few manufacturers of compatible mainframes (Fujitsu, Amdahl ) have been able to get a noticeable market-share. The same holds true for the operating systems: IBM's VM- or MVS-systems are the basis of very significant investments into software development on the customers side. In most companies it is a hard fact that the software directions given by IBM have to be followed with no deviation . Information systems also tend to be distributed. Intelligent nodes migrate into the plants and subsidiaries and take over part of the workload from the large mainframes: The basic structure is very similar to distributed process control systems . Again IBM defines the standard for the interconnection of nodes and terminals: SNA (system network architecture) controls the logical information flow, and all other systems requiring access to the information system have to meet that standard (Randesi,1982). The information systems also need access to the process control installations to improve the company's efficiency : - There is an urgent demand for actual production data that allow the refinement of the planning process and the realization of quality control programs or recognition of weak points in the production process. - It is also important to transfer information to process control systems, e.g. actual long-term planning data that can be used locally or control information to influence production-priorities depending on the actual market situation . That requirement for strong interconnections between process control- and information systems increases as more production facilities become automated and can be adapted to the market requirements in a fast and flexible way. Smaller companies sometimes use non-IBM equipment; typically their information systems are based on midi-computers, e.g. on Digital Equipment products (PDPll, VAX). The communication to process control systems is then defined by the network architecture as specified by the supplier (e.g. DECNET ) : Unfortunately these networks are all incompatible. A lot of adaption work is therefore left for system houses specialized in communication software. Interconnection Problems The interconnection of networks with different architectures may be realized in more or less general ways: From a simple asynchroneous serial line supported by special application programs on both sides to a complete integration of all network functions.
Process Control and Information Systems
One of the most common solutions that allows the exchange of data between two systems is the emulation of a standard-terminal in one network (e .g. IBM 3780, 3270) by a program that resides in a node of the other network. Figure 7 shows the structure of hardware/software that has to be implemented: - On the emulation side (here: process control system) the data communication hardware and the protocol software (e .g. BSC, SOLC) has to be realized: Now both systems can exchange data in the form of byte streams. - Application processes must additionally be written on both sides that are able to interpret the data in a consistent manner - these programs are dependent on the individual application.
1683
access in both directions: Each terminal at the IBMsystem could be used for each process contro lapplication task. Since the full SJmmetry is difficult to achieve, and since most applications do not need that capabil ity, today most interconne ctions are realized as PU-2-emulations (CSI, 1983). Most problems one has to face in the data communication field are non-technical . On the one side, computer companies tend to hide information on the communication protocol - partly because of political reasons, and partly because it is very difficult to give detailed and complete specifications. On the other side, the responsibilities for process control and information systems usually are separated: That again causes non-technical problems due to undefined competences. Single Vendor Solutions
SYSTEM-SW
PS
HAROWARE
DH
One way to avoid all interconnection problems is to buy process control- and information systems from one vendor. Some companies are active in both fields; however, it is not always easy to intercon nect even networks of the same vendor (e.g. SINET and TRANSOATA from Siemens) since different branches of the company are responsible for the 2 network architectures. E.G. "BSC"
I BI1 -SYSTEM
--t---
PROCESS CONTROL SYSTEM
I ~
OA TA COMMUN I CAT I ON HARDWARE/SOFTWARE (PS: PROTOCOLL SOFTWARE; OH: OAT A COM. HARDWARE)
~
CORRESPONDING APPLICATION PROCESS
Fi g. 7
Communication via terminal emulation.
The terminal-emulation-method provides only restricted capabilities and requires a high degree of individual development. As an even less expensive solution a protocol converter can be used that performs all complex conversion functions in an additional hardware box (Bracker, 1983 ). A second solution already uses some of the architectural features in the network (e.g . SNA) and supports multiple interactive communications between tasks in both systems. Specifically, standard programs in the SNA-environment can be used without adaptation effort (e.g. access to IMS-information management system). In more detai 1: - The process control system node emulates an SNAdevice, PU-type 2 (phys ical unit): That allows multiprocess communication by submultiplexing (several simultaneous communication-relations that may use the same physical path). - In the process control system node one or more terminals may be emulated (e.g. 3278). That also allows any terminal connected to the process control system to access IBM-standard applications. - Logical connections may also be established between tasks in the process control system and tasks in the SNA-world. The way described above provides much more capabilities but still shows a unidirectional relationship: Process control tasks may access SNA-tasks, but SNA-tasks do not fit into the process control network architecture. To come to a completely symmetrical situation, the gateway has to be bidirectional: The cross-domain capabilities have to be implemented. In the SNAterminology, a PU-type-4-node is able to give
OEC offers a homogeneous network architecture. Coming from process control applications, the OECsystem grew into plant level tasks and even companywide systems. OECNET now offers a common network solution from the FALCON-single board computer to the mini-mainframe VAXll-780. Also IBM, by far the commercial market leader has l ong history in process control computing. After a good entry with the IBM 1800, the following generations (/7 and even /1) couldn't continue the suc cess. But now a new initiative has been started using hardware that has been available for years: Figure 8 shows how the ACS-system (advanced control system (IBM, 1983)) connects mainframes (/370) and process control computers (/1) and supports that combination with an integrated software package that is distributed among the 2 machines; also manmachine interaction is assisted by a new operator's console technology. These are efficient tools for the development of application programs. Today the system ist still restricted to very s low processes, but the involvement of IBM in the field of manufacturing automation (e.g. robotic systems) indicates further developments. IBM/l
IBM/370
I I
..---PROCESS { INTERFACE
lOP
I I I I
T ____ I SUPPORT
I I
Fig. 8
OPERATING SYSTEM SPEZI AL REAL Ti ME OPERATiNG SYSTEM OPER AlOR CONS OLE (S) lOP ACCESS METHOD
REAL TIME DATA BASE
DI SPLAY MANAGEMENT
Q
I----
PROCESS UN I T corHROL
I
REAL TIME USER PROGRAMS
I I
OTHER USER APPLICATIONS
Structure of ACS (advanced control system)
For the customer, the strong dependency on 1 vendor may be a serious problem: It is very difficult to add automation subsystems from other suppliers which
G. Farber
1684
may have more know-how or a better solution for the specific task. Standards and Gateways Individual solut ion for the interconnection problem as discussed in subchapter 2, and single vendorsolution (subchapter 3), both have ser ious disadvantages. It would be ideal to have an interconnection standard that i s used by all vendors for process control and information systems. The open system interconnection model as proposed by the ISO would be a good base for a communication standard, but unfortunately the 7 layers are not yet completely spec ified. In the contrary, more and more proposals are competing one against the other, and it may take many years to reach an agreed standard. That is especially true for the application-oriented layers that would allow each system to understand all the high-level commands and complex data representations of other systems . The requirement for public data communication will accelerate the standardization process, however the first definitions will be dedicated to text- and not to process control-applications.
CONCLUSION There is no doubt that process control- and information systems will logically grow together, and that other computer applications (CAD, CAE) in indu stry will join them. The demand for a common network architecture will therefore be strong. Today severa l physical networks are used for different applications (e.g. commercial, production control, building control, access control applications) that also geographically overlap. Figure 10 shows the vision of a common general purpose message transport system that carries all kinds of information: Similar to the phone system it may become a future standard-infrastructure in a plant. All subsystems are directly connected to that network that shows virtually now bandwidth limitation: Today broadband communication system (Cooper and co-workers, 1983) are a possible solution, but ETHERNETtype bus systems with an increased bandwidth (e.g. SUPERNET with 100 Mbit/ s or glasfiber networks in the gigabit-range) will also be candidates.
PROCE ss
Some companies are offering networks as an independent service: They provide a hardware/software solution for the networking problem even if computers of different manufacturers and with different architecture have to be connected. As an example, the FUSION-network (NRC, 1983) offers a limited set of network functions on the basis of a companyinternal protocol (e.g. variants of XNS or TCP/IP): File transfer and remote log-i n on machines like PDP11 / RSX, IBM / PC, VAX / VMS and different UNIX systems. Most other network vendors supply a much simpler information transport service. An intermediate way will be available in form of gateways: Similar to protocol converters (that perform the same function on the lower level of link control) they adapt network architectures by implementing 2 packages of network software in one hardware-software-box. Figure 9 shows that one side of the gateway has to conform to all protocol standards of network architecture A; the relevant information is exchanged on the application level of the gateway, and the other side executes the protocols of the network architecture B. The hardware expenses for that functionality must not be very high (e.g. there are complete gateways available on one MULTIBUS-board (XICor·l, 1983) but the software usually requires several man years of development. GATEWAY
A - B /~________J/'~________~,
APPLICATION PRESENTATION
PRESENTATION SESSION
SESSION
TRANSPORT
TRANSPORT
NETWORK
NETWORK
LINK
LINK
PHVS.
PHYS .
I NETWORK ARCH I TECTURE
A
Fig. 9
I
Fig. 10
Multipurpose digital network service . (FEe front-end compute~
This type of unstructured network seems to be a contradiction to the hierarchical logical structure of process control- and information systems as shown in Fig. 1. But the physical and the logical data paths do not necessarily correspond: The hierarchical logical structure is motivated by our mental inabi lity to master complexity without hierarchical models. Since all real time-processing is shifted to small front-end computers, the functional requirements for process contro l and information systems resemble each other more and more. The same hardware-software-technology will be applied to both fields, therefore even large companies cannot afford two system groups respons ible for data processing - and perhaps some of the interconnection problems stated in this paper will be solved by a redistribution of responsibilities and competences. REFERENCES
I
I --+NETWORK I I 1 I
CONTROL
ARCH I TECTURE
B
Gateway architecture according to the 7-L ayer- OSI -Model.
Biewald, J., et al. (1979). EPOS - A specification and design technique for computer controlled real-time automation systems. In Proceedings of the 4th Int. Conference on Software Engineering, Munlch 79 . Sprlnger, Berlln. pp. 245 - 250. Bracker, W.E. (1983). Surveying the protocol con version vendor's offerings. Data Communic~tions, August 83.
Process Control and Information Systems
Cl ocks i n, W. F. , and C. S. Mellish (1981). ming in Prolog. Springer, Berlin. Cooper, E.B., et al. (1983). broadband local networks. Feb. 83, 109-122.
Program-
Oesign issues in Oata Communications,
CSI Communications Solutions, Inc. (1983 ) . sNA: Technica l Overview, 89-101.
Access /
DIN 66253 (1981) Teil 1. Informationsverarbeitung Programmiersprache PEARL Basis PEARL; (1982) Teil 2. Informationsverarbeitung Programmiersprache PEARL Full PEARL. Beuth, Berlin. F~rber,
G. (1983). Konzept und Anwendung von Fe l dbussystemen mit verteilten Prozessperipherie Modu l n. In M. syrbe und M. Thoma (Ed.), Interkama 83 , Fortschritte durch digita l e Me B- und Automatisierungstechnik . Springer, Berlin. pp. 495-510.
IBM ( 1983). Advanced control system ACS. information manual.
General
IEEE (1981). Oct.19.
Draft B,
802 Local network standard.
Janetzky, D., et al . (1983). Oberblick iiber das verteilte Automatisierungssystem Teleperm-M und Losung der Obertragungsaufgaben mit dem Prozessbus CS275. In KfK-PDV 224, Kernforschungszentrum Kar l sruhe, Apnl 83 , pp. 211-246. Korn, G.A. (1977). Highspeed block-diagram languages for microprocessors and minicomputers in instrumentation, control, and simulation. In Fachtagung ProzeBrechner 1977. Springer, Berl i n. pp. 74 - 10B . MacWilliams, P.D., et al. (1984) . Microcontroller serial bus yields distributed multispeed con trol. Electronics, Feb. 9, 125-130. Mier, E. E. (1982). High-leve l protocols, standards, and the OSI reference model. Data Communications, July, 71 - 101. Mostek (1982). SCU 20 Serial control unit, operation manual. NRC Network Research Corporation Users guide.
( 1983).
FUSION:
Randesi, S.J . ( 1982). Interfacing minis and micros to IBM networks. Mini-Micro-systems, March 82 , 159-168. Ritchie, D.f1., et al. (1978). The UNIX-time - shar ing system. The Bell System Technical Journal, 7/8.78, 2Z., No. 6, Part 2, 1905-1930. Wa l ze, H. ( 1978). Bit serial communication in de centralized control systems - approaches for common solutions . IFAC Conference Helsinki. Wiemann, B., Ries, W. , Patz, M., F~rber, G., and Demmelmeier, F. ( 1981, 1982, 1983, 1984) . rtpSeminar Bussysteme. rtp Regelungstechnische Praxis, 23, 24, 25, 26. XICOM ( 19B3). ati on.
The SNA Micro Node.
Product Inform-
1685
.\C ~'dl 11 i\"I1111 .d \\"ol1d COll!.:1 \""" Bud,tpnl. Ilun g.ln. 1QS·I
Cn!'\ fI).{ln
PROCESS CONTROL AND INFORMATION SYSTEMS G. Farber
Abstract. Industrial process control systems are no longer isolated data processing island s: They need a strong interconnection to the company wide information system. Actual information concern ing the production process has to flow to the control system, and new planning and priority data have to be received in the other direction. This paper discusses the state and some future trends in process control computing , and analyses the possibil ities for the technical interconnection to management information systems. INTRODUCTION
INDUSTRIAL PROCESS CONTROL SYST EMS
Indu stria l applications of computer systems comprise process contro l and information management tasks. They have been developed in very different organisational environments: - Technical groups that have been responsible for conventional instrumentation or even installation are now planning and installing process control computers. They are still reporting t o the production-oriented management within the corporate organisation. - The data processing department started with simple administrative jobs ("pu nched card-era") and took over more and more responsibilities. With today's integrated management information systems it gains strong influence on top management.
Functions and Devices
Now both types of computer applications grow together and overlap: On the one hand they have to exchange data, on the other hand there is a certain competition in taking over new tasks.
Many of these functions can be standardized and parameterized; additionally there are usually application-dependent data processing tasks.
For process control appl ications it is easy to identify classes of functions that have to be performed by the computer-based devices . Examples are: - Data acquisation and data logging - Supervisory functions - Sequence contro l (as in storage programmed control - SPC) - Digital control (c l osed loop systems) - t~an-machine communication (including interaction and data presentation) - Data management (as in database systems).
Figure 1 shows the relationship between process control and informati on systems. Within a plant l ocal control systems provide the interfaces to the instrumentation at the technical process; several local control systems are coordinated by an area control system.
TO/FROM OTHER SUBSYSTE MS
The plant control system that integrates all areas in a plant may orig inate from the process control world and then would be typically based on a midicomputer. It may also be an extension of the company's information system: A powerful node in a distributed processing system. However, there is an interface between information and process control systems - either before or after the pla nt control instance - that has to interconnect both worlds.
51
~I 8 Oh Oh W
This interconnection is not an easy task, it generates technical problems as well as responsibility problems between groups that have been quite independent in the past.
U
~
The paper intend s to give an overview of the state of industrial process systems (chapter 2) as well as of recent trends to interconnect these to management information systems (chap ter 3). Some of the difficult gateway-problems are discussed here as well as the requirement for communication standards. Fig. 1 Hierarchical structure of production control systems . 1679
C. Farber
1680
These functions can be implemented in general purpose devices as in the conventional process control computer. Identical hardware (typically microprocessor-based) is used to perform different functions that are realized in software. That approach typically results in high costs for individual developments . A tendency toward dedicated devices can therefore be observed. To reduce system complexity only one class of functions is implemented in a device. Often dedicated and optimized hardware architectures are used and supported by application-oriented software development systems. Examples are the SPC's for sequence control, special data loggers or distributed control systems (e.g. TDC 2000). These dedicated devices are very usefull in lowcomplexity applications. Very often all the functions mentioned above arise in combination, therefore the individual devices have to at least exchange data. Unfortunately their communication capabilities are only weakly developed. Integration into Systems It is an important task therefore to integrate the isolated stations into common systems. The resulting network is able to exchange data and allows the sharing of instrumentation devices (e.g. sensors ) between different functions . It is obvious that one needs an interconnection network that allows the physical transport of information. Process control applications tend to use bussystems. Figure 2 shows that today's distributed systems do not rely on one bus type only : A hierarchy of busses interconnects all intelligent stations (Wiemann and co-workers, 1981 - 1984 ff) : - A lot of discussion and standardization effort has been spent on the process data highway (PROWAY (Walze, 1978)), that connects local frontend computers to the more powerful process control systems. - A plant data highway with higher bandwidth may connect these process control systems with each other and to a plant control computer. Data rates of up to 100 Mbit/s will be available in the near future; today ETHERNET could be a useful solution (10 Mbit/s (IEEE, 1981)) . - At the lowest level a very local bus (see subchapter 4) will replace todays expensive cabling
1., ,,50 MBIT/ S
'=~..::.:.~:.:..:..::::::.:::..:-++
____
0,1 " "
1 MBIT/ S
FRONT END COMPUTER
0,01 ,,"
2 MBIT/S
AM
ADAPTER MODUL
IS
INTELLIGENT SENSOR
PRODUCTION PROCESS
"
Fig. 2 Hierarchy of bus systems.
between the automation system and process instrumentation (Farber, 1983). The data rates may vary from 10 kbit/s to 2 Mbit/s that are now technologically possible (MacWilliams, 1984) and allow even very high data rates between sensor and front-end computer. Beside these serial bussystems all devices have internal parallel busses that interconnect the local modules. Still more important than the physical interconnection is the ability to exchange data that can be correctly interpreted on the other side. Here the 7-Layer-OSI-Model (open systems interconnection) is widely accepted (Mier, 1982). The layers up to the transportlayer (layer 4) are already subject of standard-proposals - unfortunately there is no common proposal for information systems- and process control-networks. Even more difficult is the definition of layer 5 and 6: - The session layer (5) establishes a common control language that is understood by different operating systems. - The presentation layer (6) is responsible for the internal representation of structured information (e.g. of an array of sensor values or text), and for the presentation of the data for the application programs. Today the application programmer is still responsible for the interpretation of all transmitted bits, he has to worry about operating system-commands and the structure of the data. In the future a common standard may help the programmer to use data and commands from other systems in the same way as on the machine he is attached to. The distributed process control systems available today still have only limited capabilities: They are applicable to the intended purpose, but it is difficult to program, e.g . sequence control algorithms on a TDC 2000 system. Teleperm M (Siemens (Janetzky and co-workers, 1983)) already offers more flexibility, and some new announcements (e.g . TDC 3000 from Honneywell) seem to meet all requirements for an integrated system - with the important disadvantage that only devices from one supplier can be tied into the network. Programming and Functional Distribution Programming conventional process control computers still happens mostly in a wellknown environment: - There is a real time-operating system that allows multitasking and provides for short reaction times after external events. - Programs are written in conventional languages like Fortran or Pascal; the languages usually are extended to support multitasking and I/O to process interfaces. Some newer languages have already standardized these features like PEARL (DIN 66253, 1981, 1982); ADA and - as a less complex and more elegant alternative - Modula-2 provide the basic mechanisms for multitasking and also support low-level functions. There is however not a significant advance since the application still has to be programmed in the well-known very detailed algorithmic way. The same environment is also available for multicomputer systems . Figure 3 shows an example of how local operating systems calls (e.g. interprocess communication) can be extended to a global service: In a RPC-layer ( remote procedure call) each system call is identified to be local : It then is directed to the local operating system and executed locally
Process Control and Information Systems
COMPUTER 2
COMPUTER 1
~
~---~
~
~ ---~ RPC - LAYER
RPC - LAYER
RTOS
TS
RTOS
TS
HARDWARE
TH
HARDWARE
TH
- -- 1
----t-
technical process. Subprocesses (requiring very different functions) may be bound to computers, all processing related to a subprocess takes place on one system - data transmission is minimized. Fault tolerance is also easier to obtain : A failure e.g. in a SPC-system would kill all sequence control functions in the process, whereas a failure in a computer dedicated to a subprocess would only affect that subprocess. It is also much simpler to provide redundancy if the redundant components are all identical . Future Trends
1
PHYSICAL TRANSMISSION
Fig. 3
1681
Distributed system architecture.
- or remote: Using Transport Software (TS) and Transport Hardware (TH) the call is directed to a remote operating system and the results are transmitted back and routed to the local caller. For the programmer the remote execution remains hidden, the system behaves like a single computer (transparency) . The distributed process control systems have also introduced application-oriented software packages that allow the use of prewritten functional modules (like control algorithms, sensor data acquisation etc.). These modules can be reused in many applications and therefore tend to become more and more reliable. For the programmer it looks like a block diagram language where functional modules may be invoked as blocks in a graphical environment (Korn, 1977): Blocks are generated, interconnected and parameterized; the system generates a runnable program automatically. New modules may be written in a conventional language and added to the module library. Whereas the first generation of these programming systems have been restricted to a single application (e.g. sequence control), new systems allow also the mixing of different functionalities . Figure 4 shows how, in mUlticomputer systems, different functions may be distributed among the single systems. Whereas the conventional monoprocessor system takes over all functions, - the horizontal distribution dedicates computers to executing only one class of functions (e.g. SPC's, DDC-systems etc.), and - the vertical distribution supports all functions on all computers and distributes the load among as many computers as required by the application.
The motivation for new developments in process automation systems is usually cost reduction. Some important aspects for future systems are: - Reduction of cabling and installation costs that may contribute 50% to total system costs. - Reduction of software development costs by providing better programming tools and an efficient programming support environment . - Reduction of costs that arise due to system failures : The addition of redundancy (hardware always becomes cheaper) reduces the probability of failures by an order of magnitude and saves the expense caused by these failures. To reduce installation costs semiconductor technology allows replacing expensive cables by powerful intelligent hardware modules . Figure 5 shows an example of a 'very local bus' that transports data and electrical power to adapter modules that provide very local process I/O. They may be mounted directly at process side, and cabling is reduced to a 2wire-bus . The basis of the adapter module is a single-chip microcomputer that performs the communication task and the process-I/O including all local supervisory and diagnostic functions. Preprogrammed chips (e.g. MOSTEK SCU 20 (Mostek, 1982)) are available with transfer rates up to 9600 bit/so New announcements (Intel 8044 (MacWilliams, 1984) ) indicate that the transfer rate restriction will disappear soon: Up to 2,4 Mbit/s will be available. In the long run perhaps these modules will be integrated into the sensors ('intelligent sensor') and the actuators, so cabling is reduced to interconnecting these devices by a 2-wire-cable. A standardization for the 'very local bus' then becomes very urgent. A short note should be given to the personal computers that are becoming cheaper and cheaper and that are also used in data logging applications. Their
AM: ADAPTER MODUL
BA: BUS ADAPTER
The first approach is much easier to understand and to implement, and hardware may be specialized for the individual task . But the vertical distribution allows a much better adaptation to the required performance and to the structure of the controlled
: } PROCESS : SIGNALS
CENTRAL! ZED FUNCT! ONS
DATA ACQUISITION SUPERVI SORY
DISTRIBUTION HOR I CONTAL VERT I CAL
[~~~~-~1 ! I~R I Cl
C 2
I - -I ~~ .
}
I NTELL I GENT SENSOR
M .C. •
CONTROL MAN MACHINE
Fig. 4
SYSTEM
CM
Horizontal and vertical distribution of functions in multicomputersystems.
VERY LOCAL BUS (DATA Al!Il POWER)
Fig. 5
Very local bus systems.
C. Farber
1682
stability (high-volume-production) makes them very well suited for small general purpose process control applications as well. Bus-compatible processI/ O-boards are already available and the keyboard as well as the display (with graphics and colour) provide a good man-machine interface. One requirement to master the famous 'software crisis' is a comfortable programming environment. A computer system providing that comfort normally cannot meet the real time requirements of process control systems. Figure 6 shows a syst~m configuration with 2 types of interconnected systems that can resolve that conflict (Ritchie, 1978): - A general purpose system based on a comfortable operating system (like UNIX) is used for the development including debugging of realtime programs. These programs are linked and loaded down to real time systems where they are executed under real time-constraints. The general purpose system als o performs 'slow' functions like file access, man-ma chine interaction or the execution of background tasks. - One or several realtime systems are based on effi c ient real time-operating systems and perform actual process-I / O as well als all time-critical t as ks. These tasks have been down-loaded from th e general purpose system; if an access to a f ile i s required or an operator intervention, corresponding (slow) tasks in the general purpo se sy s tem are activated. The conventional monolithic process control operating systems disappear and are replaced by standard systems on the one side ( identical to the systems used in commercial applications) and specialized small real time-executives on the other . The combination of both offers a homogeneous and easy to use surface for the applications programmer. GENERAL PURPOSE SYSTEM: COMFORTABLE OPERATING SYSTEM (E.G. UNIX)
=-C='==-T=R=AN=-S=P=OR=-T-=SY=S-T=EM='=
-
DEVELOPMENT DEBUGG I NG F I LE SYSTEMS MAN MACHINE INTERFACE BACKGROUND-TASKS.
-~
-
+--
REAL -T I ME-SYSTEM: - PROCESS 1/0 - REAL TIME-REACTION - TIME CRITICAL TASKS.
'~----~v~---_-J/
PROCESS INTERFACE
Fig . 6
General purpose- and real time-systems.
New software development methods are also entering the field of process control programming. Software engineering methods and tools are being adapted (e . g. EPOS (Biewald and co-workers, 1979), and new programming techniques applied to process control. Data base systems optimized for realtime requirements simplify the implementation of many applications; functional or logical programming (e.g . PROLOG (Clocksin, Mellish, 1981)) unloads the programmer from the burden of detailing how a given problem has to be solved : He has only to specify what the problem is. Expert systems will help as well in the specification and planning phase as for man-machine communication . Finally, higher level functions have to be added to process control systems. There are short-term and mid-term pl anning functions that require communic-
ation with the corporate management information system : Long-term planning programs are usually running on that system, and their output should be used as input to short-term planning. The functions may even overlap and require detailed coordination - that is a political problem too. INTEGRATION INTO INFORMATION SYSTEMS Information Systems Architecture The hardware- and software-architecture of commercially-oriented information systems is dominated more and more by IBM and its history. Half a dozen other original system architectures have been displaced by the 370 and its modern successors (4300, 308X). Only a few manufacturers of compatible mainframes (Fujitsu, Amdahl ) have been able to get a noticeable market-share. The same holds true for the operating systems: IBM's VM- or MVS-systems are the basis of very significant investments into software development on the customers side. In most companies it is a hard fact that the software directions given by IBM have to be followed with no deviation . Information systems also tend to be distributed. Intelligent nodes migrate into the plants and subsidiaries and take over part of the workload from the large mainframes: The basic structure is very similar to distributed process control systems . Again IBM defines the standard for the interconnection of nodes and terminals: SNA (system network architecture) controls the logical information flow, and all other systems requiring access to the information system have to meet that standard (Randesi,1982). The information systems also need access to the process control installations to improve the company's efficiency : - There is an urgent demand for actual production data that allow the refinement of the planning process and the realization of quality control programs or recognition of weak points in the production process. - It is also important to transfer information to process control systems, e.g. actual long-term planning data that can be used locally or control information to influence production-priorities depending on the actual market situation . That requirement for strong interconnections between process control- and information systems increases as more production facilities become automated and can be adapted to the market requirements in a fast and flexible way. Smaller companies sometimes use non-IBM equipment; typically their information systems are based on midi-computers, e.g. on Digital Equipment products (PDPll, VAX). The communication to process control systems is then defined by the network architecture as specified by the supplier (e.g. DECNET ) : Unfortunately these networks are all incompatible. A lot of adaption work is therefore left for system houses specialized in communication software. Interconnection Problems The interconnection of networks with different architectures may be realized in more or less general ways: From a simple asynchroneous serial line supported by special application programs on both sides to a complete integration of all network functions.
Process Control and Information Systems
One of the most common solutions that allows the exchange of data between two systems is the emulation of a standard-terminal in one network (e .g. IBM 3780, 3270) by a program that resides in a node of the other network. Figure 7 shows the structure of hardware/software that has to be implemented: - On the emulation side (here: process control system) the data communication hardware and the protocol software (e .g. BSC, SOLC) has to be realized: Now both systems can exchange data in the form of byte streams. - Application processes must additionally be written on both sides that are able to interpret the data in a consistent manner - these programs are dependent on the individual application.
1683
access in both directions: Each terminal at the IBMsystem could be used for each process contro lapplication task. Since the full SJmmetry is difficult to achieve, and since most applications do not need that capabil ity, today most interconne ctions are realized as PU-2-emulations (CSI, 1983). Most problems one has to face in the data communication field are non-technical . On the one side, computer companies tend to hide information on the communication protocol - partly because of political reasons, and partly because it is very difficult to give detailed and complete specifications. On the other side, the responsibilities for process control and information systems usually are separated: That again causes non-technical problems due to undefined competences. Single Vendor Solutions
SYSTEM-SW
PS
HAROWARE
DH
One way to avoid all interconnection problems is to buy process control- and information systems from one vendor. Some companies are active in both fields; however, it is not always easy to intercon nect even networks of the same vendor (e.g. SINET and TRANSOATA from Siemens) since different branches of the company are responsible for the 2 network architectures. E.G. "BSC"
I BI1 -SYSTEM
--t---
PROCESS CONTROL SYSTEM
I ~
OA TA COMMUN I CAT I ON HARDWARE/SOFTWARE (PS: PROTOCOLL SOFTWARE; OH: OAT A COM. HARDWARE)
~
CORRESPONDING APPLICATION PROCESS
Fi g. 7
Communication via terminal emulation.
The terminal-emulation-method provides only restricted capabilities and requires a high degree of individual development. As an even less expensive solution a protocol converter can be used that performs all complex conversion functions in an additional hardware box (Bracker, 1983 ). A second solution already uses some of the architectural features in the network (e.g . SNA) and supports multiple interactive communications between tasks in both systems. Specifically, standard programs in the SNA-environment can be used without adaptation effort (e.g. access to IMS-information management system). In more detai 1: - The process control system node emulates an SNAdevice, PU-type 2 (phys ical unit): That allows multiprocess communication by submultiplexing (several simultaneous communication-relations that may use the same physical path). - In the process control system node one or more terminals may be emulated (e.g. 3278). That also allows any terminal connected to the process control system to access IBM-standard applications. - Logical connections may also be established between tasks in the process control system and tasks in the SNA-world. The way described above provides much more capabilities but still shows a unidirectional relationship: Process control tasks may access SNA-tasks, but SNA-tasks do not fit into the process control network architecture. To come to a completely symmetrical situation, the gateway has to be bidirectional: The cross-domain capabilities have to be implemented. In the SNAterminology, a PU-type-4-node is able to give
OEC offers a homogeneous network architecture. Coming from process control applications, the OECsystem grew into plant level tasks and even companywide systems. OECNET now offers a common network solution from the FALCON-single board computer to the mini-mainframe VAXll-780. Also IBM, by far the commercial market leader has l ong history in process control computing. After a good entry with the IBM 1800, the following generations (/7 and even /1) couldn't continue the suc cess. But now a new initiative has been started using hardware that has been available for years: Figure 8 shows how the ACS-system (advanced control system (IBM, 1983)) connects mainframes (/370) and process control computers (/1) and supports that combination with an integrated software package that is distributed among the 2 machines; also manmachine interaction is assisted by a new operator's console technology. These are efficient tools for the development of application programs. Today the system ist still restricted to very s low processes, but the involvement of IBM in the field of manufacturing automation (e.g. robotic systems) indicates further developments. IBM/l
IBM/370
I I
..---PROCESS { INTERFACE
lOP
I I I I
T ____ I SUPPORT
I I
Fig. 8
OPERATING SYSTEM SPEZI AL REAL Ti ME OPERATiNG SYSTEM OPER AlOR CONS OLE (S) lOP ACCESS METHOD
REAL TIME DATA BASE
DI SPLAY MANAGEMENT
Q
I----
PROCESS UN I T corHROL
I
REAL TIME USER PROGRAMS
I I
OTHER USER APPLICATIONS
Structure of ACS (advanced control system)
For the customer, the strong dependency on 1 vendor may be a serious problem: It is very difficult to add automation subsystems from other suppliers which
G. Farber
1684
may have more know-how or a better solution for the specific task. Standards and Gateways Individual solut ion for the interconnection problem as discussed in subchapter 2, and single vendorsolution (subchapter 3), both have ser ious disadvantages. It would be ideal to have an interconnection standard that i s used by all vendors for process control and information systems. The open system interconnection model as proposed by the ISO would be a good base for a communication standard, but unfortunately the 7 layers are not yet completely spec ified. In the contrary, more and more proposals are competing one against the other, and it may take many years to reach an agreed standard. That is especially true for the application-oriented layers that would allow each system to understand all the high-level commands and complex data representations of other systems . The requirement for public data communication will accelerate the standardization process, however the first definitions will be dedicated to text- and not to process control-applications.
CONCLUSION There is no doubt that process control- and information systems will logically grow together, and that other computer applications (CAD, CAE) in indu stry will join them. The demand for a common network architecture will therefore be strong. Today severa l physical networks are used for different applications (e.g. commercial, production control, building control, access control applications) that also geographically overlap. Figure 10 shows the vision of a common general purpose message transport system that carries all kinds of information: Similar to the phone system it may become a future standard-infrastructure in a plant. All subsystems are directly connected to that network that shows virtually now bandwidth limitation: Today broadband communication system (Cooper and co-workers, 1983) are a possible solution, but ETHERNETtype bus systems with an increased bandwidth (e.g. SUPERNET with 100 Mbit/ s or glasfiber networks in the gigabit-range) will also be candidates.
PROCE ss
Some companies are offering networks as an independent service: They provide a hardware/software solution for the networking problem even if computers of different manufacturers and with different architecture have to be connected. As an example, the FUSION-network (NRC, 1983) offers a limited set of network functions on the basis of a companyinternal protocol (e.g. variants of XNS or TCP/IP): File transfer and remote log-i n on machines like PDP11 / RSX, IBM / PC, VAX / VMS and different UNIX systems. Most other network vendors supply a much simpler information transport service. An intermediate way will be available in form of gateways: Similar to protocol converters (that perform the same function on the lower level of link control) they adapt network architectures by implementing 2 packages of network software in one hardware-software-box. Figure 9 shows that one side of the gateway has to conform to all protocol standards of network architecture A; the relevant information is exchanged on the application level of the gateway, and the other side executes the protocols of the network architecture B. The hardware expenses for that functionality must not be very high (e.g. there are complete gateways available on one MULTIBUS-board (XICor·l, 1983) but the software usually requires several man years of development. GATEWAY
A - B /~________J/'~________~,
APPLICATION PRESENTATION
PRESENTATION SESSION
SESSION
TRANSPORT
TRANSPORT
NETWORK
NETWORK
LINK
LINK
PHVS.
PHYS .
I NETWORK ARCH I TECTURE
A
Fig. 9
I
Fig. 10
Multipurpose digital network service . (FEe front-end compute~
This type of unstructured network seems to be a contradiction to the hierarchical logical structure of process control- and information systems as shown in Fig. 1. But the physical and the logical data paths do not necessarily correspond: The hierarchical logical structure is motivated by our mental inabi lity to master complexity without hierarchical models. Since all real time-processing is shifted to small front-end computers, the functional requirements for process contro l and information systems resemble each other more and more. The same hardware-software-technology will be applied to both fields, therefore even large companies cannot afford two system groups respons ible for data processing - and perhaps some of the interconnection problems stated in this paper will be solved by a redistribution of responsibilities and competences. REFERENCES
I
I --+NETWORK I I 1 I
CONTROL
ARCH I TECTURE
B
Gateway architecture according to the 7-L ayer- OSI -Model.
Biewald, J., et al. (1979). EPOS - A specification and design technique for computer controlled real-time automation systems. In Proceedings of the 4th Int. Conference on Software Engineering, Munlch 79 . Sprlnger, Berlln. pp. 245 - 250. Bracker, W.E. (1983). Surveying the protocol con version vendor's offerings. Data Communic~tions, August 83.
Process Control and Information Systems
Cl ocks i n, W. F. , and C. S. Mellish (1981). ming in Prolog. Springer, Berlin. Cooper, E.B., et al. (1983). broadband local networks. Feb. 83, 109-122.
Program-
Oesign issues in Oata Communications,
CSI Communications Solutions, Inc. (1983 ) . sNA: Technica l Overview, 89-101.
Access /
DIN 66253 (1981) Teil 1. Informationsverarbeitung Programmiersprache PEARL Basis PEARL; (1982) Teil 2. Informationsverarbeitung Programmiersprache PEARL Full PEARL. Beuth, Berlin. F~rber,
G. (1983). Konzept und Anwendung von Fe l dbussystemen mit verteilten Prozessperipherie Modu l n. In M. syrbe und M. Thoma (Ed.), Interkama 83 , Fortschritte durch digita l e Me B- und Automatisierungstechnik . Springer, Berlin. pp. 495-510.
IBM ( 1983). Advanced control system ACS. information manual.
General
IEEE (1981). Oct.19.
Draft B,
802 Local network standard.
Janetzky, D., et al . (1983). Oberblick iiber das verteilte Automatisierungssystem Teleperm-M und Losung der Obertragungsaufgaben mit dem Prozessbus CS275. In KfK-PDV 224, Kernforschungszentrum Kar l sruhe, Apnl 83 , pp. 211-246. Korn, G.A. (1977). Highspeed block-diagram languages for microprocessors and minicomputers in instrumentation, control, and simulation. In Fachtagung ProzeBrechner 1977. Springer, Berl i n. pp. 74 - 10B . MacWilliams, P.D., et al. (1984) . Microcontroller serial bus yields distributed multispeed con trol. Electronics, Feb. 9, 125-130. Mier, E. E. (1982). High-leve l protocols, standards, and the OSI reference model. Data Communications, July, 71 - 101. Mostek (1982). SCU 20 Serial control unit, operation manual. NRC Network Research Corporation Users guide.
( 1983).
FUSION:
Randesi, S.J . ( 1982). Interfacing minis and micros to IBM networks. Mini-Micro-systems, March 82 , 159-168. Ritchie, D.f1., et al. (1978). The UNIX-time - shar ing system. The Bell System Technical Journal, 7/8.78, 2Z., No. 6, Part 2, 1905-1930. Wa l ze, H. ( 1978). Bit serial communication in de centralized control systems - approaches for common solutions . IFAC Conference Helsinki. Wiemann, B., Ries, W. , Patz, M., F~rber, G., and Demmelmeier, F. ( 1981, 1982, 1983, 1984) . rtpSeminar Bussysteme. rtp Regelungstechnische Praxis, 23, 24, 25, 26. XICOM ( 19B3). ati on.
The SNA Micro Node.
Product Inform-
1685