Copyright © IFAC Real Time Programming Kyoto. Japan. 1981
PROSUS: A SOFTWARE PACKAGE FOR INDUSTRIAL CONTROL Y. Miyoshi, A. Asanuma, H. Ukaji, N. Nagata and O. Sasaki Fuchu Works , Toshiba Corporation , Tokyo , japan
ABSTRACT PROSUS (PRocess Oriented system SUpport Software) is an approach to overcome confl ict between product ivi ty and high speed response needed for real time industrial control softwares. By using modularized attached package concept, PROSUS has been able to satisfy the requirements both performance and productivi ty.
1.
In industrial process computers, operating system must be generally rather simple and compact size, which can only operate task scheduling, physical I/O driver and interrupt handling etc.
INTRODUCTION
The function requirements to industrial computer control systems before 1975 were entirely purposed to control physical equipments such as valves and motors. However, since 1976 increasing amount of jobs to handle those kind of information concerned wi th management control and production control have come wi thin the scope of process control systems. Fortunately, computers called mega-mini have main memories sizing more than have been brought into market. These been accepted as suitable computers can satisfy these current requirements.
By using attached software package PROSUS to support the functions which are not supplied by the operating system, application software will be able to be made easily and uniformly. PROS US is consisted of numbers of subsystems which have been designed to be utilized with ease.
with 1 ME have which
Each subsystem is operated ground or background mode.
The software to handle these wide range and large amount of informations from physical control to management control needs high grade programming techniques such as data base system and hardware independent I/O access method etc. because of high productivity. These software technologies had been already accomplished in the field of general purpose computer or business application systems.
in either
fore-
*
As for the foreground mode, PROS US will be able to be interlinked to application programs with using macro instructions .
*
As for the background mode, PROS US has many utilities which are available through interactive man/maChine terminals.
These subsystems are independent basically of each other, and they are able to be freely selected. Through application software, the subsystem modules are flexibly connected to each other, and then they can build up the effective software system.
However, in order to control industrial plant mechanics quick response or parallel response is a great concern in most cases. Therefore, introduction of high grade software techniques into industr ial control application should be met some difficult problems mainly concerned with conflict between system performance and productivity. PROSUS (PROcess Oriented system SUpport Software) is an approach to solve this problem.
By this modularized attached package approach, we have been able to satisfy the requirements both performance and productivity.
69
Y. Miyoshi et al.
70 2.
COMPOSITION
Main functions of a standard package:
As figure I shows, PROSUS is located between operating system and application software. By using PROSUS, engineers can easily develop application systems without taking account of operating system depending on the physical access methods of input and output devices.
--------------
-
.... ....
...
"
------,
USER
"-
... ....
APP LICAT IO N PROGRAM
----Figure I
Overview of PROSUS
PROSUS is composed of standard packages and generation system. Standard packages include Data management, I/O service, System support and System monitor. These are incorporated in application systems, and are attached to a TOSBAC series 7/ 70 process computer. The generation system supports the PROSUS standard packages to be incorporated into application systems, and is processed by a large scale general-purpose computer. Configuration of PROSUS Data management system system File and record management (PROFAM) Data base management system (PRODBMS)
t
I / O service system BUSiness terminal I / O service system (PRCYl'AM) Data telecommunication service system (PRCYl'CS) Process I / O service system (PROPIO)
t
System support Journal service system (PROJNL) Business terminal diagnostic service system (BIOTST) Process I / O simulation service system (PIOSIM) Process I / O diagnostic service system (PIOTST) Symbolic file system maintenance (SYMFAM) System monitor Execution monitor system (PROMOS) Generation system
File and record management system (PROFAM): This provides file access method with only logical information, such as file names, without using physical information, such as addresses. This service system includes file creation and deletion functions as well. Data base management system (PRODBMS): It provides multi-file and multi-record processing. It provides a very simple Data Base access mode. Business terminal I / O service system (PRCYl'AM) : It provides I / O processing for business terminals such as video terminal, typewriter and line printer. Data telecommunication service system (PRCYl'CS) : It provides data telecommunication processing through pattern classifications of operation sequences which are being adopted in a large variety. Process I / O service system (PROPIO): It samples process signals with logical names, and performs limit check, data conversion, and maximum/ minimum monitoring. Journal service system (PROJNL): It gathers required informations at any time during program execution. Business terminal diagnostic service system (BIOTST): It performs diagnostic tests of peripheral devices, such as video terminal, typewriter, and line printer, at any time during online operation. Process system I / O simulation servi c e (PIOSIM) : It simulates process I / O signals. It enables simulation without modifying user software. Process I / O diagnostic service system (PIOTST) : It performs diagnostic tests of process I / O signals at any time during online operation. This function can also be efficiently used for remote process input output devices. Symbolic file maintenance system (SYMFAM): It updates file contents by using character string code, such as file names and item names. It prov ides efficient file maintenance tool. Execution monitor system (PROMOS): It monitors application behavior. It gathers resource utilization data, such as main memory, bulk memory and else, and also task traces to evaluate system performance, at any time during online operations.
71
PROSUS: A Software Package for Industrial Control 3.
PURPOSE AND FEATURES
PROSUS improves productivity and quality of large-scale, complicated application software development without reducing the fast response required for process control. 3.1 Improvement of Productivity and Quality (1)
Standard packaging
Macro-calls are provided for standard functions to be performed in application software systems ,. For instance, in I/O processing of process signals (P I/O), such as digital and analog I/O signals, the input and output operations of process signals, upper and lower limit check, and engineering unit conversion can be performed simply by calling a single macro. By using these standard functions, the number of special purpose programming based on individual requirements is reduced. As well as productivity improvement, it provides high quali ty system by using these already tested packages. (2) Device independency and OS independency Because PROSUS deals with everything related directly to hardware, such as process I/O devices and the controller, and to operating system, only m1n1mum modification of application software is needed upon alteration of application systems. This allows standardized method for these development of software. (3) Tabulation of non-common requirements and minimization of program logic Developing standard routines, it is generally difficult to decide to what extent application-peculiar requirements should be incorporated and how to implement them. In PROS US , these requ irements are separated from the program logic and are tabulated. Application engineer define these data and processing procedures in a table (in the memory or bulk memory) by using PROSUS utilities in advance. The data registered in this table can be tested independently of the application program to conf irm the adequacy. In application programs, only data which changes according to the online operations needs to be taken into conisideration, so that the development and testing are easy. 3.2 High-speed Response Requirement In general, if software systems are designed as standard packages, the productivity of appl ication software increases, but the overhead time of the system also increases, and consequently the response time goes down. PROSUS has been designed that only modules which are necessary only to application systems can be fetched through system generation. By this way, PROSUS provides high-performance for the response time.
(1) Independency between subsystems No subsystem of PROSUS depends on the functions of the other subsystems 1 each is independent of the others. To make an application system, only required subsystems need to be introduced. (2) Subsystem generation by required modules only Each subsystem is composed of several functional modules. For instance, PROPIO is composed of an input service module, output service module, and interruption module. PROFAM is composed of file I/O service program modules which support various file access methods. These functions of each subsystem are provided in the form of macro instructions. To build an user applied system, however, only required macro instructions are selected. In addition, PROSUS provides different program body depending on user's requirement. PROS US has several macro bodies which have the same function. For instance, for the file and record management system, although the same macro name is used, the program module to be selected differs depending on whether it supports ISF (Indexed Sequential File). Because the macro instructions without ISF, does not need the program module for an index processing. (3) Tables in main memory PROS US can deal types of tables:
with
the
following
three
A table in which processing procedures and data editing methods are registered. For instance, in the business terminal I/O service system, the Video display I/O format information and the data editing method information are registered in this table. A storage area for data set by application programs. For instance, in the business terminal I/O service system, the output image data such as those of Video display and typewriter is stored in this table. A control table used internally by PROSUS. For instance, the index area of ISF files and the file control table for each file. In PROSUS, these tables can be established in the main memory or bulk memory. For systems required high-speed response, these tables are all made in the main memory. The selection of the main or bulk memory in which the tables are to be located can be specified in an online interactive mode by using PROSUS utilities. (4)
Setting of fast routines
When a high-speed response is especially required, fast routines can be used, in place of standard processing. For instance, ISF (Indexed Sequential File),
72
Y. Miyoshi
is provided as a filing format to store data. This is a file organization method where required data can be directly fetched by specifying key values in application programs. In PROSUS, the index table is searched according to a specified key value to obtain the address of the record where the key value is stored, and the data required by the application program is fetched according to the address, and set to the application program. In fast routines, when new data is written into files, PROSUS returns the written address (record number) to the application program. Thus, the application program can obtain required data quickly by specifying the record number wi thout searching the index area of key values.
4.
SUBSYSTEMS EXAMPLE
To demostrate the functions of PROSUS for a process computer software and the features to get high-speed response, in this chapter, we explain the following subsystems: file and record management system (PROFAM), business terminal I/O service system (PROTAM), and process I/O service system (PROPIO) • 4.1
File and (PROFAM)
(1)
File organization
Record
Management
System
et aZ. (2)
Data access
(a)
I/O buffer control
Pool control of I/O buffers is used, and read blocks are stored in a pool. When an application program requests a certain record, first the existence in the pool of a block containing the record is checked. If the block exists in the pool, no access to external media is performed. If the record does not exist in the pool, the block containing the record is read into the pool. In this case, if the buffer pool has no vacancy, the oldest block in the pool is aborted, and the object block is read into its place. Wri ting to bulk memory need not to be performed for each file closing. It is performed only when there is no task using the file any more, or when the buffer pool is full and the pool needs to be cleared for another task. (b)
For files that are often accessed or require a high-speed response, a file control block can be retained in the main memory to control file access. All files are classified in seven levels according to their processing priorities. The file control block of files having the first priority is automatically retained in the main memory. (c)
There are four file supported in PROSUS.
organization
methods
Relative file (RF) A file where relative record numbers counting from the first record in the file are given for record retrieval. Circular file
(CF)
A modification of a relative file having a circular structure. The range of significant data is controlled by an in-pointer and an out-pointer. As data are added or deleted, the in-pointer and out-pointer are shifted circularly.
Concurrent access control
(ISF)
A file in which records have particular key values in their specific fields for record retrieval. Indexed circular file
Data recovery
There are two kinds of data used in PROFAM: file data to be registered and referred to in application systems, and control data for the PROFAM system. The former comprises main memory file data and bulk file data, and the latter comprises catalog information for files and index information for key access. To prevent these data from being destroyed by abnormal operation of the system, functions to read the data into a save file or to load them from such a file are provided as a macro or a utility. In application systems, the macro can be incorporated into the application programs, if necessary. Then, the timing of saving can be selected for each file depending on the importance of the file data. (3)
Indexed sequential file
Priority control
(ICF)
A file where occurrence order access and key access of records are performed efficiently. By specifying key value in application program, data can be refer red to randomly or sequentially in the order of event occurrence. A main memory area can also be handled as a file, with access by record number s or key values available.
Files supported by PROFAM are accessed at random by several tasks. Therefore, depending on the timing of file updating, the validity of the data cannot always be guaranteed. To solve this problem, PROFAM has two levels of exclusive control function. . Exclusive control of file In general, modes: NO WHILE WRITE, any of these
there are four exclusive control SHARE, SHARE READ, SHARE READ and SHARE FREE. PROFAM can use modes for data guarantee.
PRO SUS : A Softwa re Pa ckage f o r Industri a l Con tr o l
73
• Exclusive control for each record
4.3
Exclusive control for each record is provided to guarantee the contents of records upon updating of record data. When several tasks request update of the same record simultaneously, some of the update requests may be ignored as a result. To solve this problem, in PROFAM, if one task has already started reading to update a record, other tasks are forbidden to read the record for updating until the first task writes the update data. This is referred to as exclusive possession of a record. The exclusively possessed record is released at the end of updating or at file closing.
To access process I/O devices, hardware attr ibutes, such as controller, type of Process I / O, group, and bit, need to be specified.
Unlike business computer systems, process computer systems have little creation of new records but a lot of updating operations. It is one of the features in PROFAM that several tasks can update the same file simultaneously and efficiently. 4.2
Business (PRCYrAM)
Terminal
(1)
Oevice independency
I/O
Service
System
For online system operation, it is conven ient for the user, especially when there is terminal trouble, to be able to change I / O device arbitrarily without modifying the application program. Using a simple utility, PRCYrAM can switch between I/O devices of the same type, or of different types, arbitrarily.
Process I/O Service System (PROPIO)
PROPIO frees application software programmers from these troublesome procedures and enables access of process I / O devices simply by specifying the logical name of an object device and the operation to be executed. such as "Open valve No. 1." In PROPIO subsystem, point identification numbers (PlO NO) are logical name to point the process input output devices. In application softwares, then, process I/O devices are accessed by specifying these PlO NOs. (1)
Tabulation of processing functions
PlO information describes the contents of PlO NO: Process I / O (01, AI, etc.), controller, group, bit, and processing. The PlO information can be registered in main memory or bulk storage, and is classified according to types of Process I / O and processing modes. In application software, process input and output operations can be executed by specifying PlO NO and calling macros for input, output, and interruption. At this time, it is unnecessary to consider hardware or the operating system. (2)
High-speed response
For devices of different types, for instance Video display and line printer, device control data proper to each device (cursor specification of Video display; control codes such as blink, inverse, and double size; VPG (variable pattern generator) codes; and line control codes of line printer) is converted accordi ng to the particular output device. When outputting Video display data to a line printer, the control codes are ignored or converted into predetermined special codes.
Normally PlO information are stored in the bulk memory. For application systems requiring high-speed response, the PlO information may be stored in the main memory. Among the PlO information, data that can be edited before the output operation, is converted into output images in advance, then stored in the main memory.
(2)
TOSHIBA has a software production system called the SWB. The purpose of SWB is to improve the productivity and quality of software with host computer (large scale general-purpose computer). The PROS US Generation System is operated under SWB.
I / O format independency from program
Oata editing formats are prepared in advance in the background mode, using PRCYrAM utility. Application software need only specify data that differs during online operation. That is, application software need not do any of the following: Fixed data specification, data conversion specification, line and page control for line printer output, or cursor specification for Video di splay. Thus, the program logic of application software can be simplified, and formats can be easily modified. Because registered I / O formats can be tested independently of application software, validity must be confirmed only data that differs due to online systems when testing application software.
5.
5.1
GENERATION SYSTEM OF PROSUS
Configuration of Generation System
Figure 2 shows the configuration of Generation System. Generation system generates program module required by application systems, based on generation control data base which consist of the subsystem specification table, a module tree table, and module description table. As a supplementary function, this system generates program modules which initialize PROSUS control information table for each application software.
Y. Miyoshi
74
Program lib r ary
et al .
Source code Object code Compil e list i mage
Subsystem spec i f i c a tion tab l e Module t r ee table Modu l e descr i p ti on table
Generation
r~
Generation system
Release objects (object , source , etc.) Release objects
configura t ion o f Gene r atio n System
Fi gure 2 5.2
(2)
Selection of Module
We explain usage of these tables in case of PROFAM. (1)
specification
Subsystem specification table
Table 1 shows the subsystem specification table. In PROFAM, four file organization methods, Relative file (RF), Circular file (CF), Indexed circular file (ICF), and Indexed sequential file (ISF), are supported. Depending on application systems, however, only RF and CF may be used. In this case, a PROFAM menu is provided to support only RF and CF. To distinguish these menus, special codes, each consisting of the subsystem name and a group number, such as PROFAMGOl and PROFAMG02, have been given to the respective menus.
Unlike a PROFAM that supports all the file organization methods, a PROFAM that supports only RF and CF does not need the GETK macro and the like for key access. The GETL macro, which is used to access records sequentially, supports all the file organization methods. However, a PROFAM that supports only RF and CF does' not need the logic for processing ICF and ISF.
A subsystem specification table has been made for every code, and stored in the generation control data base. These codes are used to select necessary module according to the generation requirements of application systems, and called "TOP modules" because they are located at the top in the module tree table. Ta b l e 1 TOP module name
Module tree table
Upon first development of this macro, it was planned that processes that differ depending on file organization methods should be decided by the upper modules as far as possible so that the lower modules can have functional strength. Although processing modules of each file organization method use a lot of common modules as submodules, the processing modules have an independent module structure for each file organization method. Therefore, it is very easy to cut off the processing part of the file organization that need not to be supported. This can be car ried out easily and securely in an interactive mode by using a general-purpose computer system.
Subsystem Spec i f i c a tion Ta b l e
Subsystem name
Computer system
File organization
Main memory file
PROFAM
Multiple computer system
RF, CF rCF, rSF
Provided
PROFAMGOl
Provided
PROFAM
Multiple computer system
RF, CF
PROFAMG02
75
PROSUS: A Software Package for Industrial Control In thi sway, a lot of modules can be made, which support different scopes although having the same functions. These modules have been the same subroutine names, but are distinguished by their group numbers given as a suffix; the name GETLGOl is given to the GETL macro that supports all of the file organization methods, the name GETLG02 is given to that which supports only RF and CF, and so on.
specifications of an application system are given, all modules necessary for the application system can be found by exploding the module tree table, starting from the TOP modules.
In this way, module trees are formed, where each subsystem menu has necessary minimum functions only. These module trees are registered as a module tree table in the generation control data base. When the
Table 2 is an information table for modules, and most items are generated automatically through the source program. In this table, subroutine name, revision number, module size, etc. are registered for each module.
Figure 3 Structure. (3)
shows
the
PROFAM
Module
Tree
Module description table
PROFAMGOl
PROFAMG02
Utility program group
Macro group
I I
I
GETLGOl
Ut i lity program group
I
Macro group
I
II
~GETLG02
GETK
~\
Same ma c ro name , but different contents
Not provi ded in PROFAMG02
Figure 3
PROFAM Modu l e Tree Structure
Ta bl e 2 Module name
Subrou t i ne Rev . No. name
Modul e
Ma ximum s t ack s iz e t o be us e d
s ~z e
GETLGO l
GETL
OlDl
500 by t es
GETLG02
GETL
0 103
400 by t es
5. 3
Mo du l e Desc ri pti on Tabl e
(b)
Generation Procedure
The generation is car ried out through lowing four steps: Reception of generation conditions Selection of TOP module Explosion of subordinate modules Release
fol-
Program divi s i on
Description o f functions
Selection of TOP module
Various subsystem menu are discriminated by TOP module names on the module tree table. The specifications in the system generation menu are converted to TOP module names using the subsystem specification table. (c)
(a)
Maximum buffer s iz e t o be use d
Explosion of subordinate modules
Reception of generation conditions
As figure 4 shows, the operator selects required functions acco rding to inductive messages, which are provided to each subsystem. The operator also specifies the release objects (object code, source code, system specification, etc. ) and the release medium (FDD, paper tape, card, list, etc . )
The module tree table is similar to bills of mater ial for hardware. In the same way as parts explosion, module tree table can be exploded starting from a TOP module, until all required module names are found. (d)
Release
The
exploded
module
names
are
given
ap-
Y. Miyoshi
76
et at.
[Sub system menu] 1. PROFAM
2. PROTAM
3. PROPIO .... .
I PROFAM I
SUB SYSTEM?
.....
Se l ection of PROFAM
[File organization method menu] 1.RF
2 . CF
3. ICF .
FILE ORGANIZATION?
4 . ISF
RF, CF
MAIN MEMORY FI LE (YES or NO)?
- .- .. Selection of RF and CF . .. . . Support of main memory f il e
[Release media] 1. FDD
2 . PTP
3. MT
OBJECT PROGRAM?
Figure 4
Inductive Message for Genera t ion
plication system information, subsystem name, and revision number, and stored in the release information data base. The program has been stored in the SWB system in the form of source code, object code, and compile list. The program need not to be compiled at each generation, so that only medium conversion is performed. At the time when the program is released, the generated module conifiguration table of the PROSUS system and the specification list of the modules are generated.
6.
CONCLUSION
Through the development of PROS US , experienced the following:
we
have
(1) Upon development of standard software, not only the required functions should be fullfilled, but also the design should be reviewed in terms of the response at every stage of the development. (2) Standard software should not be merely a general stereotype, but should be able to provide various menus to fit for several applications. (3) Standard software is applied to many application systems. Therefore, reliability and response will have a wide influence . Similar to mass-production of hardware, upon development of standard software, a prototype should first be made and evaluated before shipping the final product. (4) The facility to evaluate formance of a standard software implemented.
the pershould be
PROSUS has been applied more than 30 plants, such as iron and steel plants, nuclear power plants, and water supply facilities, during 2 years. Productivi ty has been improved about 20% on the average and response time has been kept as usual.