UNIVERSITY OF EDINBURGH DEPARTMENT OF CHEMICAL ENGINEERING NIVER
S
IT
TH E
U
H
Y R
G
O F E
D I U N B
Technical Report 1994-19
epee: A Support Environment for Process Engineering Software D. J. Costello, E. S. Fraga, N. Skilling, G. H. Ballinger, R. Ba~nares-Alcantara, J. Krabbe, D. M. Laing, R. C. M Kinnel, J. W. Ponton, and M. W. Spenceley c
26th September Enquiries should be addressed to : Eric S Fraga, Department of Chemical Engineering Edinburgh University, The Kings Buildings, May eld Road, Edinburgh EH9 3JL Scotland
Tel: +44 131 650 8565 E-Mail:
[email protected] Fax: +44 131 650 6551
Abstract
This paper describes epee, a distributed environment for the integration of software applications. It was developed with the aim of aiding the process of design by providing the necessary support for a design information management system. The software environment is rst described in general terms and then our speci c application of epee to process engineering design is presented. epee uses an object-oriented approach to data management. Data are represented as objects whose de nitions, via templates, re ect the process engineering design environment. The use of focussed methods promotes a consistent look and feel to the tools in the environment. Method reuse reduces software development costs and increases users' con dence in the reliability of the methods. The bene ts of the history recording mechanism in epee and its object publishing facilities are described. A history record is a critical component of a high level design management system. This, together with the sharing of data through object publishing, provides the necessary support for collaborative design. The application of epee to process engineering design illustrates the bene ts of object-oriented techniques to the process systems and design community. The inherent extensibility of object de nitions facilitates the application of the support system to any area of design. The dynamic nature of object de nitions in epee encourages exploration and experimentation with new data types and methods.
1
1 Introduction The complexity of process engineering, such as research, design, operations, and retro t projects, demands the ecient organisation of the data and tools. The data must be organised in logical units that re ect their meaning and intended use. Software tools which process data must be able to communicate with each other and a user's access to these tools should be through a common interface. Together, these features de ne an accessible and e ective environment for process engineering. epee is an example of such an environment (Ballinger et al., 1994a; Ballinger et al., 1994b; Fraga et al., 1994). It has been designed to support the large-scale organisation, manipulation, and retrieval of process engineering data. epee is a generic system for application integration, independent of the working domain. Through careful de nitions of data types as objects and the construction of focussed methods to manipulate these objects, an environment for process engineering has been developed. There are many potential bene ts from such a system for new, current, and future users. Users bene t from the consistent behaviour and look of the system minimising the frustration and time spent in learning the mechanical aspects of the applications (programs) used. By using and developing focussed applications for speci c object types, users and programmers alike bene t by an increase in application reusability. The guidelines provided by the organisation of the data provide reassurance to the programmer that only the speci ed object type is used. This allows applications to grow and develop with the objects, or to remain operational even as the object de nitions evolve and change. The use of objects protects users from having to be aware of di erences in diverse applications that perform the same function. The only restriction a user need be aware of in using an application is that it must be given an object of a certain type and that it will return a new object. Finally, future users bene t because the consistency imposed upon the project allows history maintenance and retrieval mechanisms to be incorporated. Users may then take advantage of the information obtained from an old project in new project developments. This paper gives an overview of the epee system and its use as a process engineering design environment. It demonstrates the potential bene ts that epee can have for users. A companion paper (Fraga et al., 1994) is available which gives an indepth description and discussion of the implementation issues involved in the development of epee. Another paper (Ballinger et al., 1994b) analyses the issues that arise in developing environments for creative design.
2
2 A General Description of the epee System epee is a software system whose development was motivated by a need for ap-
plication integration. It uses an architecture and application independent object format to achieve an integrated environment. The use of object oriented techniques enables users to tailor the system as their needs demand. To enable the use of existing applications it was necessary to design a dynamic object oriented system. For this reason, some of the notation used to describe the implementation di ers from standard object oriented terminology. In the section that follows, new terms are emphasised and their relation to standard terms are described.
2.1 epee Objects and their De nition An epee object is a collection of slots. A slot is the most basic item in the epee system. Each slot has a name, a data value, and some peripheral information. The data value can be an integer, a real, a string, or a reference to an epee object. A data value can also be a collection (set or array) of any of these basic types. The peripheral information describes when, how, and by whom the data value was set or changed. The de nitions of slots includes information on the type of data accepted, the units, and valid ranges. For example, the temperature slot is de ned to contain a non-negative real number of unit degrees Kelvin. A template is a named set of slots, identifying a particular collection of slots that has a physical or conceptual meaning described by the name. For example, templates in process engineering would include component, stream, and process. A template is an object de nition but it is not a class de nition in the true object oriented sense: methods are not included in the object de nition. By de ning new templates from existing ones, through the use of inheritance, a template hierarchy is implicitly de ned. An object is not necessarily the instantiation of a particular template but can be any collection of slots. The type of an epee object is inferred dynamically at run-time by matching the slots it contains against de ned templates. In this way epee di ers from a static class based language such as C++ where objects can only ever have one type which is decided at the compile stage. epee is a domain independent system and the slot and object de nitions for one particular domain can be replaced by another without a ecting how epee works. Our particular interest has been in integrating process engineering applications. To this end, a process engineering speci c template hierarchy has been created and a part of this hierarchy is shown in Figure 1. The templates have been de ned to represent those objects familiar to process engineers. 3
Fig. 1
EPEE_GENERIC_OBJECT
Component
Mixture
Block
Network
Process_Block
Process_Network
Process_Block.Distillation_Unit
Figure 1:
EPEE_DESIGN_OBJECT
Stream
Process_Block.Reaction_Unit
A small part of the process engineering template hierarchy.
An object is said to match a particular template if it contains at least the slots named in the template. This least matching mechanism allows arbitrary objects to be constructed which can still match speci c templates. Prede ned templates are necessary as they are the conceptual units of information on which operations or methods are de ned. Through the use of templates, we have de ned an extensible object system. This is necessary for the integration of existing applications into the environment and to enable the incorporation of new applications. Objects can be extended dynamically for a new method by the addition of slots. This encourages testing of and experimentation with new methods before de ning and naming new templates. epee objects are stored in the user's scratch database, which is a temporary working area which can be periodically purged. Objects from a scratch database can be published in external databases so that results of work can be shared with other users. A detailed description of database handling is given in (Fraga et al., 1994).
2.2 Operations on Objects { Methods A method is a function that takes an object as input and which may return one or more objects as the result. Methods are provided by application programs; each program may provide several di erent methods. Methods are written for epee using the Application Programmers Interface (API)(Krabbe et al., 1994). This presents an event-driven programming model for providing methods and for manipulating objects, usable from a variety of programming languages. It provides access to the objects, their slots, the de nitions 4
of both templates and slots, and the ability to apply methods to objects. To incorporate a pre-existing application (for example, physical properties packages) into epee, a wrapper which uses the API must be written which encapsulates the existing program and which provides access to the individual methods of the application. As epee views applications as a collection of methods, it encourages the development of small tightly focussed applications which provide just one method. This encourages the re-use of software components and the development of consistent use interfaces. The creation of huge and monolithic applications is avoided, enabling the development of more adaptable tools. There is also the possibility of synergy developing through the use of many small tools. Object manipulation and the application of methods can also be achieved through graphical user interface tools. For example, the Object Browser (see Section 3.6.1) provides a generic graphical interface to a set of objects. The user may apply methods to selected objects and may view the relationships between objects. A history of method execution is kept. This history records the method invoked and the object used (all objects have globally unique identi ers). Also recorded are the parameter settings used by the method, the object (or objects) returned as a result, and the intermediate objects created during the invocation of the method. The recording of history is necessary so that when objects are published, all direct ancestors of that object can also be published. This is necessary so that the context of the published object can be understood. The history of an object is actually recorded by including history links in the actual objects, and does not require the use of any external data structure (Fraga et al., 1994). The de nition of objects through the use of templates, the incorporation and integration of applications and methods, and the capability of publishing objects with full history information do not in themselves constitute a full information management system. These features do, however, provide the basic foundations on which such a system can be built.
3 epee as a Process Engineering Design Environment The epee environment provides the basic requirements for a general interactive environment for manipulating data. With the development of suitable object templates and methods, an environment suitable for process engineering design can be created. Originally, the idea of epee arose out of the desire to bring together all the programming tools that were used in our research. Application integration, and the encapsulation of the data used by the applications, was the primary reason 5
for developing the application neutral object system. In this section we describe the process design environment implementation of epee as a speci c example of creating an epee environment. In the previous section epee templates were described as the language of the epee system. De nition of objects based on templates are the corner stone upon which a speci c epee environment is built. The choice of epee object de nitions is a dicult and complex task. Incorrectly choosing the core de nitions for an environment can make the whole task of writing methods and applications, and de ning more complex objects, dicult. Within the de nition of the objects the context and the scope (or space) in which the user can work is de ned. It is also true, however, that there is no unique set of object de nitions that are absolutely correct. It is just that one approach may make what you do more easy than another. Below we describe the approach that we have taken, discussing some of the issues that arise in the context of speci c process engineering applications.
3.1 epee Object De nitions for Process Design For the process engineering design environment, we followed the usual object oriented design philosophy of de ning object types in the context of the environment we were trying to represent. Hence for a chemical process engineering environment the rst three de nitions we created were the Component, the Stream, and the Process. In fact, an early prototype implementation of the epee system (Skilling et al., 1992) had de ned only these three types of objects. Using that early system, and recognising the limitations of xed object de nitions, led us to develop extensible objects and the template hierarchy (see Section 2.1). The template that another template inherits determines its classi cation and use within the epee environment as can be seen by the partial description of the template hierarchy in Figure 1. The old object de nitions (component, stream, and process) are still there, but the context in which they are used is now better described by their inheritance hierarchy. For instance, Stream and Component objects are EGO (epee Generic Object) objects, while the process object de nition has now been subsumed into the grouping of templates which inherit the EDO (epee Design Object) template. As previously mentioned (Section 2.1) the sole factor determining what an object is, is the slots that it contains. For instance, a Stream in epee is de ned as a owing mixture and therefore contains references to two other objects: a Flow and a Mixture. A Mixture, in turn, is de ned to be the list of Component Fractions along with temperature, pressure, and phase data; and a Component object has a name, an identifying tag (in our case the PPDS number (National Engineering Laboratory, 1982.)), and fundamental physical properties. All of these objects inherit the slots of an EGO object (which is only one slot, a string designating the 6
name of the object) and so can only be used in that context. More interesting are the process related object types, which are a subclass of the epee Design Object (EDO), which is itself an EGO object. An EDO is an EGO with a Purpose slot: string slot which records the reason for the existence of the object in question. These groups of object de nitions make extensive use of the inheritance properties available within epee to deal with the process design problem of the representation of process owsheets and unit operations. To illustrate this, the following sections describe how EDO objects have been de ned and used to represent the topological information of design: the problem of representing process networks.
3.1.1 Objects for Spatial Representation The description of the template hierarchy given in Figure 1 describes some of the relationships between the key object de nitions required for the representation of design objects within a owsheet. The two key branches of the template hierarchy are the Block templates and the Process Network templates. Physically, a Block can be considered to represent an abstract unit operation, while a Process Network object represents a process plant (a connected set of Blocks). A Block is a place holder that contains Ports onto which the outside world can connect. A Port is an object which speci es the intended purpose of the connection to the outside world. The Block does not have any slots for describing its contents as this is lled in by subclassed object de nitions. One such subclass is the Process Block. A Process Block object is a Block with one extra piece of information: the Cost of the process. The Process Block inherits the slots of a Block, and so it inherits a Block. Further subclassing has also been done with the Process Block.Distillation Unit object inheriting the Process Block. This template contains information speci c to distillation units, such as the number of stages and the re ux rate. The advantage of this inheritance is that any application using a Block object can use a Process Block or a Process Block.Distillation Unit object, giving added exibility to applications built to work with Block objects. The other branch of the template tree below EDO starts with the Network objects. The Process Network objects allow a user to view and represent processes involving control structures or energy networks as well as the usual process ow networks. The contents of a Process Network are similar to those of a Process Block in that both contain a list of ports and inherit an EDO object. However, a Process Network object also contains slots that list the Blocks that the network contains and the connections between these Blocks, this information being the minimum necessary to describe the topology of the network. The connections between Blocks are themselves objects. A Connection object consists of a From slot 7
and a To slot which describe which Ports are connected. There is also a Carries slot which describes the process engineering entity (for example, a Stream object) which is actually responsible for the connection. To represent a simple distillation unit with one feed and a top and bottoms product both the Process Network and Process Block objects are used as shown in Figure 2. The Process Block representing the actual distillation unit contains only information pertaining to the structure of the unit and what is within the unit. It has no information about what is outside it or, in fact, what is connected to it. The Process Network object keeps track of connection information. In the case of our distillation process, each Connection object has associated with it the stream it carries. As is shown in the next section this form of design representation is very useful for spatially or topologically focussed representations of the design process. InputConnection Process_Block Process_Network
Output1Connection
Output1Port InputPort Output2Port Output2Connection
FeedPort
TopsPort BottomsPort
Figure 2:
Graphical view of a Process Network template structure for a distillation column with one feed and a top and bottoms product
3.1.2 Synthesis and Decomposition of Process Flowsheets Given the epee Design Object representations discussed in the previous section it becomes very easy to perform tasks associated with the manipulation of the parts of a owsheet. As an example consider the problem of combining two process
owsheets into one bigger process owsheet. Having identi ed the common stream between the owsheets, building a new process owsheet is simply a matter of 8
Fig. 2
creating a new Process Network object where the list of Blocks and Connections are each the union of the old Process Networks, and the list of Ports are the same minus the two which have been used to connect the old processes. Figure 3 shows what happens when we connect two distillation units of the type described in Figure 2. The procedure is straightforward; and demonstrates just how useful this representation of process owsheets is for this type of application.
Figure 3:
Combining two Process Network objects into one.
An important point to consider in this example is that the method which is used to combine the two Process Networks into one does not need to know anything about the actual Process Blocks in the network. Therefore any pair of networks, regardless of detail, can use this method. In fact, one network may be fully speci ed while another may only exist at a very sketchy level of detail. The inverse operation to synthesis, decomposition, is just as easy to perform using the network structure de ned here. Together with the synthesis method, the basic 9
Fig. 3
methods for breaking down a large network into constituent pieces, working and re ning each piece, and then combining them to produce a more re ned overall network is possible. It is assumed, of course, that the synthesis method is careful about which networks it combines but, if necessary, the information it needs to check for consistency and feasibility exists within the Connection objects contained within the Process Network object.
3.1.3 Simulation The process network approach for representing a process owsheet described above is di erent from many of the representations used in other process engineering applications. Connection information is not contained in a Process Block but must instead be obtained from the Process Network surrounding it. Consider, for example, a method for simulating a distillation unit. In order to nd out what streams are coming into a unit and what is expected to come out of the unit, the method must work with the Process Network object and not the Process Block.Distillation Unit object, as might have been expected. This approach makes simulation and design calculations a more complex task than necessary. The epee system, through the extensibility of epee object de nitions, gives us a way of solving this problem by allowing us to de ne our own design or simulation object types. This has already been done for distillation design problems through the de nition of the Process Design object, which contains an Input Streams slot, an Output Streams slot, and a Stream Label slot (to denote the purpose of each Stream). It is then a much simpler task to write application programs to do design calculations on these objects than on the lower level Process Network objects. De ning equivalent objects for di erent operating domains allows us to maximise the potential of our process design environment. It is also then feasible to consider developing applications to convert from one object representation to another. Current developments in the epee system are geared towards the development and automatic invocation of such methods when required. We envision that a user interface, a more intelligent Object Browser (see Section 3.6.1), automatically calling the conversion method if the user invokes a method requiring an object of a certain type but has selected an object of another (but necessarily equivalent) type. However, it is our contention that before such procedures exist, the underlying framework must be well de ned and completely general, enabling the creation of ecient higher level environments as required.
3.2 epee Applications in a Design Environment Object-oriented environments, like epee, are focussed on the de nition of the objects, or more simply, the organisation of the data. This is unlike traditional 10
programming languages such as FORTRAN77 where the data are manipulated and organised to t the de ned solution routine. In the traditional approach, many di erent variations of a general problem could be solved by one algorithm, for example, the solution of sets of algebraic equations. The problem with this approach is that for each problem description the data has to be manipulated into the format required for the solution algorithm. This approach tends to produce very large programs that operate on a wide variety of problems. However, their size often leads to long development times, and diculties in debugging, maintaining, and modifying these programs. By organising the problem around the data, the focus of development, maintenance, and modi cation changes. The object de nitions, in general, remain the same and it is the programs (methods and applications) that are created for each particular type of object, usually to do a particular job. This approach keeps each method small and concise so that the development and any subsequent modi cation to a particular program is quicker and easier. The best example of this is the set of editors (in Section 3.6.3) that have been developed for our process engineering object de nitions. The discipline of enforcing the type of objects that can be received by a method and produced by a method instills in the programmer and user a greater level of con dence in the software. The ability to add slots to an object to create a new object provides exibility in the methods that can be applied to that object. Any method that works on a parent (or object higher up in the tree) will also work on the child. Of course none of the information contained in the child's slots could be directly used by the `parent' method; only slots from the parent would typically be operated on. This has a couple of bene cial side e ects for the epee user/programmer. Firstly, if only parent information is required then the parent method can be used - there is no need to write a new method to access the same information as the old method - even though a child object is di erent from a parent object. Secondly, if the method that operates on the new type of object requires some changes from the parent method then the programmer has the option of building upon the old method to handle the additional slots of the child object.
3.3 History Recording in epee When a method creates new objects, epee creates links between the object (or objects) just created and the object (or objects) from which they were created. This is the history recording feature of the epee system. The history that epee records lies at two levels. Firstly, epee maintains a very brief record of an object { information explicitly contained within the object that 11
de nes its existence. This information includes the object identi cation number for its parent, and its own unique identi cation number. The method used in creating the object, and its time of creation are also documented. In our process engineering environment, access to this information is through the object viewers and is displayed in its own window when required. An example of this history information is given in Figure 4.
Fig. 4
Figure 4:
Information about a Stream object created from the method Edit.Stream
Apart from the creation information, this data is analogous to the system information of program les available on any number of computer operating systems. Following this analogy it is then possible (and in many cases desirable) to use this information and treat epee objects in the same way as les on an operating system; that is, by separating them into di erent directories, accessing (viewing) speci c groupings of les, and basically organising them to the user's best advantage. This aspect of the epee system is discussed further in Section 3.4. An epee object with history and creation information can do much more for the user than the ` lesystem' type information described above. It becomes possible to trace and display all the objects that were used in and are related to the creation of one nal object. An example of this is given in Figure 5 where the history of the Stream `Hydrocarbon' is shown. All the objects directly associated with that object are displayed (some other epee objects have been hidden for clarity). The links from the EmptyStream object show that it is the parent of the Hydrocarbon Stream, the OrganicMixture, and the StreamFlow objects. The Component objects (N-Pentylamine, Pentan-1-ol, and Pentan-2-ol) are shown without links as they were created separately from the other objects. They are displayed, however, because they are contained in the Hydrocarbon object and so are of direct relevance to that object. Fig. 5 The implications of project history recording are considerable. It is now possible 12
Figure 5:
The history of the Hydrocarbon Stream object.
to see the complete history of a design project. Along with horizontal object management, branches of the history tree can be selectively pruned to obtain the key nodes of the designed process. This allows users access to the key information in a design project, enabling the quick and ecient dissemination of a project's results. Full details of the implementation of the history mechanism can be found elsewhere (Fraga et al., 1994). History recording has other, not so obvious, bene ts to the users of an epee system. Alternative designs, components, and applications can be tested. Even with a rudimentary history viewing mechanism it is possible to view these alternatives, choose the best, and then continue with the design. As each design object in the epee system inherits the epee Design Object (which contains a Purpose slot - a slot to record the intention, purpose, and/or objectives of building that object) it becomes possible to use this information retrospectively to evaluate the nal design against the original project speci cations, or evaluate the parts of the design done by particular users. Using such an approach can be a positive force in: getting designers to learn from their mistakes so that they are not made again; justifying the nal design based on the record of intent given in the project history; and using the nal design as a template for similar projects in the future. It is now within the scope of epee to implement the features just described. The information needed is recorded in each epee object, and the ecacy of the approach has been demonstrated with the simple object history viewing facilities 13
available with the Object Browser (see Section 3.6.1). However, the higher-level maintenance of project history information, and its selective viewing are really the domain of the third party design project applications, such as KBDS (Ba~naresAlcantara et al., 1994), which is already partially integrated with the epee system.
3.4 Support for Cooperative Design As part of history maintenance and proper management of a large project, consideration has to be given to organising the information generated throughout the life of that project and to provide mechanisms for sharing of information amongst the members of a team. In a large software project, for example, all the les that make up that project are generally organised into di erent directories (`src' for source code, `bin' for executables, `doc' for documentation, and so on). Similarly for large design projects: the reaction section might be done in one oce, the separation section in another, and safety and environmental sections in yet another. epee, through its database management facilities, allows the project manager to designate such divisions within a project, yet still maintain the integrity of the whole project. Di erent people or groups can each be given a particular part of a project, and be able to work on it independently of the other project sections. Each team member, however, can access other people's work through the facilities provided by epee. The work of a particular group or person is stored in their scratch database { a le that contains all the objects that the user has created since the last time the scratch database was emptied. Once a satisfactory answer to their design problem has been obtained, an object can be published by applying the Database.Publish method to that object. This then saves that object, its contents, and all history information (the object's ancestors and a record of the methods used) to a new or pre-existing user-speci ed database. That object is then said to have been published, and anyone (given le access permission to the object database) can access and use that object within epee. Using published objects will, of course, not a ect the original object: only a link to the original will be created through the `parent ID' in the new object. This ability to access published databases is not restricted to those people working on one particular computer. Its only restriction lies at the level of the distributed computing environment that is utilised. We currently operate epee in a UNIX environment, and successfully access databases from a wide variety of system architectures and login accounts spread around the university and can technically access any epee database in the world so long as it is accessible through the Internet. The exibility, provided by epee, of access to distributed information is not a 14
common feature of design environments. While crucial to the management of large design projects, higher level organisation facilities are required for their complete life cycle management. We aim to incorporate this level of management through the integration of design management software such as KBDS (Ba~nares-Alcantara et al., 1994) into the epee system.
3.5 Developing Methods in the epee Design Environment To write a method for epee requires the Application Programmer's Interface (API), a library which provides the functionality to connect a method to epee, to get the data from the slots of the object, and to parcel up the results into new epee objects. Applications are written using a client-server approach. This means that when the application is started up by the server for the rst time the server must be told of all the methods that the application (the client) provides. The server will then call on the application to execute a given method when requested by other applications or by the user directly. Consider, for example, an application to do a series of design calculations on a Stream object. Each separate manipulation might normally be considered as a separate epee method, with the application being the method provider for `Calculate.Design.Stream'. In the epee method database each method would then be separately listed, giving the provider of the method (the application), the required input (a Stream object), and a one line description. In the method provider database the location of the executable code, environment variables, and author would be listed. When a method is invoked from within epee, the server looks through the method database until it nds the appropriate method, nds the application associated with that method, starts up the application (if not already running or busy), and requests the particular method. Methods can also be integrated into epee through third party software. Usually such software has been written to provide a large number of tasks and features to the user. Examples of this are Aspen Plus (Aspen Technology, Incorporated, 1990) and PPDS (National Engineering Laboratory, 1982.). Aspen is capable of doing many di erent sorts of design calculations and steady-state simulations for di erent process systems, and PPDS is capable of determining a wide range of physical properties for components and mixtures. This grouped functionality does not lie well with the epee philosophy of focussed functionality of methods { methods doing a single operation on a particular object. However it has been possible to incorporate these large programs by considering them as applications providing a suite of methods to the epee user. A software wrapper is used to act as an interface between epee and the application. The wrapper interprets the requests for action from epee, translating objects into the particular syntax of the 15
third party program, running the application to do the required task, and nally reparsing the results into epee objects. At present our most successful integration has been with the PPDS physical property code. We now have a whole suite of physical property methods that work on Components and Mixture objects. There has also been some limited integration of Aspen and the dynamic simulator Speedup (Perkins and Sargent, 1982) and this is continuing as our needs for simulation methods grow and our experience in integrating third party applications increases.
3.6 Support Tools A design environment requires access to a variety of tools for managing and manipulating data. This section describes a set of core applications which form part of the epee design environment. This set of tools provides the functionality necessary for viewing and editing objects, selecting and applying methods to objects, and for browsing the object databases.
3.6.1 Browsing epee Databases - the Object Browser The Object Browser is the main user interaction tool for working in the epee system. The Object Browser can be viewed as a high level management tool for epee objects providing the following capabilities to:
Show historical dependencies amongst a set of objects (see Figure 5); Select and view the contents or structure of an object (see Figure 6); Access and view published objects from di erent databases, and; Provide access to all other methods in the epee system such as the editors, database management tools, and simulation tools.
The Object Browser is itself a method that can be applied to an object, or a database of objects. Most of the time it is used to view the user's own scratch database (the collection of all the objects that the user has been working with). If desired it is possible to constrain the view to particular types of objects. This is a useful facility, as most methods create many objects not directly relevant to the nal answer, and not being able to hide these `secondary' objects would make working with objects unmanageable. In the current version of the Object Browser this facility is fairly coarse: it is only possible to hide complete groups of types of objects (for instance, Mixture objects), or individual selections of objects. While 16
this currently matches our requirements, in the future this selection facility will be made more intelligent, enabling selections of objects to be viewed based upon their name (which may be a project name), and/or the user or method that created them.
Fig. 6
Figure 6:
The Structure and Contents views of the Hydrocarbon Stream object from the Object Browser Application.
The other major purpose of the Object Browser is to act as a central application for applying methods to objects. Applying methods to objects in the Object Browser is simply a matter of selecting the objects and then calling up the requested method through the Select.Method method interface (which is discussed in more detail in the following section).
3.6.2 The Method Selector The naming of methods in epee follows a strict hierarchical format with the aim of providing as much information about the method as possible. The structured name of the method also allows a selection procedure by which methods are subdivided up according to their name. The method, Select.Method, takes the user through the di erent naming levels of a method to select the method required. An example of this would be to get the method `Physical Property.Constant.All' to operate on a Component object. Using Select.Method the user would rst select the `Physical Property' level, then the `Constant' level, and nally selecting `All' would return the full method name. Figure 7 shows how to select a particular method. Note that in this example each window represents a separate method invocation, done to illustrate the method hierarchy at each level. Normally, a user would move through the di erent method levels using only one window. 17
Fig. 7
Figure 7:
An example of the hierarchical structure of
18
epee
methods.
3.6.3 Editing Objects While all of the epee environment's methods could be called through the method selector, the group of object editing methods are usually more quickly initiated through the Object Browser. By selecting the Edit method associated with an object, the most appropriate editing tool is then chosen. The default editor for all objects is the `Generic Object Editor' which was written to access and edit any epee object at the level of individual slots. For common process engineering objects, however, speci c focussed editors have been developed to meet the particular needs appropriate (ease of use, consistency checking) for these objects. Examples are the Stream, Mixture, and Component editors. Figures 8 and 9 show both the Stream and Mixture editors editing the Stream and Mixture objects displayed in the Object Browser shown in Figure 6. Fig. 8 Writing focussed applications, such as the Stream and Mixture editor above en- Fig. 9 courages the re-use of these editors in other applications. For instance, in this example, the Mixture editor is called from the Stream editor. However, as each method is independent, the application programmer can take into account the speci c needs of editing a particular object, leaving anything else to other editors and methods.
4 epee and Related Work The following two sections give a brief overview of the alternatives to epee as both a standard for de ning data objects and mechanism for passing those object, and at a higher level as a process engineering design environment.
4.1 Data Representation and Management There are several alternatives to the data models proposed in the epee implementation of the process engineering design environment. The two most important ones are STEP (STandard for the Exchange of Product model data) (Sawyer, 1993) and PDXI (Process Data Exchange Institute) (Motard et al., 1994). STEP is run as a loose consortium of interested parties under the auspices of ISO (the International Standards Organisation). Of particular interest is the STEP subset group, (PI-STEP Process Industries STEP) which was set up as a British DTI (Department of Trade and Industries) and company consortium sponsored project to accelerate the introduction of STEP to the process industries. PDXI can be viewed as the equivalent initiative in the United States. STEP focusses on the complete de nition of data representation standards for the whole life cycle of a product, and the problems of accessing this data through a 19
Figure 8:
A Stream editor operating on the Stream object given in
Figure 6
20
Figure 9:
A Mixture editor operating on the Mixture object given in
Figure 6
21
standard Application Programmers Interface. The objectives of PDXI are similar to those of STEP, except the objects being modelled are those of the Process Industries. From the published literature (Motard et al., 1994) it appears that PDXI has developed a wide range of process industry data models and tools for accessing and organising this data. Both STEP and PDXI are focussed on the data modelling aspects of information exchange for the vast variety of objects that make up their respective elds of interest. epee, however, concentrates on a much smaller aspect of the data modelling problem, and is concerned not only with data modelling but with the development of methods to operate on these objects. As a result, these approaches are complementary. Therefore, we can envisage combining subsets of the STEP and PDXI object de nitions and data representations with epee's application neutral approach.
4.2 Process Engineering Design Rather than take on the characteristic of a particular process engineering design environment, epee has the exibility to o er the user the features of the design environment of their choice wrapped in the epee system. The epee history mechanism o ers the user the possibility of design history maintenance, and di erent object viewers are currently being developed to provide a visualisation tool for di erent design objects as they are being developed. It is hoped that rather than mimic a particular design environment, such as KBDS (Ba~nares-Alcantara et al., 1994), the bene ts of moving to an object-based management system, like epee, will become apparent. And so, as is now happening, KBDS will use epee as the integration layer between the various design tools that it uses. Alternatively, it may be possible in the future for the di erent functions that make up a design environment to be subsumed into the epee environment as a method provider for a number of design tool methods.
5 Conclusions The development of epee into a software environment for process engineering design has demonstrated to users and developers of process engineering software the bene ts of an object-based programming system. As an object-based environment, epee is independent of the process engineering environment that it models. The design environment that epee is used for is de ned by the object de nitions and the methods that are used to manipulate the objects. This makes epee a
exible tool capable of modelling other design environments. 22
This exibility is a result of the system independent implementation of all of epee's main features. These features are: de nition of objects as extensible complex data structures known as templates, capable of handling a wide range of data types and information; the complete recording of the life history of an object including all the objects used in its creation and the methods applied to create that object; object publishing methods that record an object and its history in a database of the user's choice; and access to these databases across a network of computers. The general de nition of objects has been shown to provide a usable support for the de nition of process engineering objects, with the concept of inheritance a valuable tool in categorising families of objects. The data focussed approach of objects has also led naturally to the writing of methods to do speci c tasks on speci c object types leading to focussed design tools that provide a consistent look and feel to the design environment and greater reusability of programming code to the software developers. The way in which design templates have been de ned for a given set of applications has been found, in some cases, to be inconvenient for other applications requiring the same information. When a suitable compromise between the needs of the di erent applications cannot be resolved, this has led to equivalent de nitions of objects to work with di erent types of applications. Compatibility between equivalent object de nitions can be easily maintained, however, as the infrastructure of epee has been designed to facilitate the automatic ring of object conversion methods when required. Also fundamental to epee is its history recording mechanism, which has been shown to be capable of providing the low level functionality needed to implement the design recording and maintenance facilities proposed by other design environments such as KBDS. Combined with its object publishing facilities this paper has demonstrated that epee has the features required to integrate applications seamlessly into a fully functional engineering design environment.
6 The Future At present, the development of epee is moving in three directions. We are improving our current implementation by rewriting much of the underlying programming code. Further applications, especially in visualisation of vapour-liquid equilibrium systems applications, and complex objects such as processes, are being developed, and the integration of third-party design products is being continued. In the future we hope to develop and include many of the high level information management features of design maintenance systems such as KBDS, and to begin developing and implementing signi cant design projects in the epee design 23
environment.
Acknowledgements The support of this work by the Engineering and Physical Sciences Research Council (EPSRC) of the U.K. is gratefully acknowledged.
References Aspen Technology, Incorporated, Process modelling in the 1990's. Aspen Leaf Magazine, pages 1{4 (April, 1990). Ba~nares-Alcantara, R., H. Lababidi, G. Ballinger, and J. King, KBDS: A support system for chemical engineering conceptual design. In Proceedings ESCAPE 4, pages 419{426, Rugby, U.K. IChemE (1994). Ballinger, G., R. Ba~nares-Alcantara, D. Costello, E. S. Fraga, J. King, J. Krabbe, D. M. Laing, R. C. McKinnel, J. W. Ponton, N. Skilling, and M. W. Spenceley, Developing an Environment for Creative Process Design. Chemical Engineering Research and Design, Transactions of the IChemE, 72(A3), 316{324 (1994b). Ballinger, G., R. Ba~nares-Alcantara, D. Costello, E. S. Fraga, J. Krabbe, L. Haitham, M. Laing, R. C. McKinnel, J. W. Ponton, N. Skilling, and M. W. Spenceley, epee: a Process Engineering Software Environment. Computers and Chemical Engineering, 18(Suppl.), 283{287 (1994a). Fraga, E. S., G. H. Ballinger, J. Krabbe, D. M. Laing, R. C. McKinnel, J. W. Ponton, N. Skilling, and M. W. Spenceley, The implementation of a portable object oriented distributed process engineering environment. Technical Report TR 1994-17, The Department of Chemical Engineering, The University of Edinburgh, http://www.chemeng.ed.ac.uk:80/ecosse (1994). Krabbe, J., G. Ballinger, R. Ba~nares-Alcantara, D. Costello, E. S. Fraga, J. Krabbe, H. Lababidi, M. Laing, R. C. McKinnel, J. W. Ponton, N. Skilling, and M. W. Spenceley, The ep'ee Programming and Reference Manual. Technical Report TR-94-18, Department of Chemical Engineering, The University of Edinburgh, http://www.chemeng.ed.ac.uk:80/ecosse (September, 1994). Motard, R. L., M. R. Blaha, N. L. Book, and J. J. Fielding, Process Engineering Databases { From the PDXI Perspective. In Proceedings of FOCAPD '94, Snowmass, Colorado (1994). 24
National Engineering Laboratory, PPDS (Physical Property Data Service) User Manual. The Institution of Chemical Engineers, Rugby, England (1982.). Perkins, J. D. and R. W. H. Sargent, SPEEDUP: A computer program for steadystate and dynamic simulation and design of chemical processes. AICHE Symposium Series, 78(214), 1{11 (1982). Sawyer, P., STEP steps in. The Chemical Engineer, 8th, 20{22 (April, 1993). Skilling, N., G. Ballinger, R. Ba~nares-Alcantara, D. Costello, E. S. Fraga, J. Krabbe, H. Lababidi, M. Laing, R. C. McKinnel, J. W. Ponton, and M. W. Spenceley, sodue: Software object oriented design user environment version 0.1. Technical Report 1992-02, Department of Chemical Engineering, The University of Edinburgh, http://www.chemeng.ed.ac.uk:80/ecosse (February, 1992).
25
