Distributed Computer Control Systems 1989

132 Pages·1990·16.05 MB·English

by  L. Motus, S. Narita

IFAC WORKSHOP SERIES
Editor-in-Chief
Pieter Eykhoff, University of Technology, NL-5600 MB Eindhoven,
The Netherlands
CHESTNUT et al.: International Conflict Resolution Using System Engineering (1990, No. 1)
SIGUERDIDJANE & BERNHARD: Control Applications of Nonlinear Programming and Optimization
(1990, No. 2)
VILLA & MURARI: Decisional Structures in Automated Manufacturing (1990, No. 3)
RODD et al: Artificial Intelligence in Real Time Control (1990, No. 4)
NARITA & MOTUS: Distributed Computer Control Systems (DCCS'89) (1990, No. 5)
KNUTH & RODD: Distributed Databases in Real Time Control (1990, No. 6)
LOTOTSKY: Evaluation of Adaptive Control Strategies in Industrial Applications (1990, No. 7)
MEYER: Real Time Programming (1990, No. 8)
MOWLE: Experience with the Management of Software Products (1990, No.9)
TAKAMATSU & O'SHIMA: Production Control in Process Industry (1990, No. 10)
RODD: Distributed Computer Control Systems (1989)
CRESPO & DE LA PUENTE: Real Time Programming (1989)
McAVOY: Model Based Process Control (1989)
RODD & SUSKI: Artificial Intelligence in Real Time Control (1989)
BOULLART et al.: Industrial Process Control Systems (1989)
SOMMER: Applied Measurements in Mineral and Metallurgical Processing (1989)
GOODWIN: Robust Adaptive Control (1989)
MILOVANOVIC & ELZER: Experience with the Management of Software Projects (1989)
GENSER et al.: Safety of Computer Control Systems (SAFECOMP'89) (1989)
Other IFAC Publications
AUTOMATICA
the journal of IFAC, the International Federation of Automatic Control
Editor-in-Chief: G. S. Axelby, 211 Coronet Drive, North Linthicum,
Maryland 21090, USA
IFAC SYMPOSIA SERIES
Editor-in-Chief: Janos Gertler, Department of Electrical Engineering,
George Mason University, Fairfax, Virginia 22030, USA
Full list of IFAC Publications appears at the end of this volume
NOTICE TO READERS
If your library is not already a standing/continuation order customer or subscriber to this series, may we recommend that you place a standing/
continuation or subscription order to receive immediately upon publication all new volumes. Should you find that these volumes no longer serve your
needs your order can be cancelled at any time without notice.
Copies of all previously published volumes are available. A fully descriptive catalogue will be gladly sent on request.
ROBERT MAXWELL
Publisher
DISTRIBUTED COMPUTER
CONTROL SYSTEMS 1989
Proceedings of the Ninth IFAC Worfohop,
Tokyo, Japan, 26-28 September 1989
Edited by
L. MOTUS
Institute of Cybernetics, Computer Division,
Tallinn, USSR
and
S. NARITA
Waseda University, Electrical Engineering Department,
Tokyo, Japan
Published for the
INTERNATIONAL FEDERATION OF AUTOMATIC CONTROL
by
PERGAMON PRESS
Member of Maxwell Macmillan Pergamon Publishing Corporation
OXFORD · NEW YORK · BEIJING · FRANKFURT
SÄO PAULO · SYDNEY · TOKYO · TORONTO
U.K. Pergamon Press pic, Headington Hill Hall, Oxford OX3 OBW, England
U.S.A. Pergamon Press, Inc., Maxwell House, Fairview Park, Elmsford, New York 10523, U.S.A.
PEOPLE'S REPUBLIC Pergamon Press, Room 4037, Qianmen Hotel, Beijing, People's Republic of China
OF CHINA
FEDERAL REPUBLIC Pergamon Press GmbH, Hammerweg 6, D-6242 Kronberg, Federal Republic of Germany
OF GERMANY
BRAZIL Pergamon Editora Ltda, Rua Eça de Queiros, 346, CEP 04011, Paraiso, Sâo Paulo, Brazil
AUSTRALIA Pergamon Press Australia Pty Ltd., P.O. Box 544, Potts Point, N.S.W. 2011, Australia
JAPAN Pergamon Press, 5th Floor, Matsuoka Central Building, 1-7-1 Nishishinjuku, Shinjuku-ku,
Tokyo 160,Japan
CANADA Pergamon Press Canada Ltd., Suite No. 271, 253 College Street, Toronto, Ontario, Canada M5T 1R5
Copyright © 1990 IFAC
All Rights Reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in
any form or by any means: electronic, electrostatic, magnetic tape, mechanical, photocopying, recording or other­
wise, without permission in writing from the copyright holders.
First edition 1990
Library of Congress Cataloging in Publication Data
Distributed computer control systems, 1989: proceedings of the ninth
IFAC workshop, Tokyo, Japan 26-28 September 1989/edited by
L. Motus and S. Narita—1st ed.
p. cm.—(IFAC workshop series: 1990, no. 5)
Papers presented at the 9th IFAC Workshop on Distributed Computer
Control Systems.
Includes indexes.
1. Automatic Control—Data processing—Congresses. 2. Electronic
data processing—Distributed processing—Congresses.
I. Narita, S. (Seinosuke), 1938- II. Motus, L. III. International Federation
of Automatic Control. IV. IFAC Workshop on Distributed Computer
Control Systems (9th: 1989: Tokyo, Japan) V. Series.
TJ212.2.D576 1990 629.8'9—dc20 90-7496
British Library Cataloguing in Publication Data
Distributed computer control systems 1989.
1. Distributed digital control systems
I. Motus, L. II. Narita, S. III. International
Federation of Automatic Control IV. Series
629.895
ISBN 0-08-037870-6
These proceedings were reproduced by means of the photo-offset process using the manuscripts supplied by the
authors of the different papers. The manuscripts have been typed using different typewriters and typefaces. The
lay-out, figures and tables of some papers did not agree completely with the standard requirements: consequently
the reproduction does not display complete uniformity. To ensure rapid publication this discrepancy could not be
changed: nor could the English be checked completely. Therefore, the readers are asked to excuse any deficiencies
of this publication which may be due to the above mentioned reasons.
The Editors
Printed in Great Britain by BPCC Wheatons Ltd, Exeter
IFAC WORKSHOP ON DISTRIBUTED COMPUTER
CONTROL SYSTEMS 1989
Sponsored by
IFAC Technical Committee on Computers
IFAC Technical Committee on Application
In cooperation with:
CSK Corporation
Fuji Electric Co., Ltd.
Fujitsu Ltd.
Hitachi Ltd.
Mitsubishi Electric Corporation
Toshiba Corporation
Waseda University
Yamatake-Honeywell Co., Ltd.
Yokogawa Electric Corporation
Workshop Organizers:
Prof. S. Narita
Mr A. Inamoto
International Programme Committee
L. Motus (Chairman) I. MacLeod
Th. Lalive d'Epinay K. D. Mueller
Guang S. Narita
J. Hetthessy M. G. Rodd
A. Inamoto Th. Stutz
Lan Jin G. J. Suski
H. Kopetz
National Advisory Members:
K. Furuta
Y. Sawaragi
FOREWORD
This book comprises a selection of papers from some thirty contributions presented at the 9th IFAC
Workshop on Distributed Computer Control Systems (DCCS), September 26-28, 1989, Tokyo, Japan.
Discussions at the Workshop and post-workshop analysis of submitted papers indicate that compar­
atively little attention has been paid to application oriented methods and tools needed for development
of outer layers of DCCS. At the same time tools and methods for inner layers of DCCS ( i.e. networks,
protocols, operating system issues) were better represented. Application papers, presenting operational
DCCS, were on a traditionally good level.
One of the highlights of this Workshop was the further infiltration of true real time or "time critical"
concept. Starting from the 1st Workshop on DCCS (Tampa, Florida, USA, 1979) the idea of time
selective communication in DCCS has been present. True real time issues gained wider attention at the
5th Workshop (Sabi-Sabi, South Africa, 1983).
At this year's event it was claimed that we need time-deterministic communication for building a good
DCCS. This statement may lead us to revisiting some already accepted standards and may cause extensive
discussions in the fieldbus committees. Indeed, issues related to time critical communication architecture
are currently the central work item of ISO/TC184/SC5/WG2 (Communications and Interconnections for
industrial processes), which has just finished the standardization of MMS Core Standards. Conventional
MAP, MMS, etc. bound problems were also discussed.
The emergence of artificial intelligence methods in DCCS applications is another outstanding feature
of this meeting. As a consequence of this, novel computer architectures (e.g. neural networks, inference
engines) are being integrated into computer control networks.
We also had talks on software engineering and distributed computing problems. Hopefully this marks
the beginning of closer cooperation between the DCCS community and the other two corresponding
communities.
The Editors hope that the reader will get inspiration from the ideas published in these proceedings.
However, we would be equally glad if the reader could find it a challenge to solve problems that have not
been handled adequately in this volume. Everybody is welcome to join coming Workshops of this series
and provide a better coverage of DCCS problems.
L.Motus
S.Narita
VII
WELCOME ADDRESS
Y. Sawaragi
The Japan Institute of Systems Research
It is a great pleasure and honor for me that, where 48 Japanese companies are joining in the
as an advisor of IFAC, I can welcome you all to collaborative research on the development of fuzzy
the 9th IFAC Workshop on Distributed Computer control systems, fuzzy information processing and
Control Systems. As you know well, the style of fuzzy computers. Third, MITI has also decided to
control technology for manufacturing and manage­ initiate the research program for intelligent man­
ment is rapidly changing due to the development ufacturing system next year, which will be carried
of computers and communication networks. out as a collaborative research by universities and
We are now facing a new stage of automated so­ industries in Japan, USA and Europe. This IMS
ciety which will be brought about by the realiza­ is the new Japanese Version of CIM in the next
tion of CIM and other related technologies. Since coming generation.
the speed of the advancement of new technologies From this point of view, it is quite fitting that
for CIM and FA is becoming so quick and rapid at we can have this Workshop on the theme "Towards
the present, I think it very valuable that this Work­ generic function for time-critical distributed oper­
shop has been held every year. Universities as well ating systems" in our country. We do sincerely
as the industries in our country have been always hope that all the participants will obtain a valu­
interested in, and have considerably contributed able experience from this meeting. Also, I would
to the development of such control technologies. like to recommend the foreign participants to en­
joy a harmonized combination of civilized living
Fortunately, I am very pleased to inform you
and old culture in Japan through technical visit,
that the remarkable research projects are now un­
scenic tour and Workshop Banquet.
dergoing in our country.
Finally, I would like to extend my sincere grat­
First, the ministry of Education, Science and
itude to Prof. Narita, Mr.Inamoto and all other
Culture of Japan adopted the research project ti­
personnels who paid tremendous efforts in the
tled the study on Distributed Autonomous Sys­
preparation for this Workshop and brought it to
tem as one of the Priority Area Research in our
its successful opening this morning.
country from next fiscal year. This is the ba­
sic research by the academic people and consists
of three items, that is, clarifying the mechanism
of distributed autonomous bio-systems, analysing
the generic functions of distributed autonomous
technical systems and establishing the theory for
distributed autonomous systems.
Second, the ministry of International Trade and
Industry (MITI) has established the Laboratory
for international Fuzzy Engineering last March,
Copyright © IFAC Distributed Computer PLENARY SPEECH
Control Systems, Tokyo, Japan 1989
A DISTRIBUTED TYPE COMPUTER-AIDED
SOFTWARE REQUIREMENTS ENGINEERING
ENVIRONMENT
Y. Matsumoto and T. Ajisaka
Department of Information Science, Kyoto University, Sakyo Kyoto 606, Japan
ABSTRACT
KyotoDB-I is a computer-aided environment to support software requirements engineer­
ing. It consists of user interface, a set of tools and object environment which manages, interprets
and stores a set of objects each of which represents (1) model/view of one individual software
configuration item, (2) plan (process program) to elaborate this software configuration item and
(3) relations between data in one model/view and data in other model/view.
The user interface includes the function called collaborator which supports collaboration.
A collaboration is defined as an activity of KyotoDB-I to organize a common session in many
workstations, and enables project members to talk one another through individual workstations
and to result consistent software configuration items with using the set of objects stated above.
Keywords: Distributive data processing; distributed databases; object-oriented programming;
software engineering environments; computer-aided engineering environments.
1 Introduction (2) To capsulate the relations between data included in the
different artifact objects. These data are assigned to
The objective of this research project is to develop the instance variables of each specific relation object.
a computer-aided software requirements engineering envi­ Relation objects are shared by the relevant artifact ob­
ronment called KyotoDB-I. While KyotoDB (Kyoto Uni­ jects.
versity Software Engineering Database) is the name of the
(3) To enable project members to trace up and down
project to develop a computer-aided environment which aims
through different software artifacts using relation ob­
to support software engineering activities in wide range,
jects.
KyotoDB-I is the name of the environment which supports
software processes and products only for the stage of require­
(4) To enable collaboration between many participating
ments engineering.
members who are responsible of different software arti­
facts. These collaboration will be made using relation
KyotoDB-I runs on a distributive system which con­ objects, which are shared by the relevant artifact ob­
sists of a host computer, local area network and many work­ jects.
stations. The software of KyotoDB-I consists of user in­
terface, object environment and a set of tools. The object (5) To capsulate plan (process program) into each artifact
environment supports users to describe a connected set of object. (The capsulated plan is the process program
objects, which will be called object model, interprets the de­ which will be followed by the member responsible of
scribed object model and to manage persistent objects. the artifact represented by the said articaft object.)
Each object included in the object model is used for
one of the following purposes. The architecture of KyotoDB-I is presented in Sec­
tion 2. The object environment we use is the experimental
(1) To capsulate important data, which are included in system called COB, which has been developed by IBM Japan
each software artifact or configuration item produced [Kamimura89]. It provides with language COB, which we use
in requirements engineering. (These data are assigned for describing object models.
to the instance variables of the object which represents The object model which we developed for KyotoDB-
this artifact.) I has a structure that the instance variables of n-th layer
object includes (n — l)-th layer objects. Each object layer
1
2 Y. Matsumoto and T. Ajisaka
has one-to-one correspondence with the layer of the process
program, namely the structure of the engineering process
discussed in Section 3. user interface object environment
object description
Several earlier researches on software engineering envi­
ronments are providing process programming support. Sys­
tems which support process programming for creating spec­
ification and design, based on methodology specific to each
system, are PAISLey [Zave86], RSL/REVS [Bjorner87],
SARA [Estrin86], Data Flow Diagram Designs [Ward86] and
USE [Wasserman86]. Other systems such as Interlisp [Teit-
elman81], Cornell Synthesizer [Teitelbaum81], Gandalf [Ha-
bermann86] and Mentor [Donzeau-Gouge84] are the envi­
ronments to support process programming in programming.
However most of these systems do not support distribution.
Arcadia [Taylor88] is a research project to develop an
environments to support no fixed predetermined process and
product.
KyotoDB-I takes an approach similar to Archadia in Figure 1: Basic Architecture of KyotoDB
the aspect that process programming aims general process.
However what characterizes our research is that we classify workstation. The host computer H may be shared by any
process program in multi-layer model, and capsulate each project member and by other projects.
layered process program into objects of the corresponding The basic software configuration of KyotoDB-I is
layer in the way shown in Section 3. Moreover, the arti­ shown in Figure 1. The box in the upper right is the en­
fact objects in KyotoDB-I can be allocated distributively. vironment (we use COB) which supports users for creating
In order to ease cooperations of the participating members object model, interprets objects and manages persistent ob­
through workstations, KyotoDB-I provides with the facil­ jects. The object description is produced by project members
ity called collaborator. By the collaboration, the cosistencies through user interface shown in the upper left. We use the
between artifact objects located in different workstations are experimental user interface called CANAE which has been
maintained. The collaboration is discussed in Section 4. The developed by NEC Corporation [Rekimoto89]. The software
concluding remarks are given in Section 5. of CANAE itself is a client process of X- Window Version
11 Release 2. It provide with toolkits and the environment
to develop dialogs with using a language called script pro­
gramming language. Some of the tools such as text editor,
2 KyotoDB-I
table editor, graph editors are included in CANAE. However
most of the tools which are used for system integration (e.g.
KyotoDB-I includes clustering tool, decision support systems, are included in the
boxes shown in the lower end of the figure.
(1) the environment which provides users with describing
object models, interprets described model, and man­ The objects in box "object description" are produced
ages persistent objects, project by project. Each object is described based on the
scheme of standard class shown in Figure 2. A standard
(2) user interface and class includes four instance variables, that are model, view,
plan and relation. The standard class has many methods to
(3) a set of tools.
use these instance variables. Each of these variables, namely
The architecture of KyotoDB-I is presented in 2.1. In­ model, view, plan and relation is an object. The purpose of
ternally, the description of an object is divided into two each class is described in the following.
parts: declaration part and implementation part. The in­
ternal sturcture of object class is descussed in 2.2.
• Object standard class, if it is instantiated to A, rep­
resents product A, where product means a software
2.1 Architecture
configuration item, an artifact, or a description to be
elaborated as a product.
KyotoDB-I runs on a distributed system which con­
sists of workstations Wu W2,..., Wp, a local area network • Object model, if it is instantiated to A, represents data
and a host computer H. UNIX™ (UNIX is a registered model of product A. If product A is a text-like speci­
trademark of AT&T Bell Laboratories) is used in all com­ fication written in a natural-like language, the text is
puters. We assume that the workstations W\, W2,..., Wp converted to a set of formatized records of data, as is
are used for one particular project which p project members discussed in 2.2, and these formatized records are in­
participate, and each project member uses one individual stance variables in instance A of model.
Software Requirements Engineering Environment 3
The implementation parts of these objects, not shown
standard class in Figure 3, describe the codes to implement each method.
The declarations of only three example methods are included
model
in stdobj. Method mtov transforms the model data, which
are described in the instance variables of class model, the
relation
tree-view data which are described in the instance variables
view of class tree_view. The next method vtom tansforms the
tree-view data to the model data. These two methods are
used when we reuse existing model data or view data, which
have been made in the past time.
plan
Various other methods, such as insert, modify, and
delete are also declared in stdobj. These methods, when
they are invoked, will use insert, modify and delete of
class model and class tree_view. If, for example, you want
Figure 2: Basic Object Structure to insert or delete an elementary data included in the in­
stance variables of class model, your "user interface" will
first call insert or delete of class stdobj. Then the called
• Object view, if it is instantiated to A, represents view
method will invoke insert or delete of both class model
data of product A. If you need to see a tree-like dia­
and class tree.view. This is the way we do to keep con­
grammatic view of the product A, you should prepare
sistencies between model data and view data. The idea of
class tree-view which has data for showing tree-like
keeping consistency between model data and view data in
view as its instance variables. A of standard class has
this way is already known by the paper [Myers83].
methods which keeps consistencies between instance
We extend this idea. Most of elementary data in­
variables of model and view for both instance A. Ob­
cluded in the instance variables of a model-instance may have
ject plan, if it is instantiated to A, represents a pro­
some dependencies to some instance variables of other model-
cess program for elaborating product A. This will be
instances. In such cases, we must first establish consisten­
discussed in Section 3. Object relation, if it is instan­
cies between coupled instance variables in different model-
tiated to A, maintains the relationships between each
instances before we rewrite these instance variables. Ky-
elementary data included in the instance variables of
otoDB-I tries to cope with this problem in the following
instance A of model. Object relation, if it is instanti­
manner.
ated to A-X, maintains the relationships between each
elementary data included in the instance variables of (1) A member now wants to change some data included in
instance A of model and elementary data included in instance K of class model. K represents the artifact
the instance variables of instance X of model. This re­ of which the member is resposible. The member will
lation exists in host computer H, and it is accessed by enter the change-request while looking at some view on
all instances using virtual pointers. the screen. This view image comes from the instance
variables of instance K of class view.
2.2 Object
(2) One of the methods in stdobj is invoked by "user in­
terface". The invoked method will change only view
In this section, details of the basic object structure data by invoking corresponding methods in instance
shown in Figure 2 are explained. The object named standard K of class view.
class in Figure 2 is programmed using language COB. A pro­
gram named class stdobj shown in Figure 3 corresponds to (3) The method in stdobj invoked by "user interface"
it. This class may be instantiated to all real project instances also makes access to some instance of class relation
shown in Figure 5. We will discuss Figure 5 in Section 3. which maintains dependencies between the data to be
changed and the data related to it which exists in other
Only major program lines of class stdobj are shown
objects.
in Figure 3. The class denotation consists of two parts: dec­
laration part and implementation part. Shown in Figure 3 (4) If there should be any data related to the data which is
are only declaration parts. Included in the figure are the dec­ to be changed, then the instance variables of instance
larations of class stdobj, class model and class tree_view. A of class model is not changed at this time. The
Other classes, which are plan and relation, are not shown in method in stdobj leads the member to go into the
the figure. session called "collaboration".
As shown in the declaration of instance variables for
Through this session, the members responsible for the
stdobj, these four classes are the instance variables of class
change talks with other members who are responsible
stdobj. Only tree.view is used in this example. If you need
of the data related to this change through the common
other view, such as text-like view, class text_view should be
window called "collaboration window" shown on the
added.
members'individual workstation.
Y. Matsumoto and T. Ajisaka
/* class definition of standard object */
000 class decl stdobj {
001 instvar:
/* standard object has 4 classes, see figure 2 */
002 class model *modelp;
003 class view *viewp;
004 class plan *planp;
005 class relation *relationp;
006 instmethod:
007 int mtov(class model *modelp, class view *viewp);
/* transform model to view */
008 int vtom(class view *viewp, class model *modelp):
/* transform view to model */
009 int insert_view(class view *viewp, int p);
/* calls insert of view class */
010 void move_view(class view *viewp, int p);
/* calls move of view class */
011 /* other methods to invoke every method in model and
tree_view come here */
012 >
/* class definition of Model Object */
100 class decl model {
101 instvar:
/* model of software configuration item described
in case-grammar, see figure 7 and 9 */
102 struct CASE {
103 char id[IDSIZ]; /* S0000, dOOOO, ... */
104 char subj ect[STRMAX];
105 char verb[STRMAX];
106 struct {
107 char caselabel[STRMAX];
108 int tag; /* indicates if caseterm is
char * in fact or not */
109 struct CASE *caseterm;
/* if no other case expression is nested,
it should be casted for char * */
110 } terms[TERMMAX];
111 } *sci /* root pointer of item */
112 int saved; /* flag indicating if saved to file */
113 instmethod
114 void init(struct CASE *sci); /* initialize instance */
115 int destroy(int forced); /* destroy instance */
116 int insert(char *id, struct CASE *sci;;
/* insert a part of this model */
117 int modify(char *id, struct CASE *sci);
/* like as above */
118 int delete(char *id) ; /* like as above */
119 int write_data(char *scheme, char *attribute);
/* write on database */
120 int read_data(FILE *infd); /* get from database */
121 int find_influence(char *id, FILE *inf_file) deferred;
/* find influence to other model */
122 int get_part(char *id, struct CASE *sci);
/* get a part of of this Model Object */
123 classmethod
124 class model *create(struct CASE *sci); /* create instance */
125 };
/* class definition of tree structured view */
200 class decl tree_view
201 superclass view
202 {
203 instvar
204 int next; /* node id to be inserted next */
205 struct tree {
206 node desc;
207 struct tree *children[DEGMAX];
208 } *document;
/* root pointer to tree structured document */
209 instmethod
210 /* init and destroy come here */
211 int insert(struct tree *document);
212 /* modify, ..., get.part customized for tree come here */
213 struct tree *lookup(int p_num, struct tree *p_from);
/* find subtree */
214 void move(strct tree *treep); /* move view */
215 /* */
216 classmethod
217 class tree_view *create(char *viewname);
218 };
Figure 3: Class Definitions