Towards a Reusable Unified Basis for Representing Business Domain Knowledge and Development Artifacts in Systems Engineering Thomas Kofler and Daniel Ratiu 2010-11-03 The Third Workshop on Domain Engineering
Semantic gap in engineering of complex systems During the development process of complex industrial systems many development artifacts are produced They belong to different engineering disciplines Address different views of the product Result of the integration of these views is visible only in the developed product Each engineering discipline is using its special tools -> semantic gap in the development process Due to the high number of artifacts and their heterogeneity, virtually nobody from an organization knows in detail all produced artifacts and their relation to the product under development Due to this lack of knowledge, typical engineering tasks like implementing changes or reusing parts are extremely difficult and expensive 2010-11-03 Thomas Kofler, DE2010 2
Semantic gap in engineering of complex systems Domain knowledge is a common denominator between development artifacts 2010-11-03 Thomas Kofler, DE2010 3
Manage dependencies by linking a domain model to development artifacts Our approach is based on an unified model that contains knowledge about the development artifacts, the product to be developed and the dependency relations between them. 2010-11-03 Thomas Kofler, DE2010 4
Framework for dependency management In order to build such a model we need a conceptual framework which contains the following ingredients: A vocabulary to describe different kinds of development artifacts, a generic vocabulary to describe the knowledge about the product to be developend and a vocabulary to capture the dependencies between product concepts and development artifacts. 2010-11-03 Thomas Kofler, DE2010 5
SUO (Standard Upper Ontology) as semantic basis SUO represents a high-level categorization of the general concepts that can be used as starting point for organizing the knowledge about the domain of the product and the development artifacts SUO is too general for our purpose, many of the concepts in SUO are irrelevant in our use-case Therefore we only use a part of SUO 2010-11-03 Thomas Kofler, DE2010 6
Towards a framework for dependency management A fragment of SUO Technische Universität München (TBox) In order to provide an adequate vocabulary for dependency management, we need to extend SUO with concepts needed for the description of development artifacts and the product under development and the dependencies between the product and these artifacts. 2010-11-03 Thomas Kofler, DE2010 7
Extending SUO with knowledge about Systems Engineering Technische Universität München System boundaries: What belongs to the system and what is outside Industrial Process (behavior of the system): Can change attributes (Changes), can be followed by another Industrial Process (Follows) Patient: Is the input and output for an Industrial Process 2010-11-03 Thomas Kofler, DE2010 8
Extending SUO with knowledge about development artifacts Whenever a development artifact defines something, it also refers that thing Development Artifact: Refers a Thing (means that a certain concept is explicitly referenced in a development artifact), defines a System (means that an important design decision about a system is contained in a development artifact), needs another development artifact 2010-11-03 Thomas Kofler, DE2010 9
Example Edger: Is part of a Rolling Mill Compresses the edges of rolled materials Is specified by a CAD document Rolled Materials: Have physical properties such as width, height, temperature The edger has to take some of these properties into account in order to process the rolled material (e.g. the optimal throughput speed of the engine of the edger depends on the temperature of the rolled material) The width of the rolled material depends on the width of the closed hydraulic press (part of the edger) 2010-11-03 Thomas Kofler, DE2010 10
Example Technische Universität München Systems engineering related Queries: When we change the width of the hydraulic press, which development artifacts do we have to consider? When a specific development artifact defines a system and that system has parts, what development artifacts define those parts? (Generic Query: it doesn t use the vocabulary specific to edgers) 2010-11-03 Thomas Kofler, DE2010 11
Discussion On the usefulness of product knowledge for dependency management Motivation: assumption that proudct knowledge can be used to make the (hidden) dependencies between development artifacts explicite In realtiy: there are other dependencies between artifacts that are independent of the product knoweldge (e.g. dependencies generated by the integration between different tools that are used to describe the engineering views) On the choice of SUO as semantic basis There are other upper-level ontologies (e.g. Bunge, GOL) which are frequently used in conceptual modeling SUO offers us enough and appropriate concepts upon which to build our mid-level ontology 2010-11-03 Thomas Kofler, DE2010 12
Discussion On the instantiation of the framework for other system engineering domains We aim to define a mid-level ontology (SUO + our extension = TBox) that can serve as basis for every Abox (=instantiation of the TBox) in the domain of automation systems engineering Our mid-level ontology should have enough concepts to formulate queries on a high level of abstraction On the possabilities for reusing our framework a) Reusing the TBox for domain-specific ABoxes b) Reusing the TBox for creating domain-specific TBoxes with more details c) Once the model for a certain product is created, it can be reused in future engineering projects 2010-11-03 Thomas Kofler, DE2010 13
Future Work Framework evaluation Dependency management is not an end goal per se: Support of typical systems engineering tasks like impact analysis and reuse Definition of generic queries relevant for systems engineering (e.g. for impact analysis, for finding cross-cutting dependencies between different kinds of development artifacts, ) Instantiate the framework for other domains The generic concepts of our TBox should be used as basis for domain-specific ABoxes. As future work we aim to consolidate the mid-level layer by instantiating the framework for describing other products and other development artifacts. 2010-11-03 Thomas Kofler, DE2010 14
Future Work Semantically enriched PDM tools In engineering projects, product data is often stored in PDM tools (e.g. Comos). Current PDMs capture the knowledge about the built product only in an implicit manner and links it with a (very shallow) artifact model. Our mid-level ontology can be used to semantically enrich PDMs by offering a conceptual basis for a richer representation of product knowledge Automation Provide a (semi-) automatic support for creating a domainspecific ABox. The automation is very important, because the effort of creating the ABox is an essential factor that determines wheter our approach can be used in practice. 2010-11-03 Thomas Kofler, DE2010 15
End. 2010-11-03 Thomas Kofler, DE2010 16