Developing Systems EngineeringOntologiesMD B. Sarder and Susan FerreiraSystemsEngineeringResearchCenter(SERC)The University of Texas at ArlingtonBox 19017, Arlington, TX 76019bsarder@hotmail.com,ferreira@uta.eduAbstractSystems engineeringontologies arerequired toassist interestedparties in understandingthesystems engineering discipline's broad and multi-faceted nature. This paper discusses the need for andgeneral benefits of an ontology. The authors discuss the use of the domain knowledge acquisitionprocess ontology modeling technique and its application to capture a systems engineering functionaldomain ontology. A preliminary systems engineering functional domain ontology generated using theontology development methodology is presented. This systems engineering ontology will continue tobe refined over time. This paper discusses plans to develop a system of systems engineering ontologyusing the developed systems engineering ontology.Keywords: Ontology modeling, domain knowledge acquisition process, system of systemsengineering,systems engineering ontology1.IntroductionSystems engineering (SE) is a discipline that solves problems in various domains, at differentlevels, and with ever increasing complexity. Systems engineering integrates multiple disciplines andspecialty groups into a coordinated team effortforming a structured development process thatproceeds from concept development to production and operation [1]. The increasing complexity andmultidisciplinary nature of systems engineering causes some difficulty in settling on a commonsemantics and standard. This can be seen with the multiple standards and processes that exist forsystems engineering [2], [3], [4], [5], [6]. Systems engineering projects may consist of engineers fromdifferent disciplines and backgrounds which can make the lack of commonality even more difficultwhen determining what process to use and project semantics. In this scenario, a systems engineeringfunctional ontology can be very useful to the systems engineering user community
Developing Systems Engineering Ontologies MD B. Sarder and Susan Ferreira Systems Engineering Research Center (SERC) The University of Texas at Arlington Box 19017, Arlington, TX 76019 bsarder@hotmail.com, ferreira@uta.edu Abstract Systems engineering ontologies are required to assist interested parties in understanding the systems engineering discipline's broad and multi-faceted nature. This paper discusses the need for and general benefits of an ontology. The authors discuss the use of the domain knowledge acquisition process ontology modeling technique and its application to capture a systems engineering functional domain ontology. A preliminary systems engineering functional domain ontology generated using the ontology development methodology is presented. This systems engineering ontology will continue to be refined over time. This paper discusses plans to develop a system of systems engineering ontology using the developed systems engineering ontology. Keywords: Ontology modeling, domain knowledge acquisition process, system of systems engineering, systems engineering ontology 1. Introduction Systems engineering (SE) is a discipline that solves problems in various domains, at different levels, and with ever increasing complexity. Systems engineering integrates multiple disciplines and specialty groups into a coordinated team effort forming a structured development process that proceeds from concept development to production and operation [1]. The increasing complexity and multidisciplinary nature of systems engineering causes some difficulty in settling on a common semantics and standard. This can be seen with the multiple standards and processes that exist for systems engineering [2], [3], [4], [5], [6]. Systems engineering projects may consist of engineers from different disciplines and backgrounds which can make the lack of commonality even more difficult when determining what process to use and project semantics. In this scenario, a systems engineering functional ontology can be very useful to the systems engineering user community
An ontology canbeexpressed as concepts,relationships,andrules thatgovern howthe conceptsare related to one another [7], [8]. Ontology Models describe the following::Objectsand events (entities)inadomain.Relationshipsbetweenobjectsand events:Use of objects and events inside and outside the boundary of the the domain, and.Rules that govern the entities' existence and behavior.In the following sections, we discuss the need for and benefits of an ontology, an ontologymodeling technique, the methodology to capture a systems engineering ontology, and a systemsengineering functional domain ontology model. System of systems (SoS) engineering is an emergingarea within systems engineering. In addition to the need for a systems engineering ontology, anontology is required to describe the SoS engineering (SoSE) discipline. This paper will discuss thejustification for, intent, and preliminary plans to develop an SoSE ontology.This intended SoSEontology will provide structured information to the SE research and user community.The SoSEontology will be further extended to consider additional scope and additional viewpoints2.The need for an se and sose ontologiesSystems engineering is an evolving discipline, The discipline lacks a clear roadmap for itsimprovement given the multiple standards and perspectives involved.The discipline requires commonterminology and common perspectives so that comparison can be made. An ontology of the SEdomain will be helpful to the users and research community. Intellectual content of the SE domain is,of course, very important. One of the three elements that comprise intellectual content is a systemsengineering ontology [9]. Among others, Eric Honour & Ricardo Valerdi [10] and Madni et al. [11]discuss the need for systems engineering ontologies.3.Benefits of an se and sose ontologiesOntologies are being constructed for a growing number of engineering, manufacturing, andscientific domains [8]. Many benefits can be realized on a global scale with such ontologies in place,for example: standardized terminology with precise meanings that are fixed across industries andacross international borders, and the ability to access and reuse a huge number of ontologies in thedesign and construction of new systems [8]. Central products of this effort include the Knowledge
An ontology can be expressed as concepts, relationships, and rules that govern how the concepts are related to one another [7], [8]. Ontology Models describe the following: Objects and events (entities) in a domain Relationships between objects and events Use of objects and events inside and outside the boundary of the the domain, and Rules that govern the entities' existence and behavior. In the following sections, we discuss the need for and benefits of an ontology, an ontology modeling technique, the methodology to capture a systems engineering ontology, and a systems engineering functional domain ontology model. System of systems (SoS) engineering is an emerging area within systems engineering. In addition to the need for a systems engineering ontology, an ontology is required to describe the SoS engineering (SoSE) discipline. This paper will discuss the justification for, intent, and preliminary plans to develop an SoSE ontology. This intended SoSE ontology will provide structured information to the SE research and user community. The SoSE ontology will be further extended to consider additional scope and additional viewpoints. 2. The need for an se and sose ontologies Systems engineering is an evolving discipline. The discipline lacks a clear roadmap for its improvement given the multiple standards and perspectives involved. The discipline requires common terminology and common perspectives so that comparison can be made. An ontology of the SE domain will be helpful to the users and research community. Intellectual content of the SE domain is, of course, very important. One of the three elements that comprise intellectual content is a systems engineering ontology [9]. Among others, Eric Honour & Ricardo Valerdi [10] and Madni et al. [11] discuss the need for systems engineering ontologies. 3. Benefits of an se and sose ontologies Ontologies are being constructed for a growing number of engineering, manufacturing, and scientific domains [8]. Many benefits can be realized on a global scale with such ontologies in place, for example: standardized terminology with precise meanings that are fixed across industries and across international borders, and the ability to access and reuse a huge number of ontologies in the design and construction of new systems [8]. Central products of this effort include the Knowledge
Interchange Format (KIF) [1], a text-based logical language for the interchange of knowledge [8], andOntolingua [14], a mechanism built using KIF for translating knowledge between differentrepresentation languages. Ontological analysis and development have been shown to be useful for: (i)consensus building,(ii) object-oriented design and programming,(ii) component based programming,(iv) user interface design, (v) enterprise information modeling, (vi) business process reengineering.and (vi) conceptual schema design [8]4.Ontologymodelingtechnique selectionThe primary goal of the Ontology Description Capture method [8] is to provide a structuredtechnique, supported by automated tools, by which a domain expert can effectively develop andmaintain usable and accurate domain ontologies.Over the last few decades numerous conceptualmodeling techniques, used to define requirements for building information systems,processes,activities, etc. have emerged with no consistent theoretical foundation underlying their conception ordevelopment [14]. Concerned that this situation would result in the development of models that wereunable to completely capture important aspects of the real world, Wand and Weber developed andrefined a set of models [15], [16], [17] based on an ontology defined by Bunge [18] for the evaluationof modeling techniques. These models are referred to as the Bunge-Wand-Weber (BWW) models [15]ortheBWW ontology.There is handful of tools used for ontology modeling. The first tool used in ontology modeling wasPetri Nets in 1962. The most recent developed tools or methods applied to define ontologies includeBPMN, UML, Protege IDEF3 and IDEF5, among others. These multiple tools or methods (e.g. UML,Protege and IDEF5) have been designed to allow knowledge sharing, and can each be used to definean ontology with no one tool necessarily better than another. As Mr. John Zachman in his seminalwork on information systems architecture observed, ".. there is not an architecture, but a set ofarchitectural representations. One is not right and another wrong. The architectures are different andthey are additive, complementary to each other" [19]. Interested readers may refer to TheDevelopment of a Design Ontology for Products and Processes [14] for a history of the the use ofvarious ontology constructs using all available tools/methods since 1962.Most notably, the IDEF5 elaboration language is the central medium for storing ontologyinformation collected via the IDEF5 method. This method uses KIF as its foundation to foster thecrucial objective of knowledge sharing.IDEF5 was developed in the belief that it could contribute in a
Interchange Format (KIF) [1], a text-based logical language for the interchange of knowledge [8], and Ontolingua [14], a mechanism built using KIF for translating knowledge between different representation languages. Ontological analysis and development have been shown to be useful for: (i) consensus building, (ii) object-oriented design and programming, (iii) component based programming, (iv) user interface design, (v) enterprise information modeling, (vi) business process reengineering, and (vii) conceptual schema design [8]. 4. Ontology modeling technique selection The primary goal of the Ontology Description Capture method [8] is to provide a structured technique, supported by automated tools, by which a domain expert can effectively develop and maintain usable and accurate domain ontologies. Over the last few decades numerous conceptual modeling techniques, used to define requirements for building information systems, processes, activities, etc. have emerged with no consistent theoretical foundation underlying their conception or development [14]. Concerned that this situation would result in the development of models that were unable to completely capture important aspects of the real world, Wand and Weber developed and refined a set of models [15], [16], [17] based on an ontology defined by Bunge [18] for the evaluation of modeling techniques. These models are referred to as the Bunge-Wand-Weber (BWW) models [15] or the BWW ontology. There is handful of tools used for ontology modeling. The first tool used in ontology modeling was Petri Nets in 1962. The most recent developed tools or methods applied to define ontologies include BPMN, UML, Protégé IDEF3 and IDEF5, among others. These multiple tools or methods (e.g. UML, Protégé and IDEF5) have been designed to allow knowledge sharing, and can each be used to define an ontology with no one tool necessarily better than another. As Mr. John Zachman in his seminal work on information systems architecture observed, “. there is not an architecture, but a set of architectural representations. One is not right and another wrong. The architectures are different and they are additive, complementary to each other” [19]. Interested readers may refer to The Development of a Design Ontology for Products and Processes [14] for a history of the the use of various ontology constructs using all available tools/methods since 1962. Most notably, the IDEF5 elaboration language is the central medium for storing ontology information collected via the IDEF5 method. This method uses KIF as its foundation to foster the crucial objective of knowledge sharing. IDEF5 was developed in the belief that it could contribute in a
vital way to the realization of the vision of global knowledge sharing.The IDEF5 method fulfills animportant need by providing a cost-effective mechanism to acquire, store, and maintain scaleable andre-usable ontologies [20]. IDEF5 guides and assists domain experts and knowledge engineers in theconstruction of both small and large reusable ontologies.In comparingIDEF5with other availableontologymodelingtools,IDEF5isverysuitableforrepresentinganontologybecauseofitsgraphicalrepresentation and KIF. IDEF5 will be applied to develop the ontologies described in this paper.5.SE ontologymethodologydesignA well-structured methodology is essential to capture essential systems engineering knowledge inorder to develop a systems engineering ontology. This methodology must meet the particular ontologydevelopment needs. Various ontology authors use different steps to build their ontology. For exampleRicardo Calmeta mentions four steps [21], Natalya & Deborah McGuinness identifies seven steps [22]and Benjamin et al. discusses five steps [8] to build their ontologies.All of the above-mentioned methodologies do not completely meet the need for a systemsengineering ontology. They fail to ensure the consistency and accuracy of captured knowledge, do nothave provisions to explore similar ontologies for reuse, or do not incorporate lessons learned andmake these lessons available for others to use. The Domain Knowledge Acquisition Process (DKAP)[14] methodology is able to handle these identified deficiencies. DKAP was successfully used todevelop an ontology model of generic products and processes [14]. The steps of the DKAPmethodology are slightly different from other ontology building approaches. DKAP has nine majorsteps. Figure 1 shows the nine steps and their sequenceHighlihts of each of the major steps are described in thefollowing subsections.Additional detailrelated to the steps can be found in Sarder [14]5.1Determine the purpose, domain, & scope of the ontologyThis activity establishes the purpose, viewpoint, and context for the ontology development projectand assigns roles to those involved in a project (e.g. team members). The purpose defines the domain.Once the purpose of the effort has been characterized, it is possible to define the context of the projectin terms of 1) the scope of coverage, and 2) the level of detail for the ontology development effortThe scope defines the boundaries of the domain and specifies which parts of the system need to beincluded and which aretobeexcluded
vital way to the realization of the vision of global knowledge sharing. The IDEF5 method fulfills an important need by providing a cost-effective mechanism to acquire, store, and maintain scaleable and re-usable ontologies [20]. IDEF5 guides and assists domain experts and knowledge engineers in the construction of both small and large reusable ontologies. In comparing IDEF5 with other available ontology modeling tools, IDEF5 is very suitable for representing an ontology because of its graphical representation and KIF. IDEF5 will be applied to develop the ontologies described in this paper. 5. SE ontology methodology design A well-structured methodology is essential to capture essential systems engineering knowledge in order to develop a systems engineering ontology. This methodology must meet the particular ontology development needs. Various ontology authors use different steps to build their ontology. For example Ricardo Calmeta mentions four steps [21], Natalya & Deborah McGuinness identifies seven steps [22] and Benjamin et al. discusses five steps [8] to build their ontologies. All of the above-mentioned methodologies do not completely meet the need for a systems engineering ontology. They fail to ensure the consistency and accuracy of captured knowledge, do not have provisions to explore similar ontologies for reuse, or do not incorporate lessons learned and make these lessons available for others to use. The Domain Knowledge Acquisition Process (DKAP) [14] methodology is able to handle these identified deficiencies. DKAP was successfully used to develop an ontology model of generic products and processes [14]. The steps of the DKAP methodology are slightly different from other ontology building approaches. DKAP has nine major steps. Figure 1 shows the nine steps and their sequence. Highlihts of each of the major steps are described in the following subsections. Additional detail related to the steps can be found in Sarder [14]. 5.1 Determine the purpose, domain, & scope of the ontology This activity establishes the purpose, viewpoint, and context for the ontology development project and assigns roles to those involved in a project (e.g. team members). The purpose defines the domain. Once the purpose of the effort has been characterized, it is possible to define the context of the project in terms of 1) the scope of coverage, and 2) the level of detail for the ontology development effort. The scope defines the boundaries of the domain and specifies which parts of the system need to be included and which are to be excluded
Itis importanttoestablishviewpointstodeveloptheontology.Establishingviewpointsisrelatedtothe purpose of developing the ontology. For instance, the SE team will use a systems engineeringontology,henceit is appropriatetoestablishviewpointswithrespecttotheSEteam.DetermineDomain&Scope of OntologyRe-useAs IstorWithIsItMinorModificationAvailableOrgantze the ProjectCollect&Analyze Data9OntologyRepository5 Develop Initial OntologyRefine &ValidateOntologyIncorporateLessonsIsItLeaned&PublishConsistent8OntologyollectAdditionalData&Analvze Data5.2Checkavailabilityofexistingontologies
It is important to establish viewpoints to develop the ontology. Establishing viewpoints is related to the purpose of developing the ontology. For instance, the SE team will use a systems engineering ontology, hence it is appropriate to establish viewpoints with respect to the SE team. 5.2 Check availability of existing ontologies