《系统工程》课程教学资源（英文文献）Developing systems engineering ontologies

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

It is always worth considering models that someone else has created and the associated level ofrefinement. This allows extending existing sources for the systems engineering domain. In somecases, a similar kind of ontology can be derived from the available one. Reusing existing ontologiesmay be a requirement if the system needs to interact with other applications that have alreadycommitted to particular ontologies or controlled vocabularies [8]5.3OrganizetheprojectThis This activity will identify the different tasks to be performed to build the new ontology. Someof the tasks may includeforming the development team breaking down tasks, assigning teammembers to specific tasks, etc.5.4 Collect and analyze dataThe purpose of this activity is to collect the raw data needed for ontology development and analyzethe data to facilitate ontology extraction. The previous work to define the viewpoint(s),context, andpurpose sets the stage for the data-gathering phase of the the ontology captures effort.5.5 Develop initial ontologyThis activity develops a preliminary ontology from the acquired data. In the previous step relevantdata was collected and analyzed. In the development of an initial ontology there is a series of tasksthat depend on the tool to be selected. With the IDEF5 tool, the tasks could include identifying protoproperties, proto relations, proto kinds, classify kinds, properties, and relations.5.6Refine and validateontologyThis activity will refine and validate the ontology to complete the development process. Therefinementprocess isessentiallyadeductivevalidationprocedure:theontological structures aretestedwith actual data, and the result of the instantiation is compared with the ontology structure. If thecomparison produces mismatches, every mismatch must be adequately resolved5.7 Check consistency & accuracy of ontologyThis activity will ensure the accuracy and consistency of captured knowledge. Once the ontologybuilding is complete, it is necessary to check the consistency and accuracy of the capturedinformation. This consistency check can be done by the help of a consistency matrix [14]. The

It is always worth considering models that someone else has created and the associated level of refinement. This allows extending existing sources for the systems engineering domain. In some cases, a similar kind of ontology can be derived from the available one. Reusing existing ontologies may be a requirement if the system needs to interact with other applications that have already committed to particular ontologies or controlled vocabularies [8]. 5.3 Organize the project This This activity will identify the different tasks to be performed to build the new ontology. Some of the tasks may include forming the development team breaking down tasks, assigning team members to specific tasks, etc. 5.4 Collect and analyze data The purpose of this activity is to collect the raw data needed for ontology development and analyze the data to facilitate ontology extraction. The previous work to define the viewpoint(s),context, and purpose sets the stage for the data-gathering phase of the the ontology captures effort. 5.5 Develop initial ontology This activity develops a preliminary ontology from the acquired data. In the previous step relevant data was collected and analyzed. In the development of an initial ontology there is a series of tasks that depend on the tool to be selected. With the IDEF5 tool, the tasks could include identifying proto properties, proto relations, proto kinds, classify kinds, properties, and relations. 5.6 Refine and validate ontology This activity will refine and validate the ontology to complete the development process. The refinement process is essentially a deductive validation procedure: the ontological structures are tested with actual data, and the result of the instantiation is compared with the ontology structure. If the comparison produces mismatches, every mismatch must be adequately resolved. 5.7 Check consistency & accuracy of ontology This activity will ensure the accuracy and consistency of captured knowledge. Once the ontology building is complete, it is necessary to check the consistency and accuracy of the captured information. This consistency check can be done by the help of a consistency matrix [14]. The

detailed steps for the development of a consistency methodology are discussed in Sarder [14].If theconsistency check is acceptable, the ontology will be ready to use5.8 Collect additional dataIf consistency checks, performed in the previous step, identify that the ontology is unacceptableadditional data must be collected and analyzed. The model will be iteratively refined. Consistencychecking will be performed until the ontology meets the acceptable level.5.9Incorporatelessonslearned andpublishontologyThis will allow new findings and new research related to the ontology model to be available toothers. An ontology is expected to be a living entity. It should be capable of incorporating newfindings and lessons learned and should be published in an ontology repository so that others canutilize the new knowledge.6.SEontologyLike other ontologies, a SE ontology consists of domain related terminology entities andrelationships. In this research we have identified an SE functional domain terminology and throughthe DKAP structured process we have identified entities of the domain. SE functional entities aremainly two kinds; SE functions and SE objects. The SE object category identifies entities that directlyor indirectly participate in performing SEfunctions. The taxonomy of SE functional entities areshown in Figure 2.Similarly, relationships between SE functions are also identified. The detailed descriptions of eachof theentitiesand relationships are notpresented dueto space limitations in this paper.However,atop level SE ontology is shown in Figure 3. This figure shows how SE functions are related with otherentities of thedomain

detailed steps for the development of a consistency methodology are discussed in Sarder [14]. If the consistency check is acceptable, the ontology will be ready to use. 5.8 Collect additional data If consistency checks, performed in the previous step, identify that the ontology is unacceptable, additional data must be collected and analyzed. The model will be iteratively refined. Consistency checking will be performed until the ontology meets the acceptable level. 5.9 Incorporate lessons learned and publish ontology This will allow new findings and new research related to the ontology model to be available to others. An ontology is expected to be a living entity. It should be capable of incorporating new findings and lessons learned and should be published in an ontology repository so that others can utilize the new knowledge. 6. SE ontology Like other ontologies, a SE ontology consists of domain related terminology entities and relationships. In this research we have identified an SE functional domain terminology and through the DKAP structured process we have identified entities of the domain. SE functional entities are mainly two kinds; SE functions and SE objects. The SE object category identifies entities that directly or indirectly participate in performing SE functions. The taxonomy of SE functional entities are shown in Figure 2. Similarly, relationships between SE functions are also identified. The detailed descriptions of each of the entities and relationships are not presented due to space limitations in this paper. However, a top level SE ontology is shown in Figure 3. This figure shows how SE functions are related with other entities of the domain

SvsteFigure2.TaxonomyofSEFunctionalEntities7.Developing a sose ontologyThere are multiple researchers that identify that the systems engineering of an individual system isdifferent than the systems engineering required for a system of systems [23]. In particular, Pohlmanargues that that there is both a quantitative as well as a qualitative difference from engineering anindividual system and that terminology in the SoSE arena needs to be clarified [23]. An ontology isrequired that would assist in the capture of these these differences and in resolving the“buzzword"status of the field so that more consistent and clear terminology can be used in the discipline.According to our research, there are no current SoSE ontologies. Given this gap, the researchers planto leverage existing SE ontology research as a basis to create a SoSE ontology. The researchers plan touse the DKAP methodology to develop a SoSE ontology.The researchers will further analyzepreviously captured SoSE literature and knowledge. Using the DKAP methods, the team will identifyentities and relationships including current terms and definitions.The ontology will includedeveloping models and various views of the analyzed data. Constructing multiple views help toencapsulate the SoSE area and distinguish it from SE.8.Conclusions and future research

Figure 2. Taxonomy of SE Functional Entities 7. Developing a sose ontology There are multiple researchers that identify that the systems engineering of an individual system is different than the systems engineering required for a system of systems [23]. In particular, Pohlman argues that that there is both a quantitative as well as a qualitative difference from engineering an individual system and that terminology in the SoSE arena needs to be clarified [23]. An ontology is required that would assist in the capture of these these differences and in resolving the “buzzword” status of the field so that more consistent and clear terminology can be used in the discipline. According to our research, there are no current SoSE ontologies. Given this gap, the researchers plan to leverage existing SE ontology research as a basis to create a SoSE ontology. The researchers plan to use the DKAP methodology to develop a SoSE ontology. The researchers will further analyze previously captured SoSE literature and knowledge. Using the DKAP methods, the team will identify entities and relationships including current terms and definitions. The ontology will include developing models and various views of the analyzed data. Constructing multiple views help to encapsulate the SoSE area and distinguish it from SE. 8. Conclusions and future research

Systems engineering ontologies are required.This paper discusses the development and results fora preliminary SE functional domain ontology. This SE functional domain ontology will continue to berefined over time. This domain ontology can be extended to produce a site specific ontology [8]. TheSE functional domain ontology will be used by the researchers as the basis to develop an SoSEontology.ExternalOrganizationsSEProjectHasPurposeInteractswith&ScopePerformsProjectPerformPerformswithinLifeCycleSystemsSE FunctionsInfluenceProducesPerformsEngineeringBalancesPerformedByMeetsProducesMultidisciplinaryTeamCost, Schedule&PerformanceCustomerNeeDefined in&StakeholdeTermsofExpectationsNewSEKnowledgeFigure 3.Top Level Ontology of Systems Engineering Domain1. International Council on Systems Engineering (INCOSE),"What is Systems Engineering",www.incose.org/practice/whatissystemseng.aspx,2007.2. ANSI/EIA-632, Processes for Engineering a System, American National Standards Institute andElectronicsIndustriesAssociation,1999.3.IEEE 1220-1998,IEEE Standardfor Application and Management of the Systems EngineeringProcess, Institute of Electrical and Electronics Engineers, 01May19984.ISO/IEC-15288, System Life Cycle Processes, International Standards Organization, 2000

Systems engineering ontologies are required. This paper discusses the development and results for a preliminary SE functional domain ontology. This SE functional domain ontology will continue to be refined over time. This domain ontology can be extended to produce a site specific ontology [8]. The SE functional domain ontology will be used by the researchers as the basis to develop an SoSE ontology. Figure 3. Top Level Ontology of Systems Engineering Domain 1. International Council on Systems Engineering (INCOSE), "What is Systems Engineering", www.incose.org/practice/whatissystemseng.aspx, 2007. 2. ANSI/EIA-632, Processes for Engineering a System, American National Standards Institute and Electronics Industries Association, 1999. 3. IEEE 1220-1998, IEEE Standard for Application and Management of the Systems Engineering Process, Institute of Electrical and Electronics Engineers, 01 May 1998. 4. ISO/IEC-15288, System Life Cycle Processes, International Standards Organization, 2000

5.Mil-Std-499C (Draft), Systems Engineering, Draft Prepared for Space and Missiles SystemsCenter, Air Force Space Command from Original Department of Defense, United States of AmericaMil-Std-499B, March 24, 2006.6. Space engineering, System engineering - Part 1: Requirements and Process, ECSS-E-10 Part 1B18 November 2004, ECSS Secretariat, ESA-ESTEC Requirements & Standards Division, Noordwijk,TheNetherlands7.Dragan Djuriae, Dragan Gaseviae, Vladan Devedziae,"Ontology Modeling and MDA", JournalOf Object Technology, Vol. 4, No.1, 20058. Benjamin, Perakath C., Christopher P.Menzel, Richard J. Mayer, Natarajan Padmanaban,"Toward a methodfor Acquiring CIM Ontologies",International Journal of CIM, 8(3),1995,p 225-234.9. Madni, A. M., "The Intellectual Content of Systems Engineering: A Definitional Hurdle orsomethingMore?",INCOSEINSIGHT,October200610. Honour Eric C. and Valerdi Ricardo, "Advancing an Ontology for Systems Engineering toAllow Consistent Measurement", The Proceedings of the Conference on Systems EngineeringResearch, Los Angeles, CA, 2006.11. Madni, A.M., Madni, Carla and Lin Weiwen, "IDEONTMIPPD: An Ontology for SystemsEngineering.Process Design and Management",Proceedings of the1998 IEEE InternationalConference on Systems, Man, and Cybernetics, (San Diego, CA, 1998): 2597-2602.12. Natalya F. Noy and Carole D. Hafner, "The State of the Art in Ontology Design", AmericanAssociation forArtificial Intelligence, 1997:0738-4602.13. Gruber, T. R., Ontolingua: A Mechanism to Support Portable Ontologies, Knowledge SystemsLaboratory Technical Report KSL 91-66, Final Version, Stanford University, 199214. Sarder, MD B., The Development of a Design Ontology for Products and Processes, Universityof Texas at Arlington, 2006.15. Wand, Y. and Weber, R.,"An Ontological Model of an Information System," IEEETransactions on SoftwareEngineering,(16:11),1990,pp.1282-1292

5. Mil-Std-499C (Draft), Systems Engineering, Draft Prepared for Space and Missiles Systems Center, Air Force Space Command from Original Department of Defense, United States of America Mil-Std-499B, March 24, 2006. 6. Space engineering, System engineering - Part 1: Requirements and Process, ECSS-E-10 Part 1B, 18 November 2004, ECSS Secretariat, ESA-ESTEC Requirements & Standards Division, Noordwijk, The Netherlands. 7. Dragan Djuriæ, Dragan Gaševiæ, Vladan Devedžiæ, "Ontology Modeling and MDA", Journal Of Object Technology, Vol. 4, No. 1, 2005. 8. Benjamin, Perakath C., Christopher P. Menzel, Richard J. Mayer, Natarajan Padmanaban, "Toward a method for Acquiring CIM Ontologies", International Journal of CIM, 8(3), 1995, p 225- 234. 9. Madni, A. M., "The Intellectual Content of Systems Engineering: A Definitional Hurdle or something More?", INCOSE INSIGHT, October 2006. 10. Honour Eric C. and Valerdi Ricardo, "Advancing an Ontology for Systems Engineering to Allow Consistent Measurement", The Proceedings of the Conference on Systems Engineering Research, Los Angeles, CA, 2006. 11. Madni, A. M., Madni, Carla and Lin Weiwen, "IDEON™IPPD: An Ontology for Systems Engineering. Process Design and Management", Proceedings of the 1998 IEEE International Conference on Systems, Man, and Cybernetics, (San Diego, CA, 1998): 2597-2602. 12. Natalya F. Noy and Carole D. Hafner, "The State of the Art in Ontology Design", American Association for Artificial Intelligence, 1997: 0738-4602. 13. Gruber, T. R., Ontolingua: A Mechanism to Support Portable Ontologies, Knowledge Systems Laboratory Technical Report KSL 91-66, Final Version, Stanford University, 1992. 14. Sarder, MD B., The Development of a Design Ontology for Products and Processes, University of Texas at Arlington, 2006. 15. Wand, Y. and Weber, R., "An Ontological Model of an Information System," IEEE Transactions on Software Engineering, (16:11), 1990, pp. 1282-1292