- Email: [email protected]
Open environments and object-oriented methods for computer-aided control system design
ControtEng.Practice,Vol. 3, No. 3, pp. 347-356, 1995 Copyright © 1995 Elsevi~ Science Ltd lhinted in Great Britain. All rights reserved 0967-0051/95 $9.50 + 0.00
Pergamon 0967-0661(95)00006-2
OPEN ENVIRONMENTS AND OBJECT-ORIENTED METHODS FOR COMPUTER-AIDED CONTROL SYSTEM DESIGN H.A. Barker Deparanent of Electrical and Electronic Engineering,
University of Wales Swansea, Swansea, UK
(Received December 1993; in final form October 1994)
Abstract: Two current trends in the computer industry are towards open systems and objectoriented methods. Both are important for computer-aided control system design. The success of computer-aided software engineering is attributed to its open environment, based on a reference model that involves a service-oriented framework serving a set of tools. An adaptation of this reference model is proposed for computer-aided engineering in general and computer-aided control engineering in particular. Object-oriented methods are described, and their roles in the framework services are considered. Their particular importance for the modelling services of a computer-aided control engineering environment is established. It is concluded that a combination of open environments and object-oriented methods provides a unique opportunity for progress in computer-aided control system design that needs to be grasped if the world-wide control community is to benefit. Keywords: Software Environments; Open Systems; Reference Models; Object-Oriented Methods; Object Modelling; Data Types.
Complexity is also introduced by the requirements for quality and safety, which now require the design process to be proceduralised and documented to a hitherto unprecedented extent. Add the increasingly competitive nature of engineering world-wide and Gilbert might well have written:
1. INTRODUCTION The development of the computer has presented the control system engineer with both opportunities and challenges. Opportunities are provided by the ready availability of low-cost, high-speed, reliable hardware. To exploit them, the designer must either use or develop the software that utilises the power of the hardware. For one-off designs of small-scale control systems this is not likely to be a problem. The powerful software packages that are now available for analysis and simulation, MATLAB and SIMULINK for example, are normally sufficient for these cases. For more serious work, however, the designer is likely to encounter the challenges of complexity, quality, safety and competition.
"A designer's lot is not a happy one." Complexity need not, of course, be a problem provided that the designer is able to address it in a coherent fashion. In computer-aided control system design (CACSD), a completely coherent approach is unfortunately not yet available. Few of the software packages that a designer might wish to deploy in the various stages of the design process are compatible with each other, and attempts (Munro, 1988; Taylor et al., 1989) to integrate them into a coherent software environment for CACSD have not been particularly successful. Although the need for CACSD environments has long been recognised (McFarlane et al., 1989), the only successful example so far reported is ANDECS (Grtibel et al., 1993), and that was not developed by integrating proprietary CACSD software packages.
Much of the complexity of computer-aided design is self-inflicted. The power of the modem computer encourages the designer to be yet more ambitious at every stage of the design process. To paraphrase Browning: "A designer's reach should exceed his grasp, or what's a computer for?" 347
348
H.A. Barker
Fortunately, developments in software engineering, and particularly in computer-aided software engineering (CASE), give a clear indication of the direction in which CACSD environments should evolve to provide solutions for the problems of complexity. From CASE the open environment and from software engineering the object-oriented paradigm together provide the basis of a way forward in CACSD.
2. E N V I R O N M E N T S
The foundation of all forms of computer-aided engineering is the environment, which contains the software to support the engineering of a product or process throughout the whole of its life cycle, from conception and specification, through design and development, to implementation and operation. Among the environments for different forms of computer-aided engineering, CASE environments currently receive the greatest amount of investment and are the most technically advanced. These environments therefore provide an indication of the way in which CACSD environments should develop.
Interface for CASE environments. To support this, the Association has adopted a reference model (Earl, 1990; ECMA, 1990b) for CASE environments, and this has also been adopted by the American National Institute for Standards and Technology (NIST, 1991). The CASE environments reference model is shown in the "toaster" diagram in Fig. 1. Its principal feature is the division of the environment into a toolset, which provides the specialised facilities required by a particular user, and a framework, which provides the common facilities required by the whole environment. The common facilities are sub-divided into five groups of services, so that as standards are developed they cover the whole group.
2.1 CASE Environments Despite its fiercely competitive nature, the computer industry has long adhered to the open system concept. Indeed, it could be argued that spectacular growth of the industry would not have been possible without it. Kuhn (1991) has described the concept as "an interface specification to which any vendor can build hardware and software products", but the term was first used in "Basic Reference Model for Open Systems Interconnection" (ISO, 1984), which as ISO 7498 defined a set of international standards for the interconnection and interworking of different computer systems. In this context, a reference model provides a framework for debate and a focus for discussion between experts in the field, leading to the development of the standards on which the open system is based (Gibbons, 1991). It is therefore not surprising that, for CASE environments, the industry specified an open system defined by a reference model. It was once believed that a CASE environment could be formed by a co-operating set of tools with appropriate interfaces, but it is now accepted that it is necessary to provide the tools with a set of common facilities, or services, known as a Public Tool Interface (Gibbons, 1991). This takes the form of a service-oriented framework that, when populated with an appropriate set of tools, constitutes an environment. The European Computer Manufacturers' Association has adopted the Portable Common Tool Environment (Thomas, 1989; ECMA, 1990a) as the standard Public Tool
Fig. 1. CASE environments reference model. The service groups are:
User-interface services, which provide a consistent graphical user interface for the whole environment. Task management services, which create a taskoriented environment by inserting a layer of abstraction between the user and the fine detail of the facilities in the environment. Data repository services, which provide a store for all data objects in the environment. Data integration services, which enhance the services of the data repository by inserting a layer of abstraction to provide high-level semantics and operations with which to handle the stored data. Message services, which provide managed communication between all the facilities in the environment.
Computer-Aided Control System Design 2.2 Open Environments Reference Model
The CASE environments reference model is an archetype for open environments in other fields of computer-aided engineering. In the framework, the user-interface services group, the data repository services group and the message services group are independent of the field. Only the task management services group and the data integration services group, both of which introduce a layer of abstraction, contain field-dependent services. Those data integration services that are not field-dependent are best combined with the data repository services to form a field-independent group of database services that comprise a database with comprehensive management facilities. The remaining data integration services form a field-dependent group of modelling services, conveniently termed modelling services as in most fields they are concerned with modelling the physical world. The open environments reference model thus defined (Barker et al., 1993a) is shown in Fig. 2.
349
(Goldberg and Robson, 1983; 1985). The methods are particularly useful in software engineering for relating the real world to the artificial world of computer software, and although their usefulness tends to be obscured by jargon, they may in fact be readily applied elsewhere. The basic ideas will be recognised by control engineers as relating to a form of modelling that provides a logical basis for the process of abstraction by which models of complex entities are developed. They are explained here in terms of an object model that defines the structure and attributes of objects and relationships between them. An object model may be constructed by several different methods, but the graphical object modelling technique (Rumbaugh et al., 1991) for which supporting software is available (Select, 1994) is used here.
3.1 Objects a n d Classes The definition of an object is very broad, and may be taken as any concept, abstraction or thing with crisp boundaries and meaning for the problem in hand (Rumbaugh et al., 1991). When an object is a single entity, it is an object instance, or simply an instance, and a group of objects is an object class, or simply a class. In graphical object modelling, object diagrams are used to define objects and classes and the relationships between them. The basis of these diagrams is the class symbol, a rectangular box containing the class name and, optionally, the attributes of the class and the operations appropriate to the objects in it, as shown in Fig. 3. Instances of a class are shown in rounded boxes containing the values of the attributes.
Fig. 2. Open environments reference model. A striking feature of the environments defined by this reference model is the extent to which objectoriented methods may be applied throughout them (Barker et al., 1992). Before considering the features of CACSD environments, it is therefore useful to look briefly at these methods.
3. OBJECT-ORIENTED METHODS
Object-oriented programming is the current vogue in software engineering (Barker et al., 1993b), where its impact is likely to be as great as that of structured programming two decades ago (Rentsch, 1982). In that context, object-oriented methods are not new, but can be traced back three decades to the development of Sketchpad (Sutherland, 1963) and SIMULA (Dahl and Nygaard, 1966), although most of the modern ideas are derived from Smalltalk
Resistor name
supplier
cost resistance power rating
(Resistor) R2 Radiosparas 0.25 100000 1
(Resistor) R36 Famell 1.00 3.3 10
Fig. 3. Class and instances. A relationship between two classes is known as an association, which in an object diagram is denoted by a line between the class symbols, as shown in Fig. 4. An unterminated line indicates that there is a one-to-one relationship between instances of the associated classes. Termination with a circle at a class symbol denotes multiplicity; a solid circle indicates that zero or more instances of the class relate to a single instance of the associated class, while a hollow circle indicates that zero or one instances of the class relate to a single instance of the associated class.
350
H.A. Barker
Two forms of association are particularly important. One is aggregation, which is denoted by a line terminated with a diamond. The other is generalisation, which is denoted by a line terminated with a triangle. Aggregation is a relationship between a class and its components, in which instances of the class include instances of the associated class as component parts. It defines the way in which a system is divided into subsystems, and satisfies the test that one instance "is a part of" another. A simple example is shown in Fig. 4. Aggregation may be repeated to give an aggregation hierarchy with many levels.
I Circuit
]
[ Board I ITransistor I Resistor I[Capacit°r I Fig. 4. Aggregation with multiplicity Generalisation is a relationship between a class and its refinements.. The class that is refined is the superclass, or ancestor, and the refinements are the subclasses, or descendants. Those attributes that are common to all descendants are defined to be the attributes of the ancestor that are inherited by the descendants. The test to be satisfied in this case is that one instance "is a kind of" another. A simple example is shown in Fig. 5. Generalisation may be repeated to give an inheritance hierarchy with many levels. Component name supplier cost
2
L
Resistor resistance power rating
-
(Res~a~or)
(Inductor)
R2 Radiospares
L3 Farnell 1.50 0.01 0.0005 1500
0.25 1OOOOO I
• • •
Inductor inductance wire diameter turns
Encapsulation
The definition of an object requires that it has 'crisp boundaries', within which the object can be encapsulated so that its external features, which are accessible to other objects, are separated from its internal features, which are hidden from them. In object-oriented programming, this is known as information or data hiding. The separation of an object from other objects in its environment has two important consequences. One is that the implementation of the object can be changed without affecting other objects. The other is that the object can respond only to a message from another object containing appropriate instructions and data. The invoked response is known as a controller method if the state of the object is changed, or an observer method if the state of the object is simply returned. There is an obvious control engineering analogy.
4. CACSD E N V I R O N M E N T S The open environments reference model in Fig. 2 may now be developed for CACSD environments, and the role of the object-oriented methods in the framework services and tools examined.
4.1 Field.Independent Framework Services The field-independent services conform completely to corresponding services in the CASE environments reference model and are therefore relatively easy to define. A common feature is that each of the service groups has a layered reference model, in which each layer provides services to the layers above by adding functionality to the layers below. The levels of abstraction increase from the lowest layer of physical services to the highest layer of application services. Standards for the services in each layer are normally developed from the bottom up, until a set of standards is obtained for the whole service group as the basis for an open system.
Cllplcllolr capacitance voltage rating
1
(C-pa~or)
Fig. 5. Generalisation with instances.
3.2
cg Bulgin 1.5 0.0001 45
User-Interface Services. The reference model for user-interface services is the seven-layer Open Software Foundation model (OSF, 1989a) shown in Fig. 6. Although complete standardisation has not been achieved throughout this model, the use of a de facto standard such as Windows (Microsoft, 1990) or the X Window System (Scheifler and Gettys, 1986) allows portability across a wide range of computing platforms, while consistency of 'look and feel' is obtained by the use of OPEN LOOK (OPEN LOOK, 1989)or Motif (OSF, 1989b).
Computer-AidedConl~olSystemDesign
Layer 7 Application Services Layer 6 Dialogue Services Layer 5 Presentation Services Layer 4 Toolkit Services Layer 3 Toolkit Intrinsics Services Layer 2 Base Window System Services Layer 1 Data Stream Encodin~ Services Fig. 6. User interface services reference model. As their origins in the man-machine communication system Sketchpad (Sutherland, 1963) might suggest, object-oriented methods are extremely important for user-interface services. Control systems are often complex and cannot be comprehended without recourse to graphics. Interaction models, such as the model-view-controller (Kranser and Pope, 1988) found in Smalltalk (Goldberg and Robson, 1985) are paradigms in which graphics provides the view of a physical world model for which the state is changed by the controller. The concept of association is invaluable for decomposing large physical systems into notional structures that are accurately reflected in the actual structures of their graphical representations, leading naturally to the provision of views through multiple windows. Many object-oriented programming languages are used to support user-interfaces (Schmucker, 1986). Two particularly useful C++ (Stroustrup, 1986) class libraries that have been developed to support the synthesis of object-oriented user-interfaces in the X Window System (Scheifler and Gettys, 1986) are Interviews (Linton et al., 1989) and ET++ (Weinand et al., 1988). The underlying concepts are completely generic and not limited to these particular implementations. Services. The reference model for database services is the four-layer American National Standards Institute model for 'A Tool Integration Service' (ANSI, 1990), shown in Fig. 7. To maintain and manage all the information concerned with every application in the environment requires a set of services more comprehensive than that provided by most conventional databases. The diverse nature and complex structure of engineering
Database
351
data are better handled by an object-oriented database than by a relational database or a flat file system (Kent, 1979; Dittrich, 1992). With objects, rather than relations, used as the basis for data storage, the data maintain correspondences with the entities they represent, and can be handled in ways that are similar to those in which the entities are handled in the real world. If the stored properties of an object include executable operations, then the associated computation can take place within the database, rather than in the application program, and the user need not be aware that a value is retrieved by computation rather than look-up (Horowitz, 1991).
Layer 4 Work Flow Services Layer 3 Version Services Layer 2 Confisuration Services Layer 1 Object Services Fig. 7. Database services reference model. Object-oriented databases have been used successfully to support software engineering (Dittrich, 1988; Brown, 1991), and the database RSYST (Grubel and Joos, 1992) that supports the CACSD environment ANDECS (Grubel et aL, 1993) has object-oriented features and services so appropriate for engineering that it is referred to as "an engineering operating system". Commercial object-oriented databases include 0 2 (Deux, 1990), Gemstone (Bretl et al., 1989) and ONTOS (ONTOS, 1991). Message Services. The reference model for message
services is the seven-layer Open Systems Interconnection model (ISO, 1984) shown in Fig. 8. This is a fully standardised model in common use, which if necessary allows the environment to be distributed across a network of computing platforms. The services involve much more than simple message delivery, and for the higher layers of the reference model there is interest in the common object-request-broker (OMG, 1991), developed by the Object Management Group (Soley, 1990), and its associated Interface Definition Language. This is a message service for an object-oriented environment that allows objects to make requests and receive responses, enabling the framework services and tools to exchange not only data but also methods for manipulating them.
352
H.A. Barker
Layer 7 Application Services Layer 6 Presentation Services Layer 5 Session Services Layer 4 Transport Services Layer 3 Network Services Layer 2 Data Link Services Layer 1 Ph),sical Services Fig. 8. Message services reference model.
4.2 Field.Dependent Framework Services
The field-dependent services in CACSD environments are not as well developed as the corresponding services in CASE environments. Neither of the two groups of services involved has an agreed reference model, and this is a great impediment to the development of appropriate standards.
Task Management Services.
The function of the task management services is to create a task-oriented environment in which the user is insulated from the fine detail of the framework services and tools. This is accomplished by services to support the definition of tasks, to control the execution of tasks, and to record the history of tasks. For CASE environments, it is recognised that this group of services is the least well defined, because the subject of task management is still in its infancy and the understanding of the services involved is low (Earl, 1990; ECMA, 1990b). Although a reference model has yet to be defined for this service group, experience with other service groups suggests that it is likely to be a layered reference model. For CACSD environments, most progress will probably be made through procedural task management, in which a task is described by means of a command language, rather than declarative task management, in which only the goals of a task are specified. A standard for a command language has already been developed (Rimvall, 1989) based on IMPACT (Rimvall and Cellier, 1985), and it has been shown by Pang (1992) that knowledge-based methods may be combined with such a language for task management. Although knowledge-based methods will be useful for the automation of routine tasks in both kinds of task management, object-oriented extensions of these
methods are likely to provide additional advantages. The concept of association is directly applicable to the fundamental problem in this group of services, that of dividing tasks into sub-tasks, and both aggregation and generalisation will be involved.
Modelling Services. The function of the modelling services is to provide common facilities for handling the complex processes by which the real world, and understanding of it, is converted into a model appropriate for the purpose in hand. These services are obviously field-dependent, with the kind of model used reflecting the engineering field involved. The model type may be a unifying factor, as in the case of the finite-element models that are found in many engineering fields, but this is not, unfortunately, the case in control engineering, where several different types of model continue to be used to describe a single object. Agreement on a reference model for this group of services would be a useful step towards the unification that is necessary if open CACSD environments are to be achieved. A candidate reference model that may be evolved from practices in the successful ANDECS environment (Grubel et al., 1993) is the layered reference model shown in Fig. 9. Layer 4 High Level Model Services Layer 3 Neutral Model Services Layer 2 Control Data Object Services Layer 1 Data Exchange Services Fig. 9. Modelling services reference model. The service groups in this model are:
Data Exchange Services, which provide for the exchange of data in standard format with other environments, not necessarily for CACSD. The STEP neutral data exchange format and the EXPRESS data definition language are standards that could be adopted for this service group (Maciejowski, 1992).
Control Data Object Services, which provide a comprehensive set of data objects found in control engineering. These include not only system objects, such as transfer function and state space models, but also signal objects such as time and frequency responses. Such a set of objects was first proposed as a core data model by Maciejowski (1984, 1988). A more recent proposal by Joos and Otter (1992) is based on the object-oriented concept of generalisation.
Computer-Aided Control System Design
Neutral Model Services, which provide a standard set of descriptions for the fundamental dynamic systems that are the basis of all models. These might include, for example, a description of a set of differential-algebraic equations in an object-oriented language. In the ANDECS environment (Grubel et al., 1993) these dynamic system-, or DS-blocks are realised as FORTRAN or C subroutines (Otter, 1992). High-Level Model Services, which provide descriptions of complex systems in high-level modelling languages.-Traditionally, modelling has been simulation-oriented, with continuous systems simulation languages such as ACSL (ACSL, 1986) predominant. In future, modelling will be objectoriented and supported by languages such as DYMOLA (Elmqvist, 1978) and Omola (Mattson and Andersson, 1992). Object-oriented modelling of dynamic systems is essentially a bottom-up process, in which the fundamental dynamic behaviour of the system is encapsulated at the lowest level in elemental objects, described by Cellier (1991) as atomic objects. The encapsulated behaviour of an atomic object is described by an atomic model, which represents constraints on the variables involved and can take any appropriate form, such as a mathematical model in the form of equations, or a computer model in the form of code. Interaction between the atomic object and others occurs through variables at ports in its boundaries. In an electrical system, for example, the atomic objects are resistors, capacitors and inductors, the last two conferring dynamic behaviour on the system. Each atomic object is encapsulated in a boundary with two ports, one for the current through the object and the other for the voltage difference across it, and each atomic model implements the physical law that relates the voltage and the current. Fig. 10 illustrates the encapsulation of a capacitor, with an atomic model in the form of a pair of equations.
i
Y v= i=C
idt dv
• ..
dt
Above the atomic level, aggregation and inheritance hierarchies of more complex objects are developed, and to represent these graphically, the object diagrams described in Section 3 are invaluable. In an aggregation hierarchy, objects above the atomic level are described by Cellier (1991) as molecular objects. Each molecular object is composed of lower-level molecular or atomic objects. The behaviour of a molecular object is encapsulated in a molecular model that consists of descriptions of its lower-level objects and the interactions between them. For a given set of objects, only one aggregation hierarchy can normally be developed. An example of an aggregation hierarchy for a motorgenerator molecular object is shown in Fig. 11. Here the interactions between the lower-level molecular objects are constrained by the electro-mechanical coupling equations. The interactions between the atomic objects in the electrical system molecular object are constrained by Kirchoffs current and voltage laws while those between the atomic objects in the mechanical system molecular object are constrained by Newton's laws and geometry. The molecular model is valid irrespective of whether the object acts as a motor or a generator. Once the model is developed and proved, instances can represent any motor or generator of the class, so that model reusability is achieved.
Motor-Generator]
, Re~stoHrC~or 11Ind~ctoI r
~-1[ Sl:!ng11Mm
I
Fig. 11. An aggregation modelling hierarchy. In an inheritance hierarchy, the objects above the atomic level are in classes with common physical laws, and the descendants inherit the physical laws of the ancestors. For a given set of objects, more than one inheritance hierarchy can often be developed. Examples of two inheritance hierarchies for the atomic objects in Fig. 11 are shown in Fig. 12. One is a component hierarchy that is an extension of the simple inheritance hierarchy in Fig. 4. The other is an energetic system hierarchy in which all objects inherit the energy conservation law of the superclass, but only those atomic objects in a subclass inherit the law appropriate to that class.
: .:
•....
353
...."
Fig. 10. An encapsulated atomic object.
Object-oriented modelling languages are expected to support these methods of modelling, and to provide facilities for the development of class libraries. Acceptance of these will allow objects in CACSD environments to be treated as off-the-shelf items that can be taken down and slotted into new applications.
354
H.A. Barker 5. CONCLUSIONS
~
L
EM.~r~mechan,c~ al , ooo-.. ,
I ] CIq dtor It ,ndu=or I [ ReCtor I
I D" mLper II Sp"ng I
I
I
Energy r
Energy i
= Y=C J~dt I i
_]
:
Inductor [I Spring
Fig. 12. Inheritance modelling hierarchies.
4.3 Tools Tools are the most important part of an environment, because the framework and its services exist only to support them. A user must be able to select a toolset appropriate to an application and simply slot it into the framework. As the tools use the services that the framework provides, this obviates the need for toolmakers to add extensive features to tools just to provide these services, and allows them to concentrate on improving their tool's performance. The natural division of labour between framemakers and toolmakers is efficient, but it can only occur in open environments. Modern CACSD requires a diversity of tools, for example for identification, simulation and analysis by both numerical and symbolic methods (Barker et al., 1993c). To ensure that tools produced independently will function harmoniously in a toolset, they are best produced within a set of guidelines (PACT, 1988). In a mature open environment, the most successful tools are likely to be those produced by toolmakers who know how to take full advantage of the services that a framework provides. In the interim, tools not produced with framework services in mind might be encapsulated in appropriate software to allow them to be slotted into the framework. A new generation of object-oriented CACSD tools, for example Xmath (Floyd et al., 1991), is emerging for which this approach is quite feasible.
Progress in any field largely depends on the establishment of a basis on which to proceed. In CACSD, the lack of such a basis has inhibited the development of open environments, to the detriment of the control community. It is shown here that to rectify this situation it is necessary to adopt a reference model that will facilitate the development of appropriate standards on which open environments can be based. A variation of the successful reference model for CASE environments, in which each environment is divided into a servicebased framework and a toolset, has been proposed for this purpose. Most of the groups of framework services in this reference model are independent of the field of application, and therefore suitable for adoption with little alteration. Only the task management and modelling services are fielddependent, and for these the particular requirements of CACSD have been described. For modelling services, a novel reference model has been proposed. The fundamentals of object-oriented methods have been described and illustrated by means of object models. The relevance and impact of these methods in all parts of the CACSD environment have been demonstrated, and it has been shown that the concepts of generalisation, aggregation and encapsulation are particularly important for modelling. The potential of these methods in CACSD is considerable and has not yet been fully realised. Together with open environments, they provide an opportunity for progress in CACSD that needs to be grasped if the world-wide control community is to benefit.
REFERENCES
ACSL (1986). ACSL reference manual. Mitchell and Gauthier Associates, Concord, U.S.A. ANSI (1990). Working draft in formation resource dictionary system ATIS. Tech. Rep. ANSI X3H4/90-187, American National Standards Institute. Barker, H.A., M. Chen, P.W. Grant, C.P. Jobling and P. Townsend (1992). Object-oriented methods in computer-aided control engineering environments: a symbiosis for the future. In Proc. 2nd Int. Conf. on Automation, Robotics and Computer Vision, Singapore, pp. 10.1.110.1.5. Barker, H.A., M. Chen, P.W. Grant, C.P. Jobling and P. Townsend (1993a). A reference model for computer-aided control engineering. In Proc. 12th IFAC Worm Congress, Sydney, Australia, 6, pp. 437-441.
Computer-Aided Control System Design
355
Barker, H.A., P.W. Grant, C.P. Jobling and P. Townsend (1993b). The object-oriented paradigm: a means for revolutionising software development, lEE Computing and Control Engineering Journal, 4, pp. 10-14.
Floyd, M.A., P.J. Dawes and Xmath: a new generation CACSD tools. In Proc. Conf., Grenoble, France, pp.
Barker, H.A., I.T. Harvey and P. Townsend (1993c). Symbolic mathematics in control system analysis and design. Trans. lnst MC, 15, pp. 59-68.
Gibbons, M. (1991). A framework for standardisation and support environments technology. In Software Engineering Environments, F. Long, Ed., Ellis Horwood, Ch.3, pp. 155-167.
Bretl, R., D. Maier, A. Otis, J. Penney, B. Schuchardt, J. Stein, E.H. Williams and M. Williams (1989). The GemStone data management system. In Object-Oriented Concepts, Databases and Applications, ACM Press, ch. 12, pp. 283-308. Brown, A. (1991). Object-oriented databases: applications in software engineering. International Series in Software Engineering, McGraw-Hill, New York. Cellier, F.E. (1991). Continuous system modelling, Springer-Verlag, Berlin. Dahl, O.J. and K. Nygaard (1966). SIMULA - an Algol-based simulation language. Communications of the A CM, 9, pp. 671-678. Deux, O. (1990). The story of 0 2. IEEE Trans. Knowledge and Data Eng., 2, pp. 91-108.
U. Milletti (1991). of object-oriented European Control 2232-2237.
Goldberg, A. and D. Robson, (1983). Smalltalk-80: the language and its implementation. AddisonWesley, Reading. Goldberg, A. and D. Robson (1985). Smalltalk-80: the interactive programming environment. Addison-Wesley, Reading. GNbel, G. and H.-D. Joos (1992). RASP and RSYST two complementary program libraries for concurrent control engineering. In Computer Aided Design in Control Systems, H.A. Barker, Ed., Pergamon, Oxford, pp. 101-106. -
Grtibel, G., H.-D. Joos, M. Otter and R. Finsterwalder (1993). The ANDECS design environment for control engineering. In Proc. 12th IFAC Worm Congress, Sydney, Australia, 6, pp. 447-453.
Dittrich, Ed. (1988). Advances in object-oriented database systems. Lecture Notes in Computer Science, no. 334, Springer-Verlag, Berlin.
Horowitz, M.L. (1991). An introduction to objectoriented databases and database systems. CMU-ITC-91-163, Information Technology Center, Carnegie Mellon University, U.S.A.
Dittrich, K.R. (1992). Relations to objects: database technology in transition. In Proc. lASTED Int. Conf. on Informatics, Innsbruck, Austria.
ISO (1984). Basic reference model for open systems interconnection. ISO Standard 7498, International Standards Organisation.
Earl, A. (1990). A reference model for computer assisted software engineering environment frameworks. Tech. Rep. HPL-SEG-TN-90-11, Hewlett-Packard Laboratories, Bristol, U.K.
Joos, H.-D. and M. Otter (1992). Control engineering data structures for concurrent control engineering. In Computer Aided Design in Control Systems, H.A. Barker, Ed., Pergamon, Oxford, pp. 107-112.
ECMA (1990a). Portable common tool environment abstract specification. Tech. Rep. ECMA Standard 149, European Computer Manufacturers' Association, Geneva, Switzerland. ECMA (1990b). A reference model for computerassisted software engineering environments. Tech. Rep. ECMA/TR 55, European Computer Manufacturers' Association, Geneva, Switzerland. Elmqvist, H. (1978). A structured model language for large continuous systems. Tech. Rep. CODEN: LUTFD2/(TFRT-1015), Lund Institute of Technology, Lund, Sweden.
Kent, W. (1979). Limitations of record based information models. ACM Trans. Database Syst., 4, pp. 107-131. Kranser, G.E. and S.T. Pope (1988). A cookbook for using the model-view-controller user interface paradigm in Smalltalk-80. J. ObjectOriented Programming, 1, pp. 26-49. Kuhn, D.R. (1991). IEEE's POSIX making progress. IEEE Spectrum, 2,8, p. 36. Linton, M.A., J.M. Vlissides and P.A. Calder (1989). Composing user interfaces with Interviews. IEEE Computer, 22, pp. 8-22.
356
H.A. Barker
MacFarlane, A.G.C., G. Griibel and J. Ackerman (1989). Future design environments for control engineering. Automatica, 25, pp. 165-176. Maciejowski, J.M. (1984). A core data model for computer-aided control engineering. Tech. Rep. CUED/F-CAMS/TR-257, Cambridge University Engineering Department, Cambridge, U.K. Maciejowski, J.M. (1988). Data structures and software tools for the computer-aided design of control systems. In Proc. 4th IFAC Symposium on Computer Aided Design in Control Systems, Beijing, China, pp. 27-38. Maciejowski, J.M. (1992). Software standards in the control systems community. In Proc. IEEE Symposium on Computer-Aided Control System Design, Napa, U.S.A., pp. 238-241.
PACT (1988). PACT tool writer's guide. Syntagma, U.S.A. Pang, G.K.H. (1992). A knowledge environment for an interactive control systems design package. Automatica, 28, pp. 473-491. Rentsch, T. (1982). Object-oriented programming. SIGPLAN Notices, 17, pp. 51-57. Rimvall, M. (1989). Command language standard for CACSD software. IFAC Working Group on Standards for CACSD Software. Rimvall, M. and F.E. Cellier (1985). A stuctural approach to CACSD. In Computer-Aided Control Systems Engineering, North Holland, Amsterdam.
Rumbaugh, J., M. Blaha, W. Premerlani, F. Eddy, Mattson, S.E. and M. Andersson (1992). The ideas behind Omola. In Proc. IEEE Symposium on Computer-Aided Control System Design, Napa, U.S.A., pp. 23-29. Microsoft (1990). Microsoft windows user's guide. Microsoft Corporation, Redmond, U.S.A. Munro, N. (1988). ECSTASY - a control system CAD environment. In Proc. IEE Int. Conf. Control '88, Oxford, U.K., pp. 76-80. NIST (1991). Reference model for frameworks of software engineering environments. Draft version 1.5, National Institution of Standards and Technology, Gaithersburg, U.S.A. OMG (1991). The common object request broker: architecture and specification. Tech. Rep. Revision 1.1, Object Management Group, Farmingham, U.S.A. ONTOS (1991). The ONTOS reference manual. ONTOS, Burlington, U.S.A. OPEN LOOK (1989). OPEN LOOK graphical user interface - functional specification. AddisonWesley, Reading. OSF (1989a). OSF user environment component: decision rationale document. Open Software Foundation, Cambridge, U.S.A.
and W. Lorensen (1991). Object-oriented Modeling and Design. Prentice-Hall, Englewood Cliffs. Scheifler, R. and J. Gettys (1986). The X window system. ACM Trans on Graphics, 5, pp. 79-109. Schmucker, K.J. (1986). Object-oriented programming for the Macintosh. Hayden, Hasbrouk Heights. Select (1994). Select OMT user guide. Software Tools, Cheltenham, U.K.
Select
Soley, R.M. (1990). Standards manual. Tech. Rep. OMG TC Document 90.5.4, Object Management Group, Farmingham, U.S.A. Stroustrup, B. (1986). The C++ programming language. Addison Wesley, Reading. Sutherland, M.E. (1963). Sketchpad: a man-machine graphical communication system. AFIPS, 23, pp. 329-346. Taylor, J.H., D.K. Frederick, C.M. Rimvall and H.A. Sutherland (1989). The GE MEAD computeraided control engineering environment. In Proc. IEEE Control Systems Society Workshop on Computer-Aided Control System Design, Tampa, U.S.A., pp. 16-23.
Open
Thomas, I. (1989). PCTE interfaces: supporting tools in software engineering environments. IEEE Software, 6, pp. 15-23.
Otter, M. (1992). DSblock: a neutral description of dynamic systems. Tech. Rep. TRR 81-92, DLR, Munich, Germany.
Weinand, A., E. Gamma and R. Marty (1988). ET++ - an object-oriented framework in C++. In Proc. OOPSLA '88, pp. 46-57.
OSF (1989b). OSF/Motif manual set. Software Foundation, Cambridge, U.S.A
Pergamon 0967-0661(95)00006-2
OPEN ENVIRONMENTS AND OBJECT-ORIENTED METHODS FOR COMPUTER-AIDED CONTROL SYSTEM DESIGN H.A. Barker Deparanent of Electrical and Electronic Engineering,
University of Wales Swansea, Swansea, UK
(Received December 1993; in final form October 1994)
Abstract: Two current trends in the computer industry are towards open systems and objectoriented methods. Both are important for computer-aided control system design. The success of computer-aided software engineering is attributed to its open environment, based on a reference model that involves a service-oriented framework serving a set of tools. An adaptation of this reference model is proposed for computer-aided engineering in general and computer-aided control engineering in particular. Object-oriented methods are described, and their roles in the framework services are considered. Their particular importance for the modelling services of a computer-aided control engineering environment is established. It is concluded that a combination of open environments and object-oriented methods provides a unique opportunity for progress in computer-aided control system design that needs to be grasped if the world-wide control community is to benefit. Keywords: Software Environments; Open Systems; Reference Models; Object-Oriented Methods; Object Modelling; Data Types.
Complexity is also introduced by the requirements for quality and safety, which now require the design process to be proceduralised and documented to a hitherto unprecedented extent. Add the increasingly competitive nature of engineering world-wide and Gilbert might well have written:
1. INTRODUCTION The development of the computer has presented the control system engineer with both opportunities and challenges. Opportunities are provided by the ready availability of low-cost, high-speed, reliable hardware. To exploit them, the designer must either use or develop the software that utilises the power of the hardware. For one-off designs of small-scale control systems this is not likely to be a problem. The powerful software packages that are now available for analysis and simulation, MATLAB and SIMULINK for example, are normally sufficient for these cases. For more serious work, however, the designer is likely to encounter the challenges of complexity, quality, safety and competition.
"A designer's lot is not a happy one." Complexity need not, of course, be a problem provided that the designer is able to address it in a coherent fashion. In computer-aided control system design (CACSD), a completely coherent approach is unfortunately not yet available. Few of the software packages that a designer might wish to deploy in the various stages of the design process are compatible with each other, and attempts (Munro, 1988; Taylor et al., 1989) to integrate them into a coherent software environment for CACSD have not been particularly successful. Although the need for CACSD environments has long been recognised (McFarlane et al., 1989), the only successful example so far reported is ANDECS (Grtibel et al., 1993), and that was not developed by integrating proprietary CACSD software packages.
Much of the complexity of computer-aided design is self-inflicted. The power of the modem computer encourages the designer to be yet more ambitious at every stage of the design process. To paraphrase Browning: "A designer's reach should exceed his grasp, or what's a computer for?" 347
348
H.A. Barker
Fortunately, developments in software engineering, and particularly in computer-aided software engineering (CASE), give a clear indication of the direction in which CACSD environments should evolve to provide solutions for the problems of complexity. From CASE the open environment and from software engineering the object-oriented paradigm together provide the basis of a way forward in CACSD.
2. E N V I R O N M E N T S
The foundation of all forms of computer-aided engineering is the environment, which contains the software to support the engineering of a product or process throughout the whole of its life cycle, from conception and specification, through design and development, to implementation and operation. Among the environments for different forms of computer-aided engineering, CASE environments currently receive the greatest amount of investment and are the most technically advanced. These environments therefore provide an indication of the way in which CACSD environments should develop.
Interface for CASE environments. To support this, the Association has adopted a reference model (Earl, 1990; ECMA, 1990b) for CASE environments, and this has also been adopted by the American National Institute for Standards and Technology (NIST, 1991). The CASE environments reference model is shown in the "toaster" diagram in Fig. 1. Its principal feature is the division of the environment into a toolset, which provides the specialised facilities required by a particular user, and a framework, which provides the common facilities required by the whole environment. The common facilities are sub-divided into five groups of services, so that as standards are developed they cover the whole group.
2.1 CASE Environments Despite its fiercely competitive nature, the computer industry has long adhered to the open system concept. Indeed, it could be argued that spectacular growth of the industry would not have been possible without it. Kuhn (1991) has described the concept as "an interface specification to which any vendor can build hardware and software products", but the term was first used in "Basic Reference Model for Open Systems Interconnection" (ISO, 1984), which as ISO 7498 defined a set of international standards for the interconnection and interworking of different computer systems. In this context, a reference model provides a framework for debate and a focus for discussion between experts in the field, leading to the development of the standards on which the open system is based (Gibbons, 1991). It is therefore not surprising that, for CASE environments, the industry specified an open system defined by a reference model. It was once believed that a CASE environment could be formed by a co-operating set of tools with appropriate interfaces, but it is now accepted that it is necessary to provide the tools with a set of common facilities, or services, known as a Public Tool Interface (Gibbons, 1991). This takes the form of a service-oriented framework that, when populated with an appropriate set of tools, constitutes an environment. The European Computer Manufacturers' Association has adopted the Portable Common Tool Environment (Thomas, 1989; ECMA, 1990a) as the standard Public Tool
Fig. 1. CASE environments reference model. The service groups are:
User-interface services, which provide a consistent graphical user interface for the whole environment. Task management services, which create a taskoriented environment by inserting a layer of abstraction between the user and the fine detail of the facilities in the environment. Data repository services, which provide a store for all data objects in the environment. Data integration services, which enhance the services of the data repository by inserting a layer of abstraction to provide high-level semantics and operations with which to handle the stored data. Message services, which provide managed communication between all the facilities in the environment.
Computer-Aided Control System Design 2.2 Open Environments Reference Model
The CASE environments reference model is an archetype for open environments in other fields of computer-aided engineering. In the framework, the user-interface services group, the data repository services group and the message services group are independent of the field. Only the task management services group and the data integration services group, both of which introduce a layer of abstraction, contain field-dependent services. Those data integration services that are not field-dependent are best combined with the data repository services to form a field-independent group of database services that comprise a database with comprehensive management facilities. The remaining data integration services form a field-dependent group of modelling services, conveniently termed modelling services as in most fields they are concerned with modelling the physical world. The open environments reference model thus defined (Barker et al., 1993a) is shown in Fig. 2.
349
(Goldberg and Robson, 1983; 1985). The methods are particularly useful in software engineering for relating the real world to the artificial world of computer software, and although their usefulness tends to be obscured by jargon, they may in fact be readily applied elsewhere. The basic ideas will be recognised by control engineers as relating to a form of modelling that provides a logical basis for the process of abstraction by which models of complex entities are developed. They are explained here in terms of an object model that defines the structure and attributes of objects and relationships between them. An object model may be constructed by several different methods, but the graphical object modelling technique (Rumbaugh et al., 1991) for which supporting software is available (Select, 1994) is used here.
3.1 Objects a n d Classes The definition of an object is very broad, and may be taken as any concept, abstraction or thing with crisp boundaries and meaning for the problem in hand (Rumbaugh et al., 1991). When an object is a single entity, it is an object instance, or simply an instance, and a group of objects is an object class, or simply a class. In graphical object modelling, object diagrams are used to define objects and classes and the relationships between them. The basis of these diagrams is the class symbol, a rectangular box containing the class name and, optionally, the attributes of the class and the operations appropriate to the objects in it, as shown in Fig. 3. Instances of a class are shown in rounded boxes containing the values of the attributes.
Fig. 2. Open environments reference model. A striking feature of the environments defined by this reference model is the extent to which objectoriented methods may be applied throughout them (Barker et al., 1992). Before considering the features of CACSD environments, it is therefore useful to look briefly at these methods.
3. OBJECT-ORIENTED METHODS
Object-oriented programming is the current vogue in software engineering (Barker et al., 1993b), where its impact is likely to be as great as that of structured programming two decades ago (Rentsch, 1982). In that context, object-oriented methods are not new, but can be traced back three decades to the development of Sketchpad (Sutherland, 1963) and SIMULA (Dahl and Nygaard, 1966), although most of the modern ideas are derived from Smalltalk
Resistor name
supplier
cost resistance power rating
(Resistor) R2 Radiosparas 0.25 100000 1
(Resistor) R36 Famell 1.00 3.3 10
Fig. 3. Class and instances. A relationship between two classes is known as an association, which in an object diagram is denoted by a line between the class symbols, as shown in Fig. 4. An unterminated line indicates that there is a one-to-one relationship between instances of the associated classes. Termination with a circle at a class symbol denotes multiplicity; a solid circle indicates that zero or more instances of the class relate to a single instance of the associated class, while a hollow circle indicates that zero or one instances of the class relate to a single instance of the associated class.
350
H.A. Barker
Two forms of association are particularly important. One is aggregation, which is denoted by a line terminated with a diamond. The other is generalisation, which is denoted by a line terminated with a triangle. Aggregation is a relationship between a class and its components, in which instances of the class include instances of the associated class as component parts. It defines the way in which a system is divided into subsystems, and satisfies the test that one instance "is a part of" another. A simple example is shown in Fig. 4. Aggregation may be repeated to give an aggregation hierarchy with many levels.
I Circuit
]
[ Board I ITransistor I Resistor I[Capacit°r I Fig. 4. Aggregation with multiplicity Generalisation is a relationship between a class and its refinements.. The class that is refined is the superclass, or ancestor, and the refinements are the subclasses, or descendants. Those attributes that are common to all descendants are defined to be the attributes of the ancestor that are inherited by the descendants. The test to be satisfied in this case is that one instance "is a kind of" another. A simple example is shown in Fig. 5. Generalisation may be repeated to give an inheritance hierarchy with many levels. Component name supplier cost
2
L
Resistor resistance power rating
-
(Res~a~or)
(Inductor)
R2 Radiospares
L3 Farnell 1.50 0.01 0.0005 1500
0.25 1OOOOO I
• • •
Inductor inductance wire diameter turns
Encapsulation
The definition of an object requires that it has 'crisp boundaries', within which the object can be encapsulated so that its external features, which are accessible to other objects, are separated from its internal features, which are hidden from them. In object-oriented programming, this is known as information or data hiding. The separation of an object from other objects in its environment has two important consequences. One is that the implementation of the object can be changed without affecting other objects. The other is that the object can respond only to a message from another object containing appropriate instructions and data. The invoked response is known as a controller method if the state of the object is changed, or an observer method if the state of the object is simply returned. There is an obvious control engineering analogy.
4. CACSD E N V I R O N M E N T S The open environments reference model in Fig. 2 may now be developed for CACSD environments, and the role of the object-oriented methods in the framework services and tools examined.
4.1 Field.Independent Framework Services The field-independent services conform completely to corresponding services in the CASE environments reference model and are therefore relatively easy to define. A common feature is that each of the service groups has a layered reference model, in which each layer provides services to the layers above by adding functionality to the layers below. The levels of abstraction increase from the lowest layer of physical services to the highest layer of application services. Standards for the services in each layer are normally developed from the bottom up, until a set of standards is obtained for the whole service group as the basis for an open system.
Cllplcllolr capacitance voltage rating
1
(C-pa~or)
Fig. 5. Generalisation with instances.
3.2
cg Bulgin 1.5 0.0001 45
User-Interface Services. The reference model for user-interface services is the seven-layer Open Software Foundation model (OSF, 1989a) shown in Fig. 6. Although complete standardisation has not been achieved throughout this model, the use of a de facto standard such as Windows (Microsoft, 1990) or the X Window System (Scheifler and Gettys, 1986) allows portability across a wide range of computing platforms, while consistency of 'look and feel' is obtained by the use of OPEN LOOK (OPEN LOOK, 1989)or Motif (OSF, 1989b).
Computer-AidedConl~olSystemDesign
Layer 7 Application Services Layer 6 Dialogue Services Layer 5 Presentation Services Layer 4 Toolkit Services Layer 3 Toolkit Intrinsics Services Layer 2 Base Window System Services Layer 1 Data Stream Encodin~ Services Fig. 6. User interface services reference model. As their origins in the man-machine communication system Sketchpad (Sutherland, 1963) might suggest, object-oriented methods are extremely important for user-interface services. Control systems are often complex and cannot be comprehended without recourse to graphics. Interaction models, such as the model-view-controller (Kranser and Pope, 1988) found in Smalltalk (Goldberg and Robson, 1985) are paradigms in which graphics provides the view of a physical world model for which the state is changed by the controller. The concept of association is invaluable for decomposing large physical systems into notional structures that are accurately reflected in the actual structures of their graphical representations, leading naturally to the provision of views through multiple windows. Many object-oriented programming languages are used to support user-interfaces (Schmucker, 1986). Two particularly useful C++ (Stroustrup, 1986) class libraries that have been developed to support the synthesis of object-oriented user-interfaces in the X Window System (Scheifler and Gettys, 1986) are Interviews (Linton et al., 1989) and ET++ (Weinand et al., 1988). The underlying concepts are completely generic and not limited to these particular implementations. Services. The reference model for database services is the four-layer American National Standards Institute model for 'A Tool Integration Service' (ANSI, 1990), shown in Fig. 7. To maintain and manage all the information concerned with every application in the environment requires a set of services more comprehensive than that provided by most conventional databases. The diverse nature and complex structure of engineering
Database
351
data are better handled by an object-oriented database than by a relational database or a flat file system (Kent, 1979; Dittrich, 1992). With objects, rather than relations, used as the basis for data storage, the data maintain correspondences with the entities they represent, and can be handled in ways that are similar to those in which the entities are handled in the real world. If the stored properties of an object include executable operations, then the associated computation can take place within the database, rather than in the application program, and the user need not be aware that a value is retrieved by computation rather than look-up (Horowitz, 1991).
Layer 4 Work Flow Services Layer 3 Version Services Layer 2 Confisuration Services Layer 1 Object Services Fig. 7. Database services reference model. Object-oriented databases have been used successfully to support software engineering (Dittrich, 1988; Brown, 1991), and the database RSYST (Grubel and Joos, 1992) that supports the CACSD environment ANDECS (Grubel et aL, 1993) has object-oriented features and services so appropriate for engineering that it is referred to as "an engineering operating system". Commercial object-oriented databases include 0 2 (Deux, 1990), Gemstone (Bretl et al., 1989) and ONTOS (ONTOS, 1991). Message Services. The reference model for message
services is the seven-layer Open Systems Interconnection model (ISO, 1984) shown in Fig. 8. This is a fully standardised model in common use, which if necessary allows the environment to be distributed across a network of computing platforms. The services involve much more than simple message delivery, and for the higher layers of the reference model there is interest in the common object-request-broker (OMG, 1991), developed by the Object Management Group (Soley, 1990), and its associated Interface Definition Language. This is a message service for an object-oriented environment that allows objects to make requests and receive responses, enabling the framework services and tools to exchange not only data but also methods for manipulating them.
352
H.A. Barker
Layer 7 Application Services Layer 6 Presentation Services Layer 5 Session Services Layer 4 Transport Services Layer 3 Network Services Layer 2 Data Link Services Layer 1 Ph),sical Services Fig. 8. Message services reference model.
4.2 Field.Dependent Framework Services
The field-dependent services in CACSD environments are not as well developed as the corresponding services in CASE environments. Neither of the two groups of services involved has an agreed reference model, and this is a great impediment to the development of appropriate standards.
Task Management Services.
The function of the task management services is to create a task-oriented environment in which the user is insulated from the fine detail of the framework services and tools. This is accomplished by services to support the definition of tasks, to control the execution of tasks, and to record the history of tasks. For CASE environments, it is recognised that this group of services is the least well defined, because the subject of task management is still in its infancy and the understanding of the services involved is low (Earl, 1990; ECMA, 1990b). Although a reference model has yet to be defined for this service group, experience with other service groups suggests that it is likely to be a layered reference model. For CACSD environments, most progress will probably be made through procedural task management, in which a task is described by means of a command language, rather than declarative task management, in which only the goals of a task are specified. A standard for a command language has already been developed (Rimvall, 1989) based on IMPACT (Rimvall and Cellier, 1985), and it has been shown by Pang (1992) that knowledge-based methods may be combined with such a language for task management. Although knowledge-based methods will be useful for the automation of routine tasks in both kinds of task management, object-oriented extensions of these
methods are likely to provide additional advantages. The concept of association is directly applicable to the fundamental problem in this group of services, that of dividing tasks into sub-tasks, and both aggregation and generalisation will be involved.
Modelling Services. The function of the modelling services is to provide common facilities for handling the complex processes by which the real world, and understanding of it, is converted into a model appropriate for the purpose in hand. These services are obviously field-dependent, with the kind of model used reflecting the engineering field involved. The model type may be a unifying factor, as in the case of the finite-element models that are found in many engineering fields, but this is not, unfortunately, the case in control engineering, where several different types of model continue to be used to describe a single object. Agreement on a reference model for this group of services would be a useful step towards the unification that is necessary if open CACSD environments are to be achieved. A candidate reference model that may be evolved from practices in the successful ANDECS environment (Grubel et al., 1993) is the layered reference model shown in Fig. 9. Layer 4 High Level Model Services Layer 3 Neutral Model Services Layer 2 Control Data Object Services Layer 1 Data Exchange Services Fig. 9. Modelling services reference model. The service groups in this model are:
Data Exchange Services, which provide for the exchange of data in standard format with other environments, not necessarily for CACSD. The STEP neutral data exchange format and the EXPRESS data definition language are standards that could be adopted for this service group (Maciejowski, 1992).
Control Data Object Services, which provide a comprehensive set of data objects found in control engineering. These include not only system objects, such as transfer function and state space models, but also signal objects such as time and frequency responses. Such a set of objects was first proposed as a core data model by Maciejowski (1984, 1988). A more recent proposal by Joos and Otter (1992) is based on the object-oriented concept of generalisation.
Computer-Aided Control System Design
Neutral Model Services, which provide a standard set of descriptions for the fundamental dynamic systems that are the basis of all models. These might include, for example, a description of a set of differential-algebraic equations in an object-oriented language. In the ANDECS environment (Grubel et al., 1993) these dynamic system-, or DS-blocks are realised as FORTRAN or C subroutines (Otter, 1992). High-Level Model Services, which provide descriptions of complex systems in high-level modelling languages.-Traditionally, modelling has been simulation-oriented, with continuous systems simulation languages such as ACSL (ACSL, 1986) predominant. In future, modelling will be objectoriented and supported by languages such as DYMOLA (Elmqvist, 1978) and Omola (Mattson and Andersson, 1992). Object-oriented modelling of dynamic systems is essentially a bottom-up process, in which the fundamental dynamic behaviour of the system is encapsulated at the lowest level in elemental objects, described by Cellier (1991) as atomic objects. The encapsulated behaviour of an atomic object is described by an atomic model, which represents constraints on the variables involved and can take any appropriate form, such as a mathematical model in the form of equations, or a computer model in the form of code. Interaction between the atomic object and others occurs through variables at ports in its boundaries. In an electrical system, for example, the atomic objects are resistors, capacitors and inductors, the last two conferring dynamic behaviour on the system. Each atomic object is encapsulated in a boundary with two ports, one for the current through the object and the other for the voltage difference across it, and each atomic model implements the physical law that relates the voltage and the current. Fig. 10 illustrates the encapsulation of a capacitor, with an atomic model in the form of a pair of equations.
i
Y v= i=C
idt dv
• ..
dt
Above the atomic level, aggregation and inheritance hierarchies of more complex objects are developed, and to represent these graphically, the object diagrams described in Section 3 are invaluable. In an aggregation hierarchy, objects above the atomic level are described by Cellier (1991) as molecular objects. Each molecular object is composed of lower-level molecular or atomic objects. The behaviour of a molecular object is encapsulated in a molecular model that consists of descriptions of its lower-level objects and the interactions between them. For a given set of objects, only one aggregation hierarchy can normally be developed. An example of an aggregation hierarchy for a motorgenerator molecular object is shown in Fig. 11. Here the interactions between the lower-level molecular objects are constrained by the electro-mechanical coupling equations. The interactions between the atomic objects in the electrical system molecular object are constrained by Kirchoffs current and voltage laws while those between the atomic objects in the mechanical system molecular object are constrained by Newton's laws and geometry. The molecular model is valid irrespective of whether the object acts as a motor or a generator. Once the model is developed and proved, instances can represent any motor or generator of the class, so that model reusability is achieved.
Motor-Generator]
, Re~stoHrC~or 11Ind~ctoI r
~-1[ Sl:!ng11Mm
I
Fig. 11. An aggregation modelling hierarchy. In an inheritance hierarchy, the objects above the atomic level are in classes with common physical laws, and the descendants inherit the physical laws of the ancestors. For a given set of objects, more than one inheritance hierarchy can often be developed. Examples of two inheritance hierarchies for the atomic objects in Fig. 11 are shown in Fig. 12. One is a component hierarchy that is an extension of the simple inheritance hierarchy in Fig. 4. The other is an energetic system hierarchy in which all objects inherit the energy conservation law of the superclass, but only those atomic objects in a subclass inherit the law appropriate to that class.
: .:
•....
353
...."
Fig. 10. An encapsulated atomic object.
Object-oriented modelling languages are expected to support these methods of modelling, and to provide facilities for the development of class libraries. Acceptance of these will allow objects in CACSD environments to be treated as off-the-shelf items that can be taken down and slotted into new applications.
354
H.A. Barker 5. CONCLUSIONS
~
L
EM.~r~mechan,c~ al , ooo-.. ,
I ] CIq dtor It ,ndu=or I [ ReCtor I
I D" mLper II Sp"ng I
I
I
Energy r
Energy i
= Y=C J~dt I i
_]
:
Inductor [I Spring
Fig. 12. Inheritance modelling hierarchies.
4.3 Tools Tools are the most important part of an environment, because the framework and its services exist only to support them. A user must be able to select a toolset appropriate to an application and simply slot it into the framework. As the tools use the services that the framework provides, this obviates the need for toolmakers to add extensive features to tools just to provide these services, and allows them to concentrate on improving their tool's performance. The natural division of labour between framemakers and toolmakers is efficient, but it can only occur in open environments. Modern CACSD requires a diversity of tools, for example for identification, simulation and analysis by both numerical and symbolic methods (Barker et al., 1993c). To ensure that tools produced independently will function harmoniously in a toolset, they are best produced within a set of guidelines (PACT, 1988). In a mature open environment, the most successful tools are likely to be those produced by toolmakers who know how to take full advantage of the services that a framework provides. In the interim, tools not produced with framework services in mind might be encapsulated in appropriate software to allow them to be slotted into the framework. A new generation of object-oriented CACSD tools, for example Xmath (Floyd et al., 1991), is emerging for which this approach is quite feasible.
Progress in any field largely depends on the establishment of a basis on which to proceed. In CACSD, the lack of such a basis has inhibited the development of open environments, to the detriment of the control community. It is shown here that to rectify this situation it is necessary to adopt a reference model that will facilitate the development of appropriate standards on which open environments can be based. A variation of the successful reference model for CASE environments, in which each environment is divided into a servicebased framework and a toolset, has been proposed for this purpose. Most of the groups of framework services in this reference model are independent of the field of application, and therefore suitable for adoption with little alteration. Only the task management and modelling services are fielddependent, and for these the particular requirements of CACSD have been described. For modelling services, a novel reference model has been proposed. The fundamentals of object-oriented methods have been described and illustrated by means of object models. The relevance and impact of these methods in all parts of the CACSD environment have been demonstrated, and it has been shown that the concepts of generalisation, aggregation and encapsulation are particularly important for modelling. The potential of these methods in CACSD is considerable and has not yet been fully realised. Together with open environments, they provide an opportunity for progress in CACSD that needs to be grasped if the world-wide control community is to benefit.
REFERENCES
ACSL (1986). ACSL reference manual. Mitchell and Gauthier Associates, Concord, U.S.A. ANSI (1990). Working draft in formation resource dictionary system ATIS. Tech. Rep. ANSI X3H4/90-187, American National Standards Institute. Barker, H.A., M. Chen, P.W. Grant, C.P. Jobling and P. Townsend (1992). Object-oriented methods in computer-aided control engineering environments: a symbiosis for the future. In Proc. 2nd Int. Conf. on Automation, Robotics and Computer Vision, Singapore, pp. 10.1.110.1.5. Barker, H.A., M. Chen, P.W. Grant, C.P. Jobling and P. Townsend (1993a). A reference model for computer-aided control engineering. In Proc. 12th IFAC Worm Congress, Sydney, Australia, 6, pp. 437-441.
Computer-Aided Control System Design
355
Barker, H.A., P.W. Grant, C.P. Jobling and P. Townsend (1993b). The object-oriented paradigm: a means for revolutionising software development, lEE Computing and Control Engineering Journal, 4, pp. 10-14.
Floyd, M.A., P.J. Dawes and Xmath: a new generation CACSD tools. In Proc. Conf., Grenoble, France, pp.
Barker, H.A., I.T. Harvey and P. Townsend (1993c). Symbolic mathematics in control system analysis and design. Trans. lnst MC, 15, pp. 59-68.
Gibbons, M. (1991). A framework for standardisation and support environments technology. In Software Engineering Environments, F. Long, Ed., Ellis Horwood, Ch.3, pp. 155-167.
Bretl, R., D. Maier, A. Otis, J. Penney, B. Schuchardt, J. Stein, E.H. Williams and M. Williams (1989). The GemStone data management system. In Object-Oriented Concepts, Databases and Applications, ACM Press, ch. 12, pp. 283-308. Brown, A. (1991). Object-oriented databases: applications in software engineering. International Series in Software Engineering, McGraw-Hill, New York. Cellier, F.E. (1991). Continuous system modelling, Springer-Verlag, Berlin. Dahl, O.J. and K. Nygaard (1966). SIMULA - an Algol-based simulation language. Communications of the A CM, 9, pp. 671-678. Deux, O. (1990). The story of 0 2. IEEE Trans. Knowledge and Data Eng., 2, pp. 91-108.
U. Milletti (1991). of object-oriented European Control 2232-2237.
Goldberg, A. and D. Robson, (1983). Smalltalk-80: the language and its implementation. AddisonWesley, Reading. Goldberg, A. and D. Robson (1985). Smalltalk-80: the interactive programming environment. Addison-Wesley, Reading. GNbel, G. and H.-D. Joos (1992). RASP and RSYST two complementary program libraries for concurrent control engineering. In Computer Aided Design in Control Systems, H.A. Barker, Ed., Pergamon, Oxford, pp. 101-106. -
Grtibel, G., H.-D. Joos, M. Otter and R. Finsterwalder (1993). The ANDECS design environment for control engineering. In Proc. 12th IFAC Worm Congress, Sydney, Australia, 6, pp. 447-453.
Dittrich, Ed. (1988). Advances in object-oriented database systems. Lecture Notes in Computer Science, no. 334, Springer-Verlag, Berlin.
Horowitz, M.L. (1991). An introduction to objectoriented databases and database systems. CMU-ITC-91-163, Information Technology Center, Carnegie Mellon University, U.S.A.
Dittrich, K.R. (1992). Relations to objects: database technology in transition. In Proc. lASTED Int. Conf. on Informatics, Innsbruck, Austria.
ISO (1984). Basic reference model for open systems interconnection. ISO Standard 7498, International Standards Organisation.
Earl, A. (1990). A reference model for computer assisted software engineering environment frameworks. Tech. Rep. HPL-SEG-TN-90-11, Hewlett-Packard Laboratories, Bristol, U.K.
Joos, H.-D. and M. Otter (1992). Control engineering data structures for concurrent control engineering. In Computer Aided Design in Control Systems, H.A. Barker, Ed., Pergamon, Oxford, pp. 107-112.
ECMA (1990a). Portable common tool environment abstract specification. Tech. Rep. ECMA Standard 149, European Computer Manufacturers' Association, Geneva, Switzerland. ECMA (1990b). A reference model for computerassisted software engineering environments. Tech. Rep. ECMA/TR 55, European Computer Manufacturers' Association, Geneva, Switzerland. Elmqvist, H. (1978). A structured model language for large continuous systems. Tech. Rep. CODEN: LUTFD2/(TFRT-1015), Lund Institute of Technology, Lund, Sweden.
Kent, W. (1979). Limitations of record based information models. ACM Trans. Database Syst., 4, pp. 107-131. Kranser, G.E. and S.T. Pope (1988). A cookbook for using the model-view-controller user interface paradigm in Smalltalk-80. J. ObjectOriented Programming, 1, pp. 26-49. Kuhn, D.R. (1991). IEEE's POSIX making progress. IEEE Spectrum, 2,8, p. 36. Linton, M.A., J.M. Vlissides and P.A. Calder (1989). Composing user interfaces with Interviews. IEEE Computer, 22, pp. 8-22.
356
H.A. Barker
MacFarlane, A.G.C., G. Griibel and J. Ackerman (1989). Future design environments for control engineering. Automatica, 25, pp. 165-176. Maciejowski, J.M. (1984). A core data model for computer-aided control engineering. Tech. Rep. CUED/F-CAMS/TR-257, Cambridge University Engineering Department, Cambridge, U.K. Maciejowski, J.M. (1988). Data structures and software tools for the computer-aided design of control systems. In Proc. 4th IFAC Symposium on Computer Aided Design in Control Systems, Beijing, China, pp. 27-38. Maciejowski, J.M. (1992). Software standards in the control systems community. In Proc. IEEE Symposium on Computer-Aided Control System Design, Napa, U.S.A., pp. 238-241.
PACT (1988). PACT tool writer's guide. Syntagma, U.S.A. Pang, G.K.H. (1992). A knowledge environment for an interactive control systems design package. Automatica, 28, pp. 473-491. Rentsch, T. (1982). Object-oriented programming. SIGPLAN Notices, 17, pp. 51-57. Rimvall, M. (1989). Command language standard for CACSD software. IFAC Working Group on Standards for CACSD Software. Rimvall, M. and F.E. Cellier (1985). A stuctural approach to CACSD. In Computer-Aided Control Systems Engineering, North Holland, Amsterdam.
Rumbaugh, J., M. Blaha, W. Premerlani, F. Eddy, Mattson, S.E. and M. Andersson (1992). The ideas behind Omola. In Proc. IEEE Symposium on Computer-Aided Control System Design, Napa, U.S.A., pp. 23-29. Microsoft (1990). Microsoft windows user's guide. Microsoft Corporation, Redmond, U.S.A. Munro, N. (1988). ECSTASY - a control system CAD environment. In Proc. IEE Int. Conf. Control '88, Oxford, U.K., pp. 76-80. NIST (1991). Reference model for frameworks of software engineering environments. Draft version 1.5, National Institution of Standards and Technology, Gaithersburg, U.S.A. OMG (1991). The common object request broker: architecture and specification. Tech. Rep. Revision 1.1, Object Management Group, Farmingham, U.S.A. ONTOS (1991). The ONTOS reference manual. ONTOS, Burlington, U.S.A. OPEN LOOK (1989). OPEN LOOK graphical user interface - functional specification. AddisonWesley, Reading. OSF (1989a). OSF user environment component: decision rationale document. Open Software Foundation, Cambridge, U.S.A.
and W. Lorensen (1991). Object-oriented Modeling and Design. Prentice-Hall, Englewood Cliffs. Scheifler, R. and J. Gettys (1986). The X window system. ACM Trans on Graphics, 5, pp. 79-109. Schmucker, K.J. (1986). Object-oriented programming for the Macintosh. Hayden, Hasbrouk Heights. Select (1994). Select OMT user guide. Software Tools, Cheltenham, U.K.
Select
Soley, R.M. (1990). Standards manual. Tech. Rep. OMG TC Document 90.5.4, Object Management Group, Farmingham, U.S.A. Stroustrup, B. (1986). The C++ programming language. Addison Wesley, Reading. Sutherland, M.E. (1963). Sketchpad: a man-machine graphical communication system. AFIPS, 23, pp. 329-346. Taylor, J.H., D.K. Frederick, C.M. Rimvall and H.A. Sutherland (1989). The GE MEAD computeraided control engineering environment. In Proc. IEEE Control Systems Society Workshop on Computer-Aided Control System Design, Tampa, U.S.A., pp. 16-23.
Open
Thomas, I. (1989). PCTE interfaces: supporting tools in software engineering environments. IEEE Software, 6, pp. 15-23.
Otter, M. (1992). DSblock: a neutral description of dynamic systems. Tech. Rep. TRR 81-92, DLR, Munich, Germany.
Weinand, A., E. Gamma and R. Marty (1988). ET++ - an object-oriented framework in C++. In Proc. OOPSLA '88, pp. 46-57.
OSF (1989b). OSF/Motif manual set. Software Foundation, Cambridge, U.S.A