Implementation of a Design Repository based on PSSP Ontology

Transcription

1 Implementation of a Design Repository based on PSSP Ontology Pekka Siltanen1, Antti Pärnänen1, Ville Sundberg2, Timo-Pekka Viljamaa1 1 VTT Information Technology, P.O. Box 1201, FIN VTT, Finland, {pekka.siltanen antti.parnanen}@vtt.fi, timo-pekka.viljamaa@iki.fi 2 Nordem Oy, Frederikinkatu 67 D 35, Helsinki, Finland, ville.sundberg@nordem.fi Abstract Today large engineering projects, such as plant design projects, are implemented using concurrent design methodologies. Knowledge sharing within a project organisation is a key element for successful project execution. What we need is a common language to represent knowledge so that it can be shared between designers using different software and performing different design tasks. This paper describes a prototype implementation of a web based tool using PSSP language, a language for managing design knowledge. Keywords Plant design, life cycle management, mill model, design ontology, knowledge management, virtual reality 1 Introduction Today large engineering projects are becoming more and more complex. The complexity of the projects means that a single designer, or even a single company, cannot manage the whole project. Therefore companies are concentrating only on their core competences, and concurrent design methodologies, used by several design teams within one company or several companies, are applied to almost every large engineering project. Knowledge sharing within a project organisation is a key element for successful project execution. Today s design and manufacturing time schedules are so tight that there is no room for delays or misunderstandings because of lack of information. All information must be available to everyone in the project at all times. In a concurrent design project the project teams can be globally distributed, and knowledge must be shared between them successfully. Traditionally, knowledge sharing has been concentrated in exchanging geometric representations of the artefact designed, accompanied with its documentation. However, while often practical and reliable in information exchange, CAD files or other documents are often problematic while trying process the information by a variety of computer applications, because of lacking standard representations. Also, it must be noted that the documents themselves are not important, but the knowledge that they contain. We should therefore concentrate also in how the knowledge needed in the design process can be represented. The international standardisation community has been creating standard data models for representing product information. Standards, such as ISO [ISO 1994] and IFC [IFC 2002] define data model and exchange formats for product information as well as geometric data. Within the field of design theory and methodology, general ontologies for design are defined. E.g. Gero [Gero 1990] defines a knowledge representation schema for design activity, categorising design knowledge related to the artefact designed into form, function and behaviour. Similar categorisation is used also in POP ontology (Product, Organization and Process) [Garcia 2004]. Multilevel Flow Modeling [Lind 1994] uses three concepts - goal, function and component - to describe the design process. In MFM, the purpose of the product to be designed

2 is modelled with the concept of goals. The goals state why the product is designed, while the functions are seen as the means to achieve the goals. Traditional design databases are more data oriented than knowledge oriented. Szykman et all. [Szykman 2000] introduced a design repository, that is an knowledge based design modelling system based on form, function, behaviour categorisation. Garcia & all. [Garcia 2004] describe a collaboration software that uses POP ontology. Goal of this research was to study how PSSP ontology [Pohjola 2001] could be used as a foundation for building a design repository, of a same kind as the system introduced by Szykman. Similar work in chemical engineering has been done by Pasanen [Pasanen 2001]. We tried to find answers to two main questions: Is PSSP structured well enough for software implementations? How can PSSP be use in practice? Answers to those questions were searched by first creating XML schema representing PSSP ontology, and then implementing software implementation for storing and manipulating data in that format. The data format and the software implementation is described in the following sections. 2 Knowledge representation using PSSP 2.1 PSSP ontology PSSP ontology is described in detail by Pohjola [Pohjola 2001, , ]. This chapter gives an overview of the main concepts implemented. PSSP is a top level ontology, which Pohjola argues to have unlimited potential in representing reality. The top-most categories in PSSP ontology are Universals (object classes and attributes that could exist) and Particulars (objects and attribute values that do exist) (Figure 1). Universals divide into Classes and Attributes and Particulars divide into Objects and Values. The basic commitments of the PSSP ontology are: all real things are composed of events and media where the events occur. Processes and products are composite objects for which PSSP defines fixed structure of event-medium composites, all real things are characterized by exactly four attributes: Purpose, Structure, State and Performance. Particular objects that are instances of Real Thing class, or its subclasses, are here called PSSP objects. In addition to the Real Thing subclasses Event, Medium, Event-Medium Composite, Process and Product (Figure 1), Pohjola defines also five other subclasses: Interaction (subclass of Event), Boundary and Interface (subclasses of Medium), Interior and Exterior (subclasses of Event-Medium composite). Details of the meaning of the classes is explained in [Pohjola 2001]. Particular values that are instance of Universal PSSP ontology attributes are called here PSSP attribute values. Pohjola also defines graphical notation for PSSP, where basic PSSP concepts are represented as circles and ovals. Designing an object can be seen as a process where the designer acquires and represents enough knowledge so that the object can be manufactured or otherwise implemented. In the PSSP methodology the designer starts the process by stating the purpose of the object to be designed. Goal of the design process is to decide what will be the state (how the object behaves) and performance (how the object fulfils its purpose) of the object being designed.

3 Being Universal Particular Class Attribute Object Value Real Thing Purpose Structure State Performance Event Medium Event-Medium Composite Process Product Figure 1. Top level categories of the PSSP ontology [Pohjola ] Designer normally must disaggregate the object into sub-objects (each having own purpose, state and performance), hence defining structure of the object. Disaggregating is continued until state and performance of the sub-object can be determined. State and performance of the composite object is then derived from state and performance of its sub-objects. This results in iterative process: in each level of the object structure, performance of the sub-object is evaluated and if it does not fulfil the requirements set in the purpose, the structure or purpose must be changed (Figure 2). Define purpose (performance criteria) Define structure that should fulfill the purpose Define state (behavior) of the object having the structure. Purpose =? Structure =? State =? Performance =? Define performance of the object against performance criteria. 2.2 PSSP as XML Schema Figure 2. Process of defining PSSP objects PSSP ontology was represented as XML schema for software implementation purposes. The XML schema describes a language to store and exchange knowledge of particulars, based on PSSP universal concepts. Each of the PSSP objects and PSSP attribute values are represented as XML elements. Structure of the PSSP objects is represented using standard hierarchical XML representation, representing hierarchy of PSSP objects. Rules for the valid hierarchies are derived from [Pohjola 2001]: each PSSP object can be divided into topology, i.e. objects of the same class, or into predefined unit structure, e.g. Product decomposes into unit structure of Exterior, Interior, Interaction and Boundary (Figure 3).

4 Figure 3. Example of the PSSP object XML format as graphical representation Content of the PSSP attribute values is defined in [Pohjola 2001] as expression, whose details are not specified further. In the prototype implementation a simple structure for textual expression was specified: expressions are chapters that compose of the chapter title, text paragraphs and references to figure (Figure 4). Figure 4. Example of PSSP attribute value XML format as graphical representation. Relationships between objects are not defined explicitly in PSSP ontology categories (Figure 1). However, several types of relationships are described in [Pohjola , Pohjola ]. In PSSP XML schema three different relationship types has been implemented: generic inter-object relationships between any PSSP objects and monitoring and manipulating relationships between Event and Media objects PSSP articles define also other entities that are hard to place in the ontology categories in Figure 1. Concepts of Cause, Effect and Precondition are defined as forming unit structure of Event, but they are not PSSP objects. Therefore in PSSP schema, they are defined as textual expressions composed of chapters. 3 Implementation The design management database prototype implemented is called General Design Tool (GDT). The tool builds up components to support creating, viewing, searching and storing PSSP objects. The tool is implemented as a classical three tier architecture using Apache Xindice [Xindice] as data storage, Tomcat/Cocoon [Cocoon] combination as a middle tier and web browser as an user interface (Figure 5).

5 Users Web browser Internet Cocoon, Xindice & HTTP server HTML, XML, SVG XML Web browser Xindice database Web browser HTTP requests Cocoon XSLT transformations Figure 5. Architecture of GDT. GDT is based on commonly used structured documentation methodology [Goldfarb 1990]. PSSP objects are managed as a hierarchical XML document whose structure is defined by the PSSP XML schema. GDT consists of three integrated tools: document management tool PSSP object editor and PSSP object viewer. The document management, viewer and the editor are web based and can be used via normal web browser. Graphic-mode in the viewer and editor requires SVG (Scalable Vector Graphics [SVG]) compatible browser, though the tools can be used even without SVG support. The document management tool provides a possibility for several users to view and edit documents simultaneously. A simple PSSP object locking guarantees that only one user at a time can edit the PSSP object. Locking is implemented as hierarchical locks where only ancestors and descendants of an object being edited are locked. Thus siblings of the object can be edited simultaneously by another user. Also, a search functionality is provided. GDT uses Apache Xindice for storing PSSP objects in XML format. GDT is implemented for proof of concept purpose and therefore a freely available native XML database is suitable for storing documents in GDT. Connection between Xindice and Cocoon is managed by the embedded Xindice XML-RPC driver. Using Cocoon as a middleware, it is possible to easily integrate and add new components and functions to the current system. Functional logic in GDT is implemented with XSLT transformations, and with a native XML database and XML based outputs this makes GDT quite easy and straightforward to maintain and update. One of the strengths of the Cocoon based solution is its ability to target multiple client devices. Currently, only a web browser and XML, SVG and HTML as output formats are supported. 3.1 GDT usage examples To validate usability of the GDT in specifying PSSP objects, several examples were modelled using PSSP. In this chapter screenshots of the user interface while creating one such modelling case is described, in order to show how the system is used. The example is a simplified version of the pump selection case described in [Pohjola ]. In the PSSP editor, for each of the object classes defined in PSSP ontology, GDT editor guides the user to create valid structure by given only the valid sub-objects from which the user can

6 choose from (Figure 6). The user selects an insertion symbol (arrow in the figure) and the application checks from the PSSP XML schema which are valid PSSP objects in this context. The object selection user interface is implemented as a JavaScript pop-up menu. The right frame of the user interface in Figure 7 shows how PSSP ontology object Process and its Purpose attribute (Figure 1) are described. The left side on the user interface shows this are valid structural elements for the Process object (Process, Interior, Exterior, Interaction or Boundary), as defined in [Pohjola 2001]. Figure 6. Creating structure by s electing from list of valid sub-objects (GDT editor) GDT editor guides creation of the expressions in PSSP attribute values similarly. GDT creates empty templates of selected expression type and the user can edit the text contents of the by simply clicking any text in the GDT editor, which changes the user interface to editable text box (Figure 7). Figure 7. Editing text contents of a attribute (GDT editor) In the GDT editor the user can create links between objects. The links are visualised in the PSSP graphical format or as normal hypertext document (Figure 8) in the GDT viewer. Hierarchy relationships are represented as normal directory tree structure or as nested ovals in the graphical format, which can be used as navigational interface. In the current implementation the PSSP attribute values contain only textual information and pictures. However, it would be relatively simple to extend the application so that other types of media objects, such as CAD models or videos, can be embedded into the PSSP attribute values.

7 In addition to standard tree representations and PSSP graphical format, we also tested several other user interfaces for viewing hierarchical PSSP data. Results of these experiments, including implementation of 3D user interface in VTT virtual reality visualisation system, are described in [Viljamaa 2004]. Figure 8. Links between the customer interaction and the pump document in PSSP graphical format and hypertext document (GDT viewer in graphic mode) 4 Summary and future research This paper has presented a prototype implementation of a design database, using which the parties involved in concurrent design project can exchange information using common PSSP ontology. The implementation was created in the NDC-project [NDC]. The hypothesis behind the project is that creating a hierarchical framework of all the knowledge created in the design process, leads to improved communication between design partners, and therefore better design results. Usability tests using early versions the application showed that some of the users were quite confused by the PSSP methodology. It is not clear yet whether the comments resulted from poor user interface design, lack of training or too complicated methodology The modelling examples tested show that GDT tool is capable of representing PSSP objects as defined in [Pohjola 2001]. However, there are several limitations in the application that must be solved in the future: GDT uses only the classes defined in PSSP upper level ontology, which are on fairly abstract level. Full power of PSSP would be achieved only when more specific, real life object classes inherited from PSSP classes, are used. There are several components in the prototype implementation, such as XML database or Javascript hierarchy tree visualisation, that are usable with small data quantities, but probably too slow with large amount of data. The application does not have any PSSP object version control. The application guides the user to create a document that is syntactically correct according to the PSSP XML schema. However, it does not really guide the user to apply the iterative design process described in Figure 2. Since the process of defining PSSP objects starts by defining Purpose of each object, the GDT tool is well suited for managing design requirements. The problem that design solution can shift

8 away from the original goals because of several small design changes together create design that does not fulfil the original goal has been noticed before [Kiviniemi 2004]. In PSSP process this is prevented by checking the object performance after each design change to verify whether the result fulfils the original purpose. The implementation shows PSSP methodology can be used as a foundation for creating a design repository based on unified format. However, the published PSSP articles were quite indigestible, and personal communication with the author was required during the implementation. XML is well suited for representing the PSSP ontology. Since PSSP defines also other types of relationships between objects than just hierarchical structures, more advanced technologies such as semantic web definition languages should be considered in the future. Even though the softwareimplementation itself proved successful, there seems to be a gap between rather theoretic approach of PSSP and real life design cases. Therefore, evaluation the overall applicability of the methodology requires much more industrial tests in real world modelling cases, which needs to be implemented in the future research. Acknowledgement This work has been funded by Tekes - National Technology Agency of Finland - and VTT Technical Research Centre of Finland. We wish to acknowledge our gratitude and appreciation to all the NDC project partners for their contribution during the development of various ideas and concepts presented in this paper. References Cocoon: WWW page Garcia Ana, Kunz John, Ekstrom Martin, Kiviniemi Arto: Building a Project Ontology with Extreme Collaboration and Virtual Design and Construction, Technical Report TR152, Center for Integrated facility Engineering, Goldfarb Charles F.: The SGML Handbook. Calendon Press, Oxford, Gero John S.: Design prototypes: a knowledge representation for design, AI Magazine, Vol 11, No 4, p , IFC: IFC2X Edition 2. Model Implementation Guide. WWW page ISO: Industrial automation systems and integration-product data representation and exchange-part 1: Description methods: Overview and fundamental principles, 1994 Kiviniemi Arto, Fischer, Martin: Requirements Management Interface to Building Product Models. International Conference on Computing in Civil and Building Engineering, Weimar, Bauhaus-Universität, Lind Morten: Modeling Goals and Functions of Complex Industrial Plant. Applied Artificial Intelligence, Vol 8 No. 2, April-June, NDC: New Design Culture project, WWW page Pasanen Antti: Phenomenon-Driven Process Design Methodology. PhD Thesis. University of Oulu, Pohjola Veikko: POEM Guide Book. Introduction to SHE conscious process design. University of Oulu Press, Oulu, Finland, Pohjola Veikko: Ontology supporting knowledge integration, in Milutinovic, V. and Vujovic, I. (Eds) Advances in the Internet Technology: Concepts and Systems, IPSI and Academic Press, p , Belgrad, Pohjola Veikko: Ignorance management by contextual templates, in Proceedings of IPSI Stockholm 2004, September 24-26, SVG: WWW page Szykman, Simon, Sriram Ram.D., Bochenek, Christophe., Racz, Janusz W.; Senfaute, Jocelyn., Design repositories: engineering design's new knowledge base. Intelligent Systems, IEEE, Vol 15, issue 3, p , Viljamaa, Timo-Pekka: Visualisation of hierarchical data. Master s Thesis. Helsinki University of Technology. Department of Computer Science and Engineering, Xindice : WWW page