An Ontological Framework for Knowledge Management in Systems Engineering Processes - PDF

Please download to get full document.

View again

of 21
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Information Report



Views: 2 | Pages: 21

Extension: PDF | Download: 0

Related documents
An Ontological Framework for Knowledge Management in Systems Engineering Processes X An Ontological Framework for Knowledge Management in Systems Engineering Processes Olfa CHOURABI, Yann POLLET,
An Ontological Framework for Knowledge Management in Systems Engineering Processes X An Ontological Framework for Knowledge Management in Systems Engineering Processes Olfa CHOURABI, Yann POLLET, Mohamed BEN AHMED CNAM, CEDRIC- SEMPIA laboratory, PARIS RIADI laboratory, TUNISIA) 1. Introduction Systems Engineering (SE) processes comprise highly creative and knowledge-intensive tasks that involve extensive problem-solving and decision-making activities among interdisciplinary teams (Meinadier, 2002). SE projects involve the definition of multiple artifacts that present different formalization degrees, such as requirements specification, system architecture, and hardware/ software components. Transitions between the project phases stem from decision making processes supported both by generally available domain knowledge and engineering experience. We argue that Knowledge about engineering processes constitutes one of the most valuable assets for SE organizations. Most often, this knowledge is only known implicitly, relying heavily on the personal experience background of system engineers. To fully exploit this intellectual capital, it must be made explicit and shared among project teams. Consistent and comprehensive knowledge management methods need to be applied to capture and integrate the individual knowledge items emerging in the course of a system engineering project. Knowledge management (KM) is a scientific discipline that stems from management theory and concentrates on the systematic creation, leverage, sharing and reuse of knowledge resources in a company (Awas el al, 2003). Knowledge management approaches are generally divided into personalization approaches that focus on human resources and communication, and codification approaches that emphasize the collection and organization of knowledge (McMahon et al. 2004). In this work, we consider the latter approach for KM. Special focus is put on the comprehensive modeling of system engineering project knowledge. This knowledge partly resides in the product itself, while a lot of different types of knowledge are generated during the engineering processes. The background information such as why engineers came up with the final shape or geometry, what constraints were to be considered in engineering processes, and so on, can not be found either (Chan-Hong.P et al.2007). In other words, most of design rationale either disappear or exist partially in the form of engineering documents. The analysis of current engineering practices and supporting software tools reveals that they adequately support project information exchange and traceability, but lack essential capabilities for knowledge management and reuse.( C. Brandt et al., 2007) 150 Knowledge Management The recent keen interest in ontological engineering has renewed interest in building systematic, consistent, reusable and interoperable knowledge models (Mizoguchi et al. 2000)( Kitamura, 2006). Aiming at representing engineering knowledge explicitly and formally for sharing it among multidisciplinary engineering teams, our work builds upon ontological engineering as a foundation for capturing implicit knowledge and as a basis of knowledge systematization. In this chapter we present our vision about the main building blocks of a semantic framework for knowledge capitalization and sharing in Systems Engineering domain. The key idea behind our proposal is a flexible ontology-based schema with formally defined semantics to enable the capture and reuse of system engineering experiences. The main contributions of this work can be summurized as follows: A generic ontological framework for System Engineering Knowledge systematization :. The framework sets the fundamental concepts for a holistic System Engineering knowledge model involving explicit relationships between process, products, actors and domain concepts. A Knowledge capitalization model: we focus on problem resolution records during project execution. We address this problem through the use of the formal framework for capturing and sharing significant know-how, situated in projects context. we introduce the concept of Situated Explicit Engineering Knowledge (SEEK) as a formal structure for capturing problem resolution records and design rationale in SE projects. A Knowledge sharing model: we propose a semantic activation of potential relevant SEEK(s) in an engineering situation. The chapter is structured as folowing: the next section discusses key background information about System Engineering processes and knowledge management issues in SE setting. Section 3 discusses roles and representative examples of ontological engineering in SE. In section 4, we detail the ontological framework for system engineering knowledge modelling. Section 5, presents a formal approach for Situated Explicit Engineering Knowledge capitalization and sharing. Section 6, illustrates our proposal in a transport system engineering process. Section 7, discusses relevant related work. 2. Problem statement 2.1 System Engineering System Engineering (SE) is an interdisciplinary approach to enable the realization of successful systems. It is defined as an iterative problem solving process aiming at transforming user s requirements into a solution satisfying the constraints of: functionality, cost, time and quality (Meinadier, 2002). This process is usually comprised of the following seven tasks: State the problem, Investigate alternatives, Model the system, Integrate, Launch the system, Assess performance, and Re-evaluate. These tasks can be summarized with the acronym SIMILAR: State, Investigate, Model, Integrate, Launch, Assess and Re-evaluate. (Bahill et al. 1998). This Systems Engineering Process is shown in Figure 1. An Ontological Framework for Knowledge Management in Systems Engineering Processes 151 Fig. 1. SIMILAR Process It is important to note that the Systems Engineering Process is not sequential. The tasks are performed in a parallel and iterative manner. At each step a comprehensive set of possible engineering models arises which are progressively combined and refined to define the target system. Because of its inherent creative nature, it is a special case of business process. It is poorly structured and, as a rule, it evolves in an unpredictable manner. In such highly dynamic settings with continuously changing requirements, the overwhelming majority of the engineering ways of working are not properly formalized, but are heavily based on the experience knowledge of the human performers. As a consequence, engineering support environments have further to deal with the systematic collection of experience from previous project cycles and its dissemination and utilization from analogous problem solving contexts in the future. (Miatidis& Jarke, 2005). in section 4, we present a knowledge modeling framework that acts as a backend for what we expect to be a Next generation of engineering support environment i.e.: knowledge centric rather than data centric Knowledge Management issues in SE The Above-delineated characteristics of SE processes show that a significant amount of knowledge is involved to solve a mix of ill- and well-defined problems. System engineers require topic knowledge (learned from text books and courses) and episodic knowledge (experience with the knowledge) (Robillard, 1991). One of the main problems in SE processes is the lack of capture and access to knowledge underpinning the design decisions and the processess leading to those decisions (Ali-Babar et al., 2005). System Engineers spend large portions of their time searching through vast amounts of corporate legacy data and catalogs searching for existing solutions which can be modified to solve new problems or to be assembled into a new device. This requires utilizing databases or online listings of text, images, and computer aided design (CAD) data. Browsing and navigating such collections are based on manually-constructed categorizations which are error prone, difficult to maintain, and often based on an insufficiently dense hierarchy. Search functionality is limited to inadequate keyword matching on overly simplistic attributes; it lacks the formal framework to support automated reasoning. (Miatidis& Jarke, 2005) In this work, we focus firstly on the knowledge modeling issue whichh is often considered as the first step in developing Knowledge-Based Systems (KBS). The aim of this process is to understand the types of data structures and relationships within which knowledge can be 152 Knowledge Management held, and reasoned with. We use ontologies to describe the knowledge model in a formal representation language with expressive semantics. In order to determine the basic building blocks of the knowledge repository, we introduce the notion of SEEK Situated Explicit Engineering Knowledge as the smallest granularity in the system experience knowledge. SEEK, represent an integrated structure that capture product and process knowledge in engineering situations in conformance to a set of layered ontologies. 3. Background: Ontological Engineering Ontologies are now in widespread use as a means formalizing domain knowledge in a way that makes it accessible, shareable and reusable (Darlington, 2008). In this section, we review relevant ontological propositions for supporting engineering processes. In the knowledge engineering community, a definition by Gruber is widely accepted; that is, explicit specification of conceptualization (Gruber, 1993), where conceptualization is a set of objects which an observer thinks exist in the world of interest and relations between them. Gruber emphasizes that ontology is used as agreement to use a shared vocabulary (ontological commitment). The main purpose of ontology is, however, not to specify the vocabulary relating to an area of interest but to capture the underlying conceptualizations.( Gruber, 1993) Uschold (Uschold& Gruninger, 1996) identifies the following general roles for ontologies: Communication between and among people and organizations. Inter-operability among systems. System Engineering Benefits: ontologies also assist in the process of building and maintaining systems, both knowledge-based and otherwise. In particular, o Re-Usability: the ontology, when represented in a formal language can be (or become so by automatic translation) a re-usable and/or shared component in a software system. o Reliability: a formal representation facilitates automatic consistency checking. o Specification: the ontology can assist the process of identifying a specification for an IT system. One of the deep necessities of ontologies in SE domain is, we believe, the lack of explicit description of background knowledge of modeling. There are multiple options for capturing such knowledge; we present a selection of representative efforts to capture engineering knowledge in ontologies. (Lin et al., 1996) propose an ontology for describing products. The main decomposition is into parts, features, and parameters. Parts are defined as a component of the artifact being designed . Features are associated with parts, and can be either geometrical or functional (among others). Examples of geometrical features include holes, slots, channels, grooves, bosses, pads, etc. A functional feature describes the purpose of another feature or part. Parameters are properties of features or parts, for example: weight, color, material. Classes of parts and features are organized into an inheritance hierarchy. Instances of parts and features are connected with properties component of, feature of, and sub-feature of. (Saaema et al,, 2005) propose a method of indexing design knowledge that is based upon an empirical research study. The fundamental finding of their methodology is a comprehensive An Ontological Framework for Knowledge Management in Systems Engineering Processes 153 set of root concepts required to index knowledge in design engineering domain, including four dimensions: The process description i.e. description of different tasks at each stage of the design process. The physical product to be produced, i.e. the product, components, sub-assemblies and assemblies. The functions that must be fulfilled by a particular component or assembly. The issues with regards to non functional requirement such as thrust, power, cost etc. (Kitamura& Mizoguchy, 2004) has developed a meta-data schema for systematically representing functionality of a product based on Semantic Web technology for the management of the information content of engineering design documents. An ontology that supports higher-level semantics is function-behaviour-structure (FBS) ontology (gero et al, 2006). Its original focus was on representing objects specifically design artifacts. It was recently applied to represent design processes. For ontology reusability, hierarchies are commonly established; (Borst et al, 1997) propose the PhysSys ontology as a sophisticated lattice of ontologies for engineering domain which supports multiple viewpoints on a physical system Notwithstanding the promising results reported from existing research on SE ontologies, the reported ontological models don t provide a holistic view of the system engineering domain. They are either too generic or only focus on specific aspects of system representation. As development of ontologies is motivated by, amongst other things, the idea of knowledge reuse and share ability, we have considered a coherent reuse of significant ontological engineering work as complementary interrelated ontologies corresponding to the multiple facets of system engineering processes. 4. Ontological framework for knowledge modeling in System Engineering projects In this section, our framework for knowledge modeling in system engineering projects is described. It structures the traces of engineering in the form of semantic descriptions based on a system engineering ontology. Section 4.1 introduces the so-called SE general Ontology, Section 4.2. Describes the modeling layers considered for semantic knowledge capture and section 4.3 presents an engineering illustrative example. 4.1 SE general Ontology We focus here on the knowledge modeling issue that is often considered as the first step in developing a knowledge management system. The aim of this process is to understand the types of data structures and relationships within which knowledge can be held and reasoned with. We use ontologies to describe the knowledge model by a formal representation language with expressive semantics. In order to determine the basic building blocks of the knowledge model, we introduce the notion of Situated Explicit Engineeing Knowledge SEEK as the smallest granularity in the system experience knowledge. The systems engineering project assets represent an integrated structure that captures product and process knowledge in engineering situations 154 Knowledge Management as an instance of loosely connected ontology modules that are held together by a general ontology for systems engineering. This general ontology is developed in domain, product, and process modules. The three levels are required to provide a comprehensive semantic model for the systems engineering project asset through an integrated representation of its semantic content, its structural content, and its design rationale. By instantiating these ontological concepts, concrete SEEK could be stored in a system engineering repository for future reuse. Furthermore, the ontology itself can serve as a communication base about the products and processes e.g. for exploring domain knowledge for system engineers. -Domain facet: The domain ontology defines the specific domain concepts, attributes, constraints, and rules. It aims to capture formally a target system according to its different abstraction levels; in other words, for each engineering domain, the ontology defines a consensual semantic network to represent domain-specific requirements, functions, behavior and physical components, as well as their structural relationships (such as is a part of ) and their semantic relationships (such as allocation ). For example, domain ontology for electric circuits might define, among other things, generic types of electric components such as transistor, connection relation among components, physical laws among physical quantities, functions of components, and allocation relations between components and functions. Figure 3 presents a high level description of a typical domain facet. Domain facets : system abstractions levels Precision P r o b le m d o m a in o n t o lo g y R e q u ir e m e n t o n t o lo g y F u n c t io n o n t o lo g y Figure B e h a v io r o n t o lo g y C o m p o n e n t / p h y s ic a l p a r t s o n t o lo g y Fig. 2. Ontologies for system engineering domain facets -Product facet: The product ontology contains concepts and relations that represent artifact types such as requirement documents, functional models, or conceptual schema. The product ontology provides logical structure and basic modeling constructs to describe engineering artifacts. This means that data can be extracted from domain ontology and packaged into an ontological constructed conceptual model or an engineering document. By formally relating modeling elements to domain concepts we could provide a systematic and semantic description of an engineering solution. -Process facet: The process ontology contains concepts and relations that formally describe engineering activities, tasks, actors, and design rationales concepts (goals, alternatives, An Ontological Framework for Knowledge Management in Systems Engineering Processes 155 arguments, and justifications for engineering decisions). Both the process and the product facets act as a formal logical structure for the systems engineering project asset. The domain facet provides semantic content for this structure. Both the process and the product facets act as a formal structure for the SEEK. The domain facet provides semantic domain values for characterizing this structure. Figure 4, illustrates the relationships and the complementarily of our three modeling facets for comprehensively representing system engineering knowledge. Fig. 3. Relationships between the three modeling facets in SE general ontology. 4.2 Multi-layered ontologies for SE knowledge modeling While the ontological modules for domain, product, and process introduce general-level concepts that describe a systems engineering project asset, they need to be specialized and refined in order to provide an operational knowledge model for systems engineering projects. To this end, we introduce a layered organization of these ontological modules: a general ontology for system engineering, a specialized ontology for an engineering domain (such as automotive or information systems), and an application-specific ontology. Layers subdivide the ontology into several levels of abstraction, thus separating general knowledge from knowledge about particular domains, organizations, and projects. This allows all the engineering assets to be based on generic concepts while at the same time providing a mechanism to enable different stakeholders to define their own specific terminology and concept interpretation. By instantiating the most specific ontological concepts, concrete information items can be stored in a centralized project repository. Ontological concepts act as a semantic index for engineering artifacts. Each layer is defined along the two axes of abstraction and semantic links. Abstraction allows modeling a gradual specification of models that are more and more concrete, that is, from abstract system requirement to concrete system components. The semantic links define 156 Knowledge Management how the concepts within and between an ontology module are related to each other. Typical semantic links are subsumption relations, part of relations and traceability relations. For example,
View more...
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!