- Email: [email protected]
A Functional Programming Based CACSD Environment
(:()p\Ti~hl (:()n~n·ss.
© 11'.-\(: Illh Tri~nni,,1 \\'orld T"lIinn. bloni". l: SSR. 1'1'111
A FUNCTIONAL PROGRAMMING BASED CACSD ENVIRONMENT J.
D. M. Kinyua and
J.
M. Maciejowski
Departm pnt of Ellgineering. L'nil'Prsit)' of Cambridge . TrumpillgtlJlI StlPt't. Cambridge CB2 I PZ. Cl\. Abstract. An engineering design environment should allow users to design complex engineering systems, to manage and coordinate the designs as they proceed, and to develop and modify the software tools used for designs. These requirements call for a programming environment with an integrated set of software tools of different functionalities. The required functionalities are mainly: the provision of design algorithms based on suitable numeric software, appropriate data structures for the application area, a user-friendly interface, and the provision of a design database for the long term management of the designs generated. The provision of such an integrated design environment in a functional programming environment with particular emphasis on the provision of appropriate control-theoretic data structures and data model is described. Objectorientation is used to model entities in the application domain, which are represented by persistent objects in the database. Structural properties, relationships and operations on entities are modelled through objects and functions classified into strict types with inheritance semantics and a recursive structure. Keywords. Computer-aided design, Data structures, Data models, Database management, Functional programming, software tools, Control engineering applications of computers, software development, Control system design and analysis.
1
INTRODUCTION
During control design a large amolmt of data may be generated, especially by large industrial projects. For example, a non-linear system model may be linearised at several operating points and designs based on each of the linearised models will have their own simulation, analysis and design data. Tlus kind of data has complex interrelationsrups, evolves dynamically and needs to be kept in a consistent state as changes are made to data. Managing this kind of data unaided is difficult and prone to error. This is not unlike the characteristics of design data in other engineering fi elds, such as VLSI and mechanical design . Managing tIllS kind of data using traditional record-based (tuple-like) database management systems (DBMS) which are based on the relational, network or hierarchical data models has proved unnatural and too restrictive. DBMS's based on these traditional data models do not easily capture the semantics of the application area. In attempts to overcome problems with the lack of semantic power in the basic relational model, various methods have been used to enhance its expressiveness. In addition numerous (so-called) &em antic data model$ have been developed wruch increase the modellillg power by being able to handle semantically meaningful entities (or objects) rather than tuples or single records . The notion of object-oriented accessing has been incorporated to varying degrees of completeness into some prototype systems (Lorie and Plouffe 1983, Stonebraker e t al. 83). More recently a number of research projects have focussed on the development of data models that are more expressive than traditional data models but using slightly different techniques from those of semantic data models (OODBS 86). These object- oriented data models are usually centred around the concepts of large obj ec ts and extensive type structures; these arise in novel database applicati on areas like CACSD, m echanical CAD. VLSI design and so on and they incorporate the concept of local behaviour or procedure originating from object-oriented programming languages. Details of these models can be found in some recent surveys and the references therein (Hull and King 87, Maciejowski 88, OODBS 86).
Managing the kind of design and analysis problems that occur in control engineering together with the data generated in a database environment requires the use of some high level programming language. Such a language can be used for obtaining the dynamic behaviour of entities through suitable programs, modifying or querying the database. If we do not need an extra level of indirection to do database operations, for example special operators to store data objects away somewhere in some file space, then the language acts both as a database langauge and a programming language. This is an important feature and such languages have been termed databa.e programming language. in a recent survey (Atkinson and Buneman 87) . In addition, a uniform system interface to both objects and operations is important. Trus requires that there be no differences in the methods used to invoke design tools, low level operations, access to objects, and their operations. F\mctional programming languages are candidate languages for supporting the needs discussed in the previous paragraphs. The suitability of these 'new' langauges for computer-aided design and especially CACSD has not been fully investigated to date. Such languages should provide a set of basic data structures and facilities for defining further data structures as the need arises and programs for manipulating them. This should then mal
2
FUNCTIONAL PROGRAMMING AND DATABASES
2.1 Functional Pl'Ogramming 2.1.1 Introduction Functional progranuning languages solve a given problem by providing an abstract problem specification on what to do, while imperative (conventional) progranuning languages provide a recipe of how to do it (Darlington et al. 80). Functional programs are built from 'pure' functions (functions in a mathematical sense) and values. A function applied to a parameter or argument gives an expression which has a single value. The value of such an expression cannot be changed by evaluating it or by using the same expression in a different part of a program. Functional languages are therefore said to be referentiallll tran.par· ent. The process of applying a function to an argument is called function application and functional languages are alternatively termed applicative languages. Functions in imperative languages can produce different values for the same argument because such functions refer to global data which can be changed by destructive auignment statements. Hence expressions do not generally represent the same single value and imperative languages are therefore referentially opaque. A functional programming environment consists of types and values. Program evaluation (execution) involves reducing (altcring) expressions to the required flllal fonn where successive forms represent the same value. Since there are no assignable program states, evaluation does not alter the program execution environment and there are no .id e effect..
2.1.2 The ML Programming Language ML consists of a core language and a module. language (Harper, Milner and Tofte 88). Programs can be developed entirely within the core language or using both the core and the module languages. The module language is based on the core language, and consists of larger program structures as units containing core language constructs. The core language provides the basic types real, integer, boolean and string. The following data structure types are also available: tu pies, lists and labelled records, and any combination of these which maintains the type discpline. User-defined types, data types and abstract data types based on all the types described above can be defined and used like all the other types provided by the language. The other important prograrruning constructs are: if-thenelse, case, do, while, and, andalso, orelse (the logical connectives), exception handling, in fix flmction definition with selectable binding and change of infix status, recursive function definition, local functions and values within other functions and values, clausal function declarations , pattern matching, value and function declarations, imperative (reference) type variables and so on. There is a stream-based input-output facility with a well established I/O protocol. Functions in a program can take other functions as arguments and produce functions as results. The module language consists of .ignalttre., .tructure& and junctor., derived from the core language. Modules allow modular solution of a large software problem, and inheritance between module structures is possible. A structure is a collection of data types, types, values, exceptions and probably other structures. A signature specifies types and data types and gives the types of values and exceptions. A functor is essentially a function from structures to structures. Functors cannot take other functors as arguments and they cannot produce functors as results. The ML structures are analogous (roughly) to ADA packages, CLU clusters and so on.
ML is strongly-typed, statically type-checked and has a type inference system which supports polymorphism. This implies that ooe can define a function which operates urufonnly over a range of types. A good example of this type of polymorphism is the generic list length function which takes a list of any type and returns an integer. There is a relationship between inheritance and polymorphism, and ML's polymorphism can be used to provide some inheritance. ML is not a pure functional language. There are imperative type variables which can be ur--dated by assignment and input-output has side-effects, which are both features of non-applicative languages. Although one can write programs in a purely functional style, at some point it will become necessary to communicate with the outside world and side-effects will occur. The updatable variable types can be useful if operating in a databaoe environment where changes are continuously being made to data.
DL. Some prototype experiments of the work described in this paper were done using another functional language DL (Data Langauge), which has a database extension (Breuer 88) . DL has a set of data types and data structures (both user-extendable), though not as rich as in ML, and a dependency mechanism which maintains semantic consistency between data values in the database when changes occur (in a manner almost similar to the imperative types in ML) in the environment . It is strongly-typed and has a type-inference IlIcd.anism. There were two main problems encountercd in using this language. (1) There are no reserved words, few restrictions and the user can make 'any' programming constructs (subject to the type disclipline) . This proved very limiting since a pre-assigned set of inbuilt syntatic programming constructs is necessary to develop large applications at the top environment. (2) The language implementation has not yet been tested by many users so that any bugs may be revealed. Developing robust programs proved very painstaking and time consuming. ML was subsequently chosen because of its blend of experience and the fusion of useful features from other functional languages.
2.1.3 Example functional programs We give some examples of functional programs. The examples given here are coded in standard ML, although any other functional language could have been used to illustrate programming in a functional style. We start by defining a generic tool called reduce which can be adapted to different needs by supplying it with different types of arguments:
fun reduce f x [] = x reduce f x (a: :b) = f a (reduce f x b). Val declares new values and fun declares new functions. Reduce takes a function f, a value x of some type, and a list of elements (all of the same type) and returns a single result which has the same type as x. f takes a value of the same type as the list argument elements and a second argument of the same type as x (just the result type of reduce) and returns the result type of reduce . Its type is stated as: reduce :
('a -) 'b -) 'b) -) 'b -) 'a list -) 'b,
where 'a and 'b are type parameters and represent any type. Next define some functions which can be used as a first argument of reduce , fun plus a b = a+b fun times a b = a*b fun cons x (a : : b) = (x: : a : :b) fun insert (x:int, []) = x: : [] insert (x, y: : ys) = if x<= y then x: :y: :y5 else y: :insert(x,ys) .
Cons inserts an item at the head of a list of elements of the same type. The cons is a comnlOn list constructor in functional languages and it is so corrunonly used that in most languages it has an infix status and is usually given the symbol ' :' or ' ::'. For example 4::[8) = [4,8), and is the equivalent to cons 4 [8]. Insert takes an integer and an integer list and inserts the integer in its proper sorted place in the list. Now we can define the new functions sum, product (which add and multiply a list of numbers respectively), sort (which sorts a given integer list in its proper numeric order) and map which applies a function 9 to every element o f the list argume nt given to map . val sum = reduce plus 0 val product = reduce times 1 val sort = reduce insert [] ~un map g IS = reduce (cons 0 g)
IS
Notice the use of the function compostion operator 0 to define map. For any argument t of the right type, (con$ 0 g) t = cons(g(t», and this is essentially similar to the co de for that operator. fun (f
0
g) t
=~
(g t)
!'lap is a very useful function and can alternatively be defined as: fun map g [] I map g (a : :b) = a) :: map g b) and the two definitions have the same effect. In general reduce may be used to define many useful functions by defining different 'f ' $ and then chosing some appropriate x. Notice reduce is defined reclLr$ively and it works by pattern-matching on some of its argument . These two are important features of functional languages.
= []
«g
Functional languages have at least the same computational capahilities as othe r high I"vellangllagcs, hut they do have some extra attractive features . (1) They can take other functions as arguments of other functions and produce functions as results. We say that functions are first class values of the language just like booleans or integers since they can also be arguments or results just as the latter can be. This feature is not found in most high level languages. (2) They have powerful pattern matching capabilities, which helps in writing clearer and succinct code. (3) Most functional languages are strongly typed, incorporating a type-inference system which makes it much easier to develop programs rapidly. Generally these languages are function-based, elegant , have easily d efined semantics and are o f high e xpressive power which is also advantageous.
2.2 Databases Programming languages and databases have historically evolved along different lines, mainly because they were d e veloped for different purposes. Originally databases were developed for long term storage and manipulation( querying and updates) of data, and general purpose programming languages for complex computation. With time the need to have these two facilities in one environment., fo r example wh ere stored long t l'rm data is needed for high level computations not po ssible with databases, became necessary. In the early database systems and existing commercial database systems, special database sublanguages, were used to query and modify the database . The various ways these systems are accessed can be found in the literature (Pirotte and Lacroix 80, Atkinson and Buneman 87). R ecent attempts have been made to integrate databases and programming languages in one uniform environment, where the same language is used for general purpose progranuning as well as database access (Atkinson and Buneman 87) . The methods that have b een used to integrate the two are: (1) extending an existing language with the
:Eil
data types of an existing database system, (2) adding persistence to a new or existing language so that persistence is available to all the data types of the language, and (3) developing a new language based on a conceptual data model which also acts as a database model. The language used in the work described in this paper has an integral database which has been provided using the second method described above. It is the persistent ML available with PolyML (Matthews 88) . In the programming environment all the data types are endowed with persistence and not just some special types. There is a striking resemblance between the type declarations in a programming language and the type definitions of a data definition language for a database schema. A database can be modelled as a set of types and a set of operators which manipulate the types, and this is the kind of model proposed for relational databases fifteen years ago (Codd 70). The view taken here, therefore, is that if we have a persistent programming language, then a database can be constructed from the data types (and their instances) of a programming language and what one needs is a programming language with a generic type structure to allow the program to create his own representation of a data model, something which appears to be a major problem for most languages (Buneman 84). With this view, we can describe a database model for control engineering, by an appropriate choice of data model constructs.
3
DATABASE MODEL FOR CONTROL ENGINEERING
3.1 Overview Semantic and object-oriented data models support the structural abstraction mechanisms of classification, aggregation, generalization/specialization and composition, as well as procedural abstractions for database operations. The data model desc ribed here contains features from both semantic data modelling and object-oriented data modelling. It bears some resemblance to the functional data model (Shipman 81), but includes more semantic features. The main modelling construct in our data model is the object with unique identity and existence; this will represent some real-world entity, for example some plant or controller. All objects in the database will belong to some particular type, and there will be three varieties of objects: type, instance and function objects. Objects with unique identifiers provide better control of database integrity and raise the level of interaction between the users and the environment since objects form the currency of transactions. In contrast record-oriented data models would represent a design object as a set of records which are referred to in terms of their attributes values. The potential problems with regard to database integrity and the burden to its users are apparent. We shall make suitable structural and operational abstractions which capture important application semantics of control systems, and use suitable representations for these abstractions to show, by an example, how these can assist users in manipulating and modifying such a system. Most of the important abstractions have been achieved by the semantic hierarchical data model of Maciejowski (85), which organizes a dynamic system along the same concepts as control engineers usually think in terms of during design and analysis . This core data model is shown in Fig. 1. We shall identify suitable data type$ which correspond in some meaningful way to most of the structural aspects of the core model and then define suitable manipulation operators over these types. The data types chosen are based on the abstraction mechanisms stated above. The manipulation operators are just functions over these types. The generalization/$pecialilation abstraction is used to define
type hierarchies with inheritance semantics. Database updates and queries are also expressed through functions.
3.2 Control-theoretic types We discuss some examples of types identified as suitable for representing the core model. We can use the aggrega· tion abstraction to define a type port which describes an interface point of a dynamic system as a record consisting of the attributes: portJd, port_type and channels. The portjd is a unique name identifier for a port, porLtype is of type terminal where terminal can be Input or Output and channels is a list of channels associated with that port, this is applying a compo!ition abstraction. The channel type is also based on the aggreggation abstraction and is a record consisting of a signame stating the signal name, varname which is a name variable for the signal, units stating its units, and range..def which states the range of validity of the signal. Objects of these types can be created using suitable operators, this process called in!tantiation is the inverse of claHification. We shall have the type trfn which can either be a singleinput single-output (5150) tran!fer function consisting of a numerator and a denominator or a transfer function matrix which is a matrix of 5150 transfer functions to take care of the multivariable case. This is declared as : datatype trfn = null_trfn I Trfn of numden I TrfnJnlltrix of trfn matrix numden is a numerator-denominator pair type of real coefficients and null_trfn is a default value to be used in cases where the transfer function attribute is unknown or still has to Le computed from some other attributes. Trfn and Trfn..DIatrix are t.ype constructors which act as headers for instances of the type trfn. The type stsp consists of either four !tate spa ce matrice! (a, b, c, d), a state vector and a vector of initial conditions or a sta te space matrix ,a state vector and a vector of initial conditions. This is declared as: datatype stsp = null..stsp I Stsp of stsp-abcd - state_vector - real list I StspJnlltrix of stsp-abcd matrix - state_vector - real list stsp..abcd is just a 4-tuple of variable- matrix pairs. The variable is the name of the corresponding matrix. All such state space instances are initialised to the names ("a" ,"b", "c", "d" ) by default but the user can change these names using a suitable function. As another example the type defn consists of a tuple containing the types just explained above and the new types dfqn (differential equation) and structur (!tructure) (there is no restriction by the language on the length of name identifiers of types , functions and instances, but structure is a reserved word in ML). The structure attribute of !!fstem dermes the subsyst ems of the system and specifies how they are connected together. The connection is described by hookup which has been given a type of the same name. System is defined as a record type with the attributes shown in the core model of in Fig. 1. The mutual dependency of defn, structur and system types requires them to be declared together and this may done as follows: datatype system = null..system I System of {nameJd : string.class:class.connections : port list. defn:defn.properties:property list} and defn = null..defn I Oefn of (trfn - stsp - dfqn - structur) and structur = null..structur I Structur of (system list - hookup) In the above declaration. the data type system depends on defn. which depends on structur. while structur de-
352
pends on syste.. This dependency between these types also implies that functions defined over them will be dependent in the same manner. and this is so if we have a large hierarchical system containing other subsystems. Since we may need to have linear or non-linear systems or special systems for example IUmming junction •• plitter and combiner•• it is better to declare system as a parameleric type. Thus we can have: datatype 'a syste. = null~yste. I System of {nameJd : string,class:'a class. connections:port list.defn:'a defn.properties:'a property list} and ' a defn '" null..defn I Oefn of ('a trfn - 'a stsp - 'a dfqn - 'a structur) and'a structur • null~tructur I Structur of ('a syste. list - hooknp) and the type of system is reflected in its clau. definition and ,tructure attribute values. In this declaration the parameter '0. is a type parameter. It allows us to have different characteristic cia ... definition and .tructure attribute types with which we can derive different system subtypes. This also requires the types trln. 813p. dfqn and .tructur to be declared as parametric types. characteristic of the system subtypes intended. When system is declared as a parametric type we achieve the power of deriving different system subtypes by instantiating the type parameter to some specific type. This parameterisation ability is due to the polymorphi!m of the language. and can be used as a way of obtaining some inheritance and as mentioned earlier. In the example to be discussed we shall use the non-parametric system type definition.
3.3 Operations The basic initial operations are creating objects of some of the types described in the previous sub-section. In a purely abstract type system. this can only be done using functions which have to be defined for that purpose during the abstract types declaration. The abstract types enforce a strict discipline on the use of values of those types which is not the case with the data types. After creating various objects. functions can be implemented for creating new and possibly larger objects. obtaining value attributes of created objects. computing their behaviour or responses to some given conditions. connecting systems together in some specified way and so on. In addition objects may have function object components.
4 EXAMPLE The control system example discussed here is that by Astrom and Kreutzer (86), in Fig. 2 with the extra special subsystems. summer and the two splitters. These have been incuded explicitly to facilitate the unambiguous specification of interconnection points and their efficient manipulation by the the system operators which have been made available. We consider how the object reg(Regulator} is created. The following declarations are made: val reg.Jlame .. "Reg" val reg...class • Class [" linear" ,"time..invariant", "continuous_tia. It ] val reg..inportl " ref (Port{portJd .. "reg$pl".
channels=[Channel{units="",sigvar-"r", signame= ..... range..def"[]}J. port_type" Input}) val regJnport2 z ref (Port{portJd • "reg$p2". channels
z:
[Channel{units zsftll .aigvars"J",
lIigname ....... range..def.[]}J. port_type· Input}) val regJlutport .. ref(Port{portJd • "reg$p3". channels "[Channel{ un! tll"''''. sigvar="u". signame" ..... range..defz[]}] .port_type "output}) val reg...connectiona " [! reg..inportl. regJnport2. ! regJlutport]
val reg-stsp =(make-stsp( ([Ha" "b" J liCit J "d"],
ferent systems accorcling to the interconnections shown in Fig. 2. We first specify the systems we want to interconnect. this system list is needed in the interconnection algorithm: vu nevJSystemJ.ist = [ff().model().reg().summing_junctionl().proc(). sensor().splitterl().splitter2()] then the way we want to interconnect them. .,al nev..system..hookup "' Bookup [(! ff-inport,! splitterl-Outportl). ( ! 1110 de l-inpo rt • ! spli tterl.J)utport1) • ( ! reg-inportl • ! 1Il0del-Outport) • (! s1llllllling_junctionl-inportl.! ff.J)utport). (! s1llllllling_junctionl-inport2.! reg.J)utport) • (! proc-inport.! sUlllllling_junctionl-Outport) • (! spE tter2-inport.! proc.J)utport) • ( ! sensor-inport. ! spE tter2.J)utport2) • (! reg-inport2.! sensor.J)utport)l. and then state which ports we want to act as the external ports of the new connected system, .,al nev..system..connections co [! spE tterl-inport. ! spE thr2.J)utportl]. as well as naming any ports provicling negative feedback. n l neg~eedbaclt...ports = [! reg-inport2] . Thereafter we can use the function systelll..lll.,connect which is implemented entirely within the language to interconnect the systems together by the function application: fun nevJSystem() lIl.,connect nev..systemJ.ist nev..systelll..hookup nevJSystem..connections neg~eedback_ports "nev..JIystelll" where "new..system" is the name of the new system. This will perform all the necessary computations. finally returning a new system with attributes derived from the component systems. We can query for properties or any attributes as we did with model.
j
[[[0 . 0,0.0],[0 . 0, 18.6]], [[0 . 18868, 0.18868],[0.0,18.6]]. [[1 . 0.3.72]]. [[1. 0.4 . 72]]]). [], []» val reg_trfn=ref(stsp2trfn«! regJStsp).1 . 0» fun reg~efn()=Defn«! reg_trfn).(! regJStsp). null~fqn, nullJStructur) val reg_properties = ref null-prop fun regO = ma1teJSystem(reg..name,reg..class. reg_connections, (reg~efnO) ([[0.0,0.0),[0.0, 18.6)) is a 2x2 matrix) . The value of objects declared as reference types (using rei) may be changed at a later time, and because of declaring them as mutable values, any change is reflected in all other objects using those objects in the database. RegJbp is created through the makeJt3p function which checks the necessary contraints. The system object reg is created by the makeJY3tem function which also checks all the required contraints. The reg_defn and reg objects have been declared as nilary argument functions so that any changes which occur in their components (say if we change reg_trfn to some new value by an update) at a later time are reflected in them if we subsequently demand them or use them. Initially reg_trjn is unkown, but there is a function 3t3p2trjn which when applied to a state space value returns its transfer function form. It works by calling PRO-MATLAB (MoleI' and Little 87) to make the appropriate transformation. The other systems in Fig. 2 are declared in a manner similar to reg above.
=
We can now demand for example the impulse reponse of model IIsillg t.he fllnd.ion system_impulse by the application: system-impulse (model(» [] and we get back a vector of response values and their corresponding time vector which in this case is the default time vector [0:1:50], but if this is inappropriate we could provide the one we wish as the last argument above instead of O. We can ask for a plot of this response or store it away in the properties attribute of the system model by model_properties : = insert-property (reg(» (make_trajectory ("impulse", 1111) ("time", "secs") (systeBLimpulse (model(» []». Malte_trajectory takes the name of the property (impulse in this case) and its units, the name of the independent variable (time) and its units (seconds), their values and then creates a property attribute of system. This is then used by the insert-property function to store it in the system model. There is also malte_property which deals with those properties that do not need to include an independent variable for example , stability.
As a final example we may want the behaviour of a system for a range of parameters values, for example the dynamics of Regulator depends on k, Ti. Td and N and this is reflected in its A. B, C. D matrices. We can have a parameterised Regulator function which takes k. Ti, Td and N and returns a state space value for particular values of these parameters. We can do this by. fun malteJ'eg..stsp Ti Td • k ~ let Tal ITd z I/Td .,al kl - ItJ .,al ITi c 1 . 0/Ti val a • [[0 . 0 0 . 0].[0 . 0 ITd]] .,al b • [[ITi ITi].[O . O ITd]] .,al c [[k. kl]] YBl d [[It. (k+ItJ)]] in malte..stsp«["' ..... B... "e" ."D"] .[a.b.c.d]).[] .[]) end. We can then say keep Ti and N fixed and obtain reg..stsp for values of k say in the range (1 - 10) which can be done by: val reg..JItspJ
Similarly we could generate a frequency list w, and then ask for the frequency response of the system model by: val model_bode = system_bode (model(» v and we get back a response vector whi ch we can plot or store away in model by the request : model_properties := insert_property (model(» (malte_trajectory ( " bode".'''') ("frequency". "Hz") modelJ>ode) and asking for the modeLproperties should now return both the time response created earlier, without recomputation, and the new frequency response. In general we can demand any control system design utilities available in the control system tools of PRO-MATLAB , though the data goes tlu'ough major transformations to reorganise it into the data struc tures used here . The int erface between ML and PHO-MATLAB is essentially sill1ilar to the one used used in parallel work involving PRO LOG, described elsewhere in these pro ceeclings (Tan and Maciejowski 89) .
=
As a more interesting example let us interconnect the c1if-
35 3
5
CONCLUSIONS
The use of a functional language for implementing the applications described here has been very convenient for the following reasons. Firstly, the usage of functions as described here very much resembles the mathematical concept of a function and even in control applications, resembles the way in which control theory problems are formulated. Secondly, in a functional language a user specifies what to do, the details of how to do something being abstracted away. Thirdly, all objects are first class values of the language, and this implies that any object including other functions can be an argument and a result of a function . This means that all values within the environment are treated uniformly and the user can interact with higher level objects directly. Consequently, the resulting programs are more compact and easily readable. The .trong typing regime combined with .tatic type checking results in a program development environment where a user cannot write type-incorrect programs. The set of types and the provision of facilities for definition of userdefined types and functions over them has proven to be a very versatile set of data structuring tools for the design environment. Not all these tools have been fully exploited yet and future work wiU involve full polymorphic use of the abstract types and modules. Although the language is fully statically type checked, we think that a certain amount of dynamic type checking, available when necessary would be very useful. This would make it easier to support dynamic schema modification, something which is very difficult to achieve in the present circumstances. Other issues not yet resolved, but are for future consideration are: support for dynamic schema modificat.ion, design history management, provision of design object views, versioll control , and transaction control. We believe that fWlctiollal languages will prove to be strong candidates for the implementation of software tools for future CACSD systems.
6
Lorie, R . and Plouffe, W. (1983). Complex Objects and their use in design transactions, Proceeding. of the Databau week, SICMOD, A CM, pp. 115-121. Maci ej ow ski , J . M. (1985). A core data model for computer-aided control engineering, Cambridge Univer-
sity Engineering Department, Technical Report CUED/FCAMS/TR257 (1985), Cambridge University England. M aciejow ski , J. M. (1988) . Data structures and software tools for the computer aided design of control systems: a survey. ,4th IFA C Symposium on CA CSD, Beijing, China, pp27-38. Matthews, D. C . J . (1988). A Persistent Storage System for Poly and ML. In Technical Report No . 161, Computer Laboratory, University of Cambridge, England, 1989. Moler, C . and Little, J. (1987). PRO-MATLAB Users Guide. The Mathworks Inc. , Sherborn, M. A. 01770, USA. OODBS 1986. 1986 International Workshop on ObjectOriented Databue Sy.tems. Pacific Groove, CA, USA. Pirotte, A. and Lacroix, M . (1980). User interfaces for database application programming. In Infotech State of the A rt Conference on Database • . Info tech , London England. Rimvall, C . M. (1986).Man-Machine Interfaces and Implementational Issues in Computer-Aided Control System Design. PhD Dissertation, Swiss Federal Institute of Technology, Zurich (ETH No. 8200). Shipman, D. (1981). The Functional data model and data language Daplex. A CM TranMctions on Database systems, Vol. 6 No. 1, pp. 140-173. Stonebraker, M., Rubenstein, R. and Guttman, A. (1983) . Application of abstract data types and abstract indices to CAD Data Bases. Proceedings oJ the Da tabase Week, SICMOD, A CM, New York, pp. 107-113. Tan, C. Y. and Maciejowski, J. M . (1989). A Prolog programming based CASCSD Environment. Proceeding. of the IFAC World Congre .. , August 1990, Tallinn, USSR, submitted.
ACKNOWLEDGEMENTS
The authors ' research is supported by the Science and Engineering Research Council, grants G RI 0/17830 and GR/D/60782, and Shell International limited through the Cambridge Commonwealth Trust.
7
REFERENCES
Astrom, 1<. J. and Kreutzer, W.(198G). System representation, Proceeding. of the IEEE Control Sy.tem. Society Third Sympo.ium on CA CSD, Arlington , Virginia, VA, USA . Atkinson, M. P . and Buneman, O. P. (1987) . Types and Persistence in Database Programming Languages. A CM Computing Survey., Vol. 19, No. 2, pp. 105-190. Breuer, P . T. (1988). A Data Language - DL. Cam-
bridge University Engineering Department, Technical Report CUED/F-INFENC/TRI6 (1988). Cambridge University, England. BUllcmall, O. P. (1981) Can we reconcile pmgrnrnming languages and databases? III "Databau.: Role and Structure ", Cambridge University Press, Cambridge, England. Codd, E. F . (1970). A Relational Model for large shared databanks. Communication. of the A CM, Vol. 13, No . 6, pp. 377-387. Darlington, J., Henderson, P., Turner, D. (1980). Functional programming and it. applications. An advanced course. Cambridge University Press. Harper, R., Milner, R. and Tofte, M. (1988). The definition of Standard ML Ver.ion 2. LFCS, Department of Computer Science, Uni\'ersity of Edingurgh, Scotland. Hull, R. and King, R. (1987). Semantic Data Modelling: Survey, Applications , and Research Issues. A CM Computing Survey., Vol. 19 No. 3, pp. 201-260.
Fig.1. The Core Data Model.
pl····· .. --~···- .. ···· .. ··y········· .. ···· .. ··· ..··· .. ····· ........ . !:::.
FF
pT· .... ·· .... _··_-_ .. ·· .. ··· .... ·· ........yl
u:
·· :
...............................................
:. ....................................................................... Fig. 2. Example control system.
© 11'.-\(: Illh Tri~nni,,1 \\'orld T"lIinn. bloni". l: SSR. 1'1'111
A FUNCTIONAL PROGRAMMING BASED CACSD ENVIRONMENT J.
D. M. Kinyua and
J.
M. Maciejowski
Departm pnt of Ellgineering. L'nil'Prsit)' of Cambridge . TrumpillgtlJlI StlPt't. Cambridge CB2 I PZ. Cl\. Abstract. An engineering design environment should allow users to design complex engineering systems, to manage and coordinate the designs as they proceed, and to develop and modify the software tools used for designs. These requirements call for a programming environment with an integrated set of software tools of different functionalities. The required functionalities are mainly: the provision of design algorithms based on suitable numeric software, appropriate data structures for the application area, a user-friendly interface, and the provision of a design database for the long term management of the designs generated. The provision of such an integrated design environment in a functional programming environment with particular emphasis on the provision of appropriate control-theoretic data structures and data model is described. Objectorientation is used to model entities in the application domain, which are represented by persistent objects in the database. Structural properties, relationships and operations on entities are modelled through objects and functions classified into strict types with inheritance semantics and a recursive structure. Keywords. Computer-aided design, Data structures, Data models, Database management, Functional programming, software tools, Control engineering applications of computers, software development, Control system design and analysis.
1
INTRODUCTION
During control design a large amolmt of data may be generated, especially by large industrial projects. For example, a non-linear system model may be linearised at several operating points and designs based on each of the linearised models will have their own simulation, analysis and design data. Tlus kind of data has complex interrelationsrups, evolves dynamically and needs to be kept in a consistent state as changes are made to data. Managing this kind of data unaided is difficult and prone to error. This is not unlike the characteristics of design data in other engineering fi elds, such as VLSI and mechanical design . Managing tIllS kind of data using traditional record-based (tuple-like) database management systems (DBMS) which are based on the relational, network or hierarchical data models has proved unnatural and too restrictive. DBMS's based on these traditional data models do not easily capture the semantics of the application area. In attempts to overcome problems with the lack of semantic power in the basic relational model, various methods have been used to enhance its expressiveness. In addition numerous (so-called) &em antic data model$ have been developed wruch increase the modellillg power by being able to handle semantically meaningful entities (or objects) rather than tuples or single records . The notion of object-oriented accessing has been incorporated to varying degrees of completeness into some prototype systems (Lorie and Plouffe 1983, Stonebraker e t al. 83). More recently a number of research projects have focussed on the development of data models that are more expressive than traditional data models but using slightly different techniques from those of semantic data models (OODBS 86). These object- oriented data models are usually centred around the concepts of large obj ec ts and extensive type structures; these arise in novel database applicati on areas like CACSD, m echanical CAD. VLSI design and so on and they incorporate the concept of local behaviour or procedure originating from object-oriented programming languages. Details of these models can be found in some recent surveys and the references therein (Hull and King 87, Maciejowski 88, OODBS 86).
Managing the kind of design and analysis problems that occur in control engineering together with the data generated in a database environment requires the use of some high level programming language. Such a language can be used for obtaining the dynamic behaviour of entities through suitable programs, modifying or querying the database. If we do not need an extra level of indirection to do database operations, for example special operators to store data objects away somewhere in some file space, then the language acts both as a database langauge and a programming language. This is an important feature and such languages have been termed databa.e programming language. in a recent survey (Atkinson and Buneman 87) . In addition, a uniform system interface to both objects and operations is important. Trus requires that there be no differences in the methods used to invoke design tools, low level operations, access to objects, and their operations. F\mctional programming languages are candidate languages for supporting the needs discussed in the previous paragraphs. The suitability of these 'new' langauges for computer-aided design and especially CACSD has not been fully investigated to date. Such languages should provide a set of basic data structures and facilities for defining further data structures as the need arises and programs for manipulating them. This should then mal
2
FUNCTIONAL PROGRAMMING AND DATABASES
2.1 Functional Pl'Ogramming 2.1.1 Introduction Functional progranuning languages solve a given problem by providing an abstract problem specification on what to do, while imperative (conventional) progranuning languages provide a recipe of how to do it (Darlington et al. 80). Functional programs are built from 'pure' functions (functions in a mathematical sense) and values. A function applied to a parameter or argument gives an expression which has a single value. The value of such an expression cannot be changed by evaluating it or by using the same expression in a different part of a program. Functional languages are therefore said to be referentiallll tran.par· ent. The process of applying a function to an argument is called function application and functional languages are alternatively termed applicative languages. Functions in imperative languages can produce different values for the same argument because such functions refer to global data which can be changed by destructive auignment statements. Hence expressions do not generally represent the same single value and imperative languages are therefore referentially opaque. A functional programming environment consists of types and values. Program evaluation (execution) involves reducing (altcring) expressions to the required flllal fonn where successive forms represent the same value. Since there are no assignable program states, evaluation does not alter the program execution environment and there are no .id e effect..
2.1.2 The ML Programming Language ML consists of a core language and a module. language (Harper, Milner and Tofte 88). Programs can be developed entirely within the core language or using both the core and the module languages. The module language is based on the core language, and consists of larger program structures as units containing core language constructs. The core language provides the basic types real, integer, boolean and string. The following data structure types are also available: tu pies, lists and labelled records, and any combination of these which maintains the type discpline. User-defined types, data types and abstract data types based on all the types described above can be defined and used like all the other types provided by the language. The other important prograrruning constructs are: if-thenelse, case, do, while, and, andalso, orelse (the logical connectives), exception handling, in fix flmction definition with selectable binding and change of infix status, recursive function definition, local functions and values within other functions and values, clausal function declarations , pattern matching, value and function declarations, imperative (reference) type variables and so on. There is a stream-based input-output facility with a well established I/O protocol. Functions in a program can take other functions as arguments and produce functions as results. The module language consists of .ignalttre., .tructure& and junctor., derived from the core language. Modules allow modular solution of a large software problem, and inheritance between module structures is possible. A structure is a collection of data types, types, values, exceptions and probably other structures. A signature specifies types and data types and gives the types of values and exceptions. A functor is essentially a function from structures to structures. Functors cannot take other functors as arguments and they cannot produce functors as results. The ML structures are analogous (roughly) to ADA packages, CLU clusters and so on.
ML is strongly-typed, statically type-checked and has a type inference system which supports polymorphism. This implies that ooe can define a function which operates urufonnly over a range of types. A good example of this type of polymorphism is the generic list length function which takes a list of any type and returns an integer. There is a relationship between inheritance and polymorphism, and ML's polymorphism can be used to provide some inheritance. ML is not a pure functional language. There are imperative type variables which can be ur--dated by assignment and input-output has side-effects, which are both features of non-applicative languages. Although one can write programs in a purely functional style, at some point it will become necessary to communicate with the outside world and side-effects will occur. The updatable variable types can be useful if operating in a databaoe environment where changes are continuously being made to data.
DL. Some prototype experiments of the work described in this paper were done using another functional language DL (Data Langauge), which has a database extension (Breuer 88) . DL has a set of data types and data structures (both user-extendable), though not as rich as in ML, and a dependency mechanism which maintains semantic consistency between data values in the database when changes occur (in a manner almost similar to the imperative types in ML) in the environment . It is strongly-typed and has a type-inference IlIcd.anism. There were two main problems encountercd in using this language. (1) There are no reserved words, few restrictions and the user can make 'any' programming constructs (subject to the type disclipline) . This proved very limiting since a pre-assigned set of inbuilt syntatic programming constructs is necessary to develop large applications at the top environment. (2) The language implementation has not yet been tested by many users so that any bugs may be revealed. Developing robust programs proved very painstaking and time consuming. ML was subsequently chosen because of its blend of experience and the fusion of useful features from other functional languages.
2.1.3 Example functional programs We give some examples of functional programs. The examples given here are coded in standard ML, although any other functional language could have been used to illustrate programming in a functional style. We start by defining a generic tool called reduce which can be adapted to different needs by supplying it with different types of arguments:
fun reduce f x [] = x reduce f x (a: :b) = f a (reduce f x b). Val declares new values and fun declares new functions. Reduce takes a function f, a value x of some type, and a list of elements (all of the same type) and returns a single result which has the same type as x. f takes a value of the same type as the list argument elements and a second argument of the same type as x (just the result type of reduce) and returns the result type of reduce . Its type is stated as: reduce :
('a -) 'b -) 'b) -) 'b -) 'a list -) 'b,
where 'a and 'b are type parameters and represent any type. Next define some functions which can be used as a first argument of reduce , fun plus a b = a+b fun times a b = a*b fun cons x (a : : b) = (x: : a : :b) fun insert (x:int, []) = x: : [] insert (x, y: : ys) = if x<= y then x: :y: :y5 else y: :insert(x,ys) .
Cons inserts an item at the head of a list of elements of the same type. The cons is a comnlOn list constructor in functional languages and it is so corrunonly used that in most languages it has an infix status and is usually given the symbol ' :' or ' ::'. For example 4::[8) = [4,8), and is the equivalent to cons 4 [8]. Insert takes an integer and an integer list and inserts the integer in its proper sorted place in the list. Now we can define the new functions sum, product (which add and multiply a list of numbers respectively), sort (which sorts a given integer list in its proper numeric order) and map which applies a function 9 to every element o f the list argume nt given to map . val sum = reduce plus 0 val product = reduce times 1 val sort = reduce insert [] ~un map g IS = reduce (cons 0 g)
IS
Notice the use of the function compostion operator 0 to define map. For any argument t of the right type, (con$ 0 g) t = cons(g(t», and this is essentially similar to the co de for that operator. fun (f
0
g) t
=~
(g t)
!'lap is a very useful function and can alternatively be defined as: fun map g [] I map g (a : :b) = a) :: map g b) and the two definitions have the same effect. In general reduce may be used to define many useful functions by defining different 'f ' $ and then chosing some appropriate x. Notice reduce is defined reclLr$ively and it works by pattern-matching on some of its argument . These two are important features of functional languages.
= []
«g
Functional languages have at least the same computational capahilities as othe r high I"vellangllagcs, hut they do have some extra attractive features . (1) They can take other functions as arguments of other functions and produce functions as results. We say that functions are first class values of the language just like booleans or integers since they can also be arguments or results just as the latter can be. This feature is not found in most high level languages. (2) They have powerful pattern matching capabilities, which helps in writing clearer and succinct code. (3) Most functional languages are strongly typed, incorporating a type-inference system which makes it much easier to develop programs rapidly. Generally these languages are function-based, elegant , have easily d efined semantics and are o f high e xpressive power which is also advantageous.
2.2 Databases Programming languages and databases have historically evolved along different lines, mainly because they were d e veloped for different purposes. Originally databases were developed for long term storage and manipulation( querying and updates) of data, and general purpose programming languages for complex computation. With time the need to have these two facilities in one environment., fo r example wh ere stored long t l'rm data is needed for high level computations not po ssible with databases, became necessary. In the early database systems and existing commercial database systems, special database sublanguages, were used to query and modify the database . The various ways these systems are accessed can be found in the literature (Pirotte and Lacroix 80, Atkinson and Buneman 87). R ecent attempts have been made to integrate databases and programming languages in one uniform environment, where the same language is used for general purpose progranuning as well as database access (Atkinson and Buneman 87) . The methods that have b een used to integrate the two are: (1) extending an existing language with the
:Eil
data types of an existing database system, (2) adding persistence to a new or existing language so that persistence is available to all the data types of the language, and (3) developing a new language based on a conceptual data model which also acts as a database model. The language used in the work described in this paper has an integral database which has been provided using the second method described above. It is the persistent ML available with PolyML (Matthews 88) . In the programming environment all the data types are endowed with persistence and not just some special types. There is a striking resemblance between the type declarations in a programming language and the type definitions of a data definition language for a database schema. A database can be modelled as a set of types and a set of operators which manipulate the types, and this is the kind of model proposed for relational databases fifteen years ago (Codd 70). The view taken here, therefore, is that if we have a persistent programming language, then a database can be constructed from the data types (and their instances) of a programming language and what one needs is a programming language with a generic type structure to allow the program to create his own representation of a data model, something which appears to be a major problem for most languages (Buneman 84). With this view, we can describe a database model for control engineering, by an appropriate choice of data model constructs.
3
DATABASE MODEL FOR CONTROL ENGINEERING
3.1 Overview Semantic and object-oriented data models support the structural abstraction mechanisms of classification, aggregation, generalization/specialization and composition, as well as procedural abstractions for database operations. The data model desc ribed here contains features from both semantic data modelling and object-oriented data modelling. It bears some resemblance to the functional data model (Shipman 81), but includes more semantic features. The main modelling construct in our data model is the object with unique identity and existence; this will represent some real-world entity, for example some plant or controller. All objects in the database will belong to some particular type, and there will be three varieties of objects: type, instance and function objects. Objects with unique identifiers provide better control of database integrity and raise the level of interaction between the users and the environment since objects form the currency of transactions. In contrast record-oriented data models would represent a design object as a set of records which are referred to in terms of their attributes values. The potential problems with regard to database integrity and the burden to its users are apparent. We shall make suitable structural and operational abstractions which capture important application semantics of control systems, and use suitable representations for these abstractions to show, by an example, how these can assist users in manipulating and modifying such a system. Most of the important abstractions have been achieved by the semantic hierarchical data model of Maciejowski (85), which organizes a dynamic system along the same concepts as control engineers usually think in terms of during design and analysis . This core data model is shown in Fig. 1. We shall identify suitable data type$ which correspond in some meaningful way to most of the structural aspects of the core model and then define suitable manipulation operators over these types. The data types chosen are based on the abstraction mechanisms stated above. The manipulation operators are just functions over these types. The generalization/$pecialilation abstraction is used to define
type hierarchies with inheritance semantics. Database updates and queries are also expressed through functions.
3.2 Control-theoretic types We discuss some examples of types identified as suitable for representing the core model. We can use the aggrega· tion abstraction to define a type port which describes an interface point of a dynamic system as a record consisting of the attributes: portJd, port_type and channels. The portjd is a unique name identifier for a port, porLtype is of type terminal where terminal can be Input or Output and channels is a list of channels associated with that port, this is applying a compo!ition abstraction. The channel type is also based on the aggreggation abstraction and is a record consisting of a signame stating the signal name, varname which is a name variable for the signal, units stating its units, and range..def which states the range of validity of the signal. Objects of these types can be created using suitable operators, this process called in!tantiation is the inverse of claHification. We shall have the type trfn which can either be a singleinput single-output (5150) tran!fer function consisting of a numerator and a denominator or a transfer function matrix which is a matrix of 5150 transfer functions to take care of the multivariable case. This is declared as : datatype trfn = null_trfn I Trfn of numden I TrfnJnlltrix of trfn matrix numden is a numerator-denominator pair type of real coefficients and null_trfn is a default value to be used in cases where the transfer function attribute is unknown or still has to Le computed from some other attributes. Trfn and Trfn..DIatrix are t.ype constructors which act as headers for instances of the type trfn. The type stsp consists of either four !tate spa ce matrice! (a, b, c, d), a state vector and a vector of initial conditions or a sta te space matrix ,a state vector and a vector of initial conditions. This is declared as: datatype stsp = null..stsp I Stsp of stsp-abcd - state_vector - real list I StspJnlltrix of stsp-abcd matrix - state_vector - real list stsp..abcd is just a 4-tuple of variable- matrix pairs. The variable is the name of the corresponding matrix. All such state space instances are initialised to the names ("a" ,"b", "c", "d" ) by default but the user can change these names using a suitable function. As another example the type defn consists of a tuple containing the types just explained above and the new types dfqn (differential equation) and structur (!tructure) (there is no restriction by the language on the length of name identifiers of types , functions and instances, but structure is a reserved word in ML). The structure attribute of !!fstem dermes the subsyst ems of the system and specifies how they are connected together. The connection is described by hookup which has been given a type of the same name. System is defined as a record type with the attributes shown in the core model of in Fig. 1. The mutual dependency of defn, structur and system types requires them to be declared together and this may done as follows: datatype system = null..system I System of {nameJd : string.class:class.connections : port list. defn:defn.properties:property list} and defn = null..defn I Oefn of (trfn - stsp - dfqn - structur) and structur = null..structur I Structur of (system list - hookup) In the above declaration. the data type system depends on defn. which depends on structur. while structur de-
352
pends on syste.. This dependency between these types also implies that functions defined over them will be dependent in the same manner. and this is so if we have a large hierarchical system containing other subsystems. Since we may need to have linear or non-linear systems or special systems for example IUmming junction •• plitter and combiner•• it is better to declare system as a parameleric type. Thus we can have: datatype 'a syste. = null~yste. I System of {nameJd : string,class:'a class. connections:port list.defn:'a defn.properties:'a property list} and ' a defn '" null..defn I Oefn of ('a trfn - 'a stsp - 'a dfqn - 'a structur) and'a structur • null~tructur I Structur of ('a syste. list - hooknp) and the type of system is reflected in its clau. definition and ,tructure attribute values. In this declaration the parameter '0. is a type parameter. It allows us to have different characteristic cia ... definition and .tructure attribute types with which we can derive different system subtypes. This also requires the types trln. 813p. dfqn and .tructur to be declared as parametric types. characteristic of the system subtypes intended. When system is declared as a parametric type we achieve the power of deriving different system subtypes by instantiating the type parameter to some specific type. This parameterisation ability is due to the polymorphi!m of the language. and can be used as a way of obtaining some inheritance and as mentioned earlier. In the example to be discussed we shall use the non-parametric system type definition.
3.3 Operations The basic initial operations are creating objects of some of the types described in the previous sub-section. In a purely abstract type system. this can only be done using functions which have to be defined for that purpose during the abstract types declaration. The abstract types enforce a strict discipline on the use of values of those types which is not the case with the data types. After creating various objects. functions can be implemented for creating new and possibly larger objects. obtaining value attributes of created objects. computing their behaviour or responses to some given conditions. connecting systems together in some specified way and so on. In addition objects may have function object components.
4 EXAMPLE The control system example discussed here is that by Astrom and Kreutzer (86), in Fig. 2 with the extra special subsystems. summer and the two splitters. These have been incuded explicitly to facilitate the unambiguous specification of interconnection points and their efficient manipulation by the the system operators which have been made available. We consider how the object reg(Regulator} is created. The following declarations are made: val reg.Jlame .. "Reg" val reg...class • Class [" linear" ,"time..invariant", "continuous_tia. It ] val reg..inportl " ref (Port{portJd .. "reg$pl".
channels=[Channel{units="",sigvar-"r", signame= ..... range..def"[]}J. port_type" Input}) val regJnport2 z ref (Port{portJd • "reg$p2". channels
z:
[Channel{units zsftll .aigvars"J",
lIigname ....... range..def.[]}J. port_type· Input}) val regJlutport .. ref(Port{portJd • "reg$p3". channels "[Channel{ un! tll"''''. sigvar="u". signame" ..... range..defz[]}] .port_type "output}) val reg...connectiona " [! reg..inportl. regJnport2. ! regJlutport]
val reg-stsp =(make-stsp( ([Ha" "b" J liCit J "d"],
ferent systems accorcling to the interconnections shown in Fig. 2. We first specify the systems we want to interconnect. this system list is needed in the interconnection algorithm: vu nevJSystemJ.ist = [ff().model().reg().summing_junctionl().proc(). sensor().splitterl().splitter2()] then the way we want to interconnect them. .,al nev..system..hookup "' Bookup [(! ff-inport,! splitterl-Outportl). ( ! 1110 de l-inpo rt • ! spli tterl.J)utport1) • ( ! reg-inportl • ! 1Il0del-Outport) • (! s1llllllling_junctionl-inportl.! ff.J)utport). (! s1llllllling_junctionl-inport2.! reg.J)utport) • (! proc-inport.! sUlllllling_junctionl-Outport) • (! spE tter2-inport.! proc.J)utport) • ( ! sensor-inport. ! spE tter2.J)utport2) • (! reg-inport2.! sensor.J)utport)l. and then state which ports we want to act as the external ports of the new connected system, .,al nev..system..connections co [! spE tterl-inport. ! spE thr2.J)utportl]. as well as naming any ports provicling negative feedback. n l neg~eedbaclt...ports = [! reg-inport2] . Thereafter we can use the function systelll..lll.,connect which is implemented entirely within the language to interconnect the systems together by the function application: fun nevJSystem() lIl.,connect nev..systemJ.ist nev..systelll..hookup nevJSystem..connections neg~eedback_ports "nev..JIystelll" where "new..system" is the name of the new system. This will perform all the necessary computations. finally returning a new system with attributes derived from the component systems. We can query for properties or any attributes as we did with model.
j
[[[0 . 0,0.0],[0 . 0, 18.6]], [[0 . 18868, 0.18868],[0.0,18.6]]. [[1 . 0.3.72]]. [[1. 0.4 . 72]]]). [], []» val reg_trfn=ref(stsp2trfn«! regJStsp).1 . 0» fun reg~efn()=Defn«! reg_trfn).(! regJStsp). null~fqn, nullJStructur) val reg_properties = ref null-prop fun regO = ma1teJSystem(reg..name,reg..class. reg_connections, (reg~efnO) ([[0.0,0.0),[0.0, 18.6)) is a 2x2 matrix) . The value of objects declared as reference types (using rei) may be changed at a later time, and because of declaring them as mutable values, any change is reflected in all other objects using those objects in the database. RegJbp is created through the makeJt3p function which checks the necessary contraints. The system object reg is created by the makeJY3tem function which also checks all the required contraints. The reg_defn and reg objects have been declared as nilary argument functions so that any changes which occur in their components (say if we change reg_trfn to some new value by an update) at a later time are reflected in them if we subsequently demand them or use them. Initially reg_trjn is unkown, but there is a function 3t3p2trjn which when applied to a state space value returns its transfer function form. It works by calling PRO-MATLAB (MoleI' and Little 87) to make the appropriate transformation. The other systems in Fig. 2 are declared in a manner similar to reg above.
=
We can now demand for example the impulse reponse of model IIsillg t.he fllnd.ion system_impulse by the application: system-impulse (model(» [] and we get back a vector of response values and their corresponding time vector which in this case is the default time vector [0:1:50], but if this is inappropriate we could provide the one we wish as the last argument above instead of O. We can ask for a plot of this response or store it away in the properties attribute of the system model by model_properties : = insert-property (reg(» (make_trajectory ("impulse", 1111) ("time", "secs") (systeBLimpulse (model(» []». Malte_trajectory takes the name of the property (impulse in this case) and its units, the name of the independent variable (time) and its units (seconds), their values and then creates a property attribute of system. This is then used by the insert-property function to store it in the system model. There is also malte_property which deals with those properties that do not need to include an independent variable for example , stability.
As a final example we may want the behaviour of a system for a range of parameters values, for example the dynamics of Regulator depends on k, Ti. Td and N and this is reflected in its A. B, C. D matrices. We can have a parameterised Regulator function which takes k. Ti, Td and N and returns a state space value for particular values of these parameters. We can do this by. fun malteJ'eg..stsp Ti Td • k ~ let Tal ITd z I/Td .,al kl - ItJ .,al ITi c 1 . 0/Ti val a • [[0 . 0 0 . 0].[0 . 0 ITd]] .,al b • [[ITi ITi].[O . O ITd]] .,al c [[k. kl]] YBl d [[It. (k+ItJ)]] in malte..stsp«["' ..... B... "e" ."D"] .[a.b.c.d]).[] .[]) end. We can then say keep Ti and N fixed and obtain reg..stsp for values of k say in the range (1 - 10) which can be done by: val reg..JItspJ
Similarly we could generate a frequency list w, and then ask for the frequency response of the system model by: val model_bode = system_bode (model(» v and we get back a response vector whi ch we can plot or store away in model by the request : model_properties := insert_property (model(» (malte_trajectory ( " bode".'''') ("frequency". "Hz") modelJ>ode) and asking for the modeLproperties should now return both the time response created earlier, without recomputation, and the new frequency response. In general we can demand any control system design utilities available in the control system tools of PRO-MATLAB , though the data goes tlu'ough major transformations to reorganise it into the data struc tures used here . The int erface between ML and PHO-MATLAB is essentially sill1ilar to the one used used in parallel work involving PRO LOG, described elsewhere in these pro ceeclings (Tan and Maciejowski 89) .
=
As a more interesting example let us interconnect the c1if-
35 3
5
CONCLUSIONS
The use of a functional language for implementing the applications described here has been very convenient for the following reasons. Firstly, the usage of functions as described here very much resembles the mathematical concept of a function and even in control applications, resembles the way in which control theory problems are formulated. Secondly, in a functional language a user specifies what to do, the details of how to do something being abstracted away. Thirdly, all objects are first class values of the language, and this implies that any object including other functions can be an argument and a result of a function . This means that all values within the environment are treated uniformly and the user can interact with higher level objects directly. Consequently, the resulting programs are more compact and easily readable. The .trong typing regime combined with .tatic type checking results in a program development environment where a user cannot write type-incorrect programs. The set of types and the provision of facilities for definition of userdefined types and functions over them has proven to be a very versatile set of data structuring tools for the design environment. Not all these tools have been fully exploited yet and future work wiU involve full polymorphic use of the abstract types and modules. Although the language is fully statically type checked, we think that a certain amount of dynamic type checking, available when necessary would be very useful. This would make it easier to support dynamic schema modification, something which is very difficult to achieve in the present circumstances. Other issues not yet resolved, but are for future consideration are: support for dynamic schema modificat.ion, design history management, provision of design object views, versioll control , and transaction control. We believe that fWlctiollal languages will prove to be strong candidates for the implementation of software tools for future CACSD systems.
6
Lorie, R . and Plouffe, W. (1983). Complex Objects and their use in design transactions, Proceeding. of the Databau week, SICMOD, A CM, pp. 115-121. Maci ej ow ski , J . M. (1985). A core data model for computer-aided control engineering, Cambridge Univer-
sity Engineering Department, Technical Report CUED/FCAMS/TR257 (1985), Cambridge University England. M aciejow ski , J. M. (1988) . Data structures and software tools for the computer aided design of control systems: a survey. ,4th IFA C Symposium on CA CSD, Beijing, China, pp27-38. Matthews, D. C . J . (1988). A Persistent Storage System for Poly and ML. In Technical Report No . 161, Computer Laboratory, University of Cambridge, England, 1989. Moler, C . and Little, J. (1987). PRO-MATLAB Users Guide. The Mathworks Inc. , Sherborn, M. A. 01770, USA. OODBS 1986. 1986 International Workshop on ObjectOriented Databue Sy.tems. Pacific Groove, CA, USA. Pirotte, A. and Lacroix, M . (1980). User interfaces for database application programming. In Infotech State of the A rt Conference on Database • . Info tech , London England. Rimvall, C . M. (1986).Man-Machine Interfaces and Implementational Issues in Computer-Aided Control System Design. PhD Dissertation, Swiss Federal Institute of Technology, Zurich (ETH No. 8200). Shipman, D. (1981). The Functional data model and data language Daplex. A CM TranMctions on Database systems, Vol. 6 No. 1, pp. 140-173. Stonebraker, M., Rubenstein, R. and Guttman, A. (1983) . Application of abstract data types and abstract indices to CAD Data Bases. Proceedings oJ the Da tabase Week, SICMOD, A CM, New York, pp. 107-113. Tan, C. Y. and Maciejowski, J. M . (1989). A Prolog programming based CASCSD Environment. Proceeding. of the IFAC World Congre .. , August 1990, Tallinn, USSR, submitted.
ACKNOWLEDGEMENTS
The authors ' research is supported by the Science and Engineering Research Council, grants G RI 0/17830 and GR/D/60782, and Shell International limited through the Cambridge Commonwealth Trust.
7
REFERENCES
Astrom, 1<. J. and Kreutzer, W.(198G). System representation, Proceeding. of the IEEE Control Sy.tem. Society Third Sympo.ium on CA CSD, Arlington , Virginia, VA, USA . Atkinson, M. P . and Buneman, O. P. (1987) . Types and Persistence in Database Programming Languages. A CM Computing Survey., Vol. 19, No. 2, pp. 105-190. Breuer, P . T. (1988). A Data Language - DL. Cam-
bridge University Engineering Department, Technical Report CUED/F-INFENC/TRI6 (1988). Cambridge University, England. BUllcmall, O. P. (1981) Can we reconcile pmgrnrnming languages and databases? III "Databau.: Role and Structure ", Cambridge University Press, Cambridge, England. Codd, E. F . (1970). A Relational Model for large shared databanks. Communication. of the A CM, Vol. 13, No . 6, pp. 377-387. Darlington, J., Henderson, P., Turner, D. (1980). Functional programming and it. applications. An advanced course. Cambridge University Press. Harper, R., Milner, R. and Tofte, M. (1988). The definition of Standard ML Ver.ion 2. LFCS, Department of Computer Science, Uni\'ersity of Edingurgh, Scotland. Hull, R. and King, R. (1987). Semantic Data Modelling: Survey, Applications , and Research Issues. A CM Computing Survey., Vol. 19 No. 3, pp. 201-260.
Fig.1. The Core Data Model.
pl····· .. --~···- .. ···· .. ··y········· .. ···· .. ··· ..··· .. ····· ........ . !:::.
FF
pT· .... ·· .... _··_-_ .. ·· .. ··· .... ·· ........yl
u:
·· :
...............................................
:. ....................................................................... Fig. 2. Example control system.