Developing Ontologies for Interoperability of Systems of Systems *

Transcription

1 Paper #131 Developing Ontologies for Interoperability of Systems of Systems * John S. Osmundson Departments of Information Sciences and Systems Engineering 1 University Circle Monterey, CA josmundson@nps.edu Thomas V. Huynh Department of Systems Engineering The Naval Postgraduate School 1 University Circle Monterey, CA thuynh@nps.edu Paul Shaw Functional Data Manager (FDM) Navy Command, Control, and Communications (C3) Space and Naval Warfare Systems Command 4301 Pacific Highway San Diego, CA paul.shaw@navy.mil * Work is supported in part by a contract from the Office of the Undersecretary of Defense Acquisition, Logistics and Technology (OUSD AT&L), facilitated by the Systems of Systems Engineering Center of Excellence (SOSECE). Abstract Engineering of systems of systems must meet, among other challenges, the information interoperability requirements. In this research we develop ontologies and employ process modeling (Osmundson 2004) to engineer a system of systems with robust information interoperability. Ontological engineering is an approach that has been used successfully to solve system of systems information interoperability requirements in number of different application domain areas. There are numerous ways to develop ontologies and recent applications of the Unified Modeling Language (UML) for ontology representation indicate convergence of UML and ontologies (Kogut et al 2002). In this work we represent a system of systems in a UML-like representation from which we develop an ontology to support information interoperability. Introduction There is increasing interest in what has become known as systems of systems engineering. (Quinlan 2005) Here we assume that system elements in a system of system have been

2 independently engineered as stand-alone systems, and there is an interest in forming a system of systems from the previously independently developed elements. The desire is to have existing systems interoperate to produce a new capability, a new product or a new service that exceeds the capabilities of a single system or a limited number of systems in the system of systems construct. Systems in a system of systems must interact by exchanging items such as physical items, energy, or information in order to produce new products, information, services or other end results. Therefore, two questions of interest arise when engineering a system of systems: To what extent are the existing systems capable of item interchanges; in other words to what extent are the systems interoperable? To what extent can the existing systems be made interoperable through the addition of interfaces? One approach to answering these questions for information systems of systems is through the enabling technology of ontologies. In this paper we describe a systems engineering methodology using a UML-like representation of the system of systems. UML assists us to understand objects, actors, interactions and core terms from which we can develop the required elements of system of systems ontologies to support information interoperability. System of Systems Engineering Methodology We have developed an approach for engineering a system to be formed from pre-existing systems (Osmundson and Huynh 2005). This approach includes developing operational scenarios and operational architectures, describing threads of operation, representing operational architectures in a UML-like format, identification of system design parameters and factor levels, transformation of UML-like format representation into executable models, and application of design of experiments to perform architectural tradeoffs. Operational architectures have a close relation to use cases in UML. Operational architectures of a system of systems describe the interactions that a users will have with the individual systems and the overall system in order to achieve certain goals. Threads of operation are event specific traces of the time-ordered exchanges of items between systems. Figure 1 represents a system of systems consisting of systems 1, 2 and 3 arranged to show a thread of interactions with time. This view of system-of-system interactions is analogous to swim lane diagrams in the Unified Modeling Language (UML) (Arlow and Neustadt 2005). Time increases to the right along the horizontal axis in Figure 1. Element A of system 1 and element C of system 3 interact with system 2 by passing items to element C of system 2. Later element F of system 2 interacts with element B of system 1 through the passing of items. Examples of elements of systems could include organizations of people, processing systems, communication systems, production systems or transportation systems that interact to produce information, products or to transport things. 2

3 System 1 Element A System 2 System 3 Element C In an information system, for example, the directed arrows on Figure 1 represent information items and the graphical view of the system would indicate information exchange requirements needed for interoperability. The requirements for interoperability of information systems include: A means of system-to-system connectivity; a common language; a common grammar; a common set of meanings in given contexts; and operational time lines that assure that information is never time late. We assume that the individual systems of an information system of systems have been previously separately engineered so that interoperability requirements are not necessarily met without new interfaces. Focusing on the requirements for common language, grammar and meanings, a preferred approach would be to have all systems interact through a common interface. This interface can be created through the use of multiple layers of ontologies. The advantage of this approach is that it is scalable as other systems are added to the system of systems. Ontologies Element C Time Element F Element B Figure 1. Graphical View of System of System Interactions in a UML-Like Format One means of achieving information interoperability using a common interface is through the use of ontologies. An ontology has been defined (Studer et al, 1998) as a formal, explicit specification of a shared conceptualization. Conceptualization refers to an abstract model of some phenomenon in the world by having identified the relevant concepts of that phenomenon. Explicit means that the type of concepts used, and the constraints on their use are explicitly defined. Formal refers to the fact that the ontology should be machine-readable. Shared reflects the notion that an ontology captures consensual knowledge, that is, it is not private of some individual, but accepted by a group. In this paper we are focusing on an ontology to describe the vocabulary of terms and some specification of the meaning of the terms required for interoperability of a system of systems. An ontology is an enabling technology that models the vocabulary and meaning of data domains, the objects in the domains, relationships among objects, properties, function and processes involving those objects and constraints and rules about the objects. An ontology defines a core lexicon, taxonomy, data dictionary and data schema. UML modeling allows us to identify the key objects and the interactions between them, which become our ontology classes, the properties of those classes, core vocabulary, and the assertions on that vocabulary. 3

4 Ontologies permit fine, accurate, consistent, meaningful distinctions to be made between classes, instances, properties, attributes and relations in the data domain. The extent that ambiguity in the data can be resolved is the limit to how far the ontology can be developed. If ambiguity exists in the data, classes, or their relationships, ontological development will be stopped. This limit of ontology development will be a key concept that we return to in the development of ontologies with our UML modeling. Ontological engineering is an approach that has been used successfully to solve system of systems information interoperability requirements in number of different application domain areas, including medical field (Unified Medical Language System), mathematical modeling in engineering (Gruber 1994), U.S. Department of Defense strategic command and control (Diggs 2004), and NATO command, control and intelligence systems interoperability (Mandutianu 2004). There are numerous ways to develop ontologies (Gomez-Perez 2004). Gruber (1993a) proposes to model ontologies using frames and first order logic. He identifies five kinds of components: Classes, relations, functions, formal axioms and instances. Classes represent concepts and classes are usually organized in taxonomies through which inheritance mechanisms can be applied. Relations represent a type of association between concepts of the domain. Functions are a special case of relations. Formal axioms serve to model sentences that are always true. Instances represent elements in an ontology. Uschold and King s method (Uschold and King 1995), later extended by Uschold and Gruninger (Uschold and Gruninger 1996), includes the ideas of identifying concepts in the ontology by using bottoms-up, top-down and middle-out domain analysis strategies. Recent applications of the Unified Modeling Language (UML) for ontology representation indicate convergence of UML and ontologies. Since we adopt a UML-like representation of system of systems, it is a natural extension to our system of systems engineering approach to adopt UML for system of systems ontology representation. UML helps us to understand how the various ontologies of the different systems are to interact to perform the desired mission or series of actions for a desired effect. The key to using UML for the development of system of systems ontologies is not to try to develop one single ontology for the mission, but instead from the UML modeling to understand how the various systems need to interact for interoperability and mission accomplishment. A key concept in our development of interoperability is that different ontology layers will be needed to achieve the desired interoperability and mission accomplishment. The other key concept in UML is that we have an understanding of the actors and classes. Figure 2 shows how the ontology layers can work together for accomplishment of the desired effect. An understanding of this interaction is what allows some simplification of the ontologies at the different layers and leverages the fact that the UML will call out the different layers. Additionally the SoS modeling helps to identify the core lexicon items. We are not suggesting that UML will be all that is needed for the development of the ontologies, as UML lacks mechanisms that provide restriction on domain semantics. This can be overcome by augmenting UML with object constraint language (OCL) (OCL 1997). The 4

5 advantage of UML representations is that systems engineering analysis artifacts lead directly to development of an appropriate ontology and data interoperability to accomplish the mission or Domain Ontology Language Translator Mission Ontology Sub-mission Taxonom Activity Contextual Meaning Instance Ontology Lexicon Engine Figure 2. Ontology Layers create the desired effect, without requiring additional system views. The systems are actors in the use cases for the mission and present out their data to be used in context of the mission. Figure 3 provides a further breakdown of the different elements in the completion of a mission that describe how SoS modelling allows for the development of the ontologies at the different levels of domain (Maritime Domain Protection), mission (Prevent Transport of Weapons of Mass Destruction), and instance (a system ontology for a particular sensor). Data is flowing between all levels of the figure. The UML use cases call out the desired actions by the different actors and classes of objects for the accomplishment of the mission. This breakdown accommodates that a particular system or sensor does not have to know how it will be used, just provide context for its data. The mission ontology will be developed with the activities (that humans will perform) for the mission along with the systems that are desired to support the mission. It does not imply that all systems will create services, but instead systems will provide functions that either create a service or support the activities of a human. A key element of this approach is the ease with which additional systems can be quickly added to enable the performance of a mission. The classification of information around the who, how, what, where, when and why relate back to the modelling that the UML will provide. 5

6 Who, How, What, Where, When, Why Mission Capability Mission Ontology Activity Service Semantic Web (m2m information Function System Instance Ontologies Workload Element Library Skill Object System Design Task Figure 3. Different Elements in the Completion of a Mission Maritime Domain Protection Example We illustrate the development of the ontology layers of a system of systems with a coalition maritime domain protection system consisting of a collection of stand-alone sensors, processing centers, and fusion centers that are designed to operate as separate U.S. and coalition partner systems as well as operating in a larger coalition system of systems. This type of system of systems could also represent a grouping U.S. Navy, U.S. Coast Guard and local organization systems working together for U.S. maritime domain protection. The independent systems are assumed to interface through a common network (possibly presenting their data as a network service with an instance ontology of the system), using a publish-and-subscribe architecture for information exchange. According to our system of systems engineering methodology an initial step is to develop operational scenarios. There is a large number of scenarios applicable to a maritime domain protection system, but, for purposes of illustration, we will consider a scenario in which a ship carrying a weapon of mass destruction enters the area of regard of the maritime domain protection system. The following step is to identify use cases, such as, for this example, DetectShip, TrackShip, CompareManifest, and AlertResponder, in the different ontology layers for completing the mission of possibly discovering a ship carrying a weapon of mass destruction and alerting a responder team for investigation. For illustration, Figure 4 shows only the DetectShip use case. 6

7 Use case: DetectShip ID: 1 Brief Description: Detect ships during transit of the area of regard. Primary actors: Sensors Secondary actors: Sensor Platforms Preconditions: 1. Sensor is scanning the area of regard. Main flow: 1. The use case starts when a sensor detects a ship. If the sensor is platform based, then the platform must be operating and in position to allow the sensor to scan the area of regard.2. The sensor system sends a data stream to a processing center via a network. Post conditions: 1. The processing center receives the sensor data. 2. The sensor continues surveillance of the area of regard. Alternative flows: None. Figure 4. Detect Ship Use Case After a set of use cases has been identified the use cases are analyzed to determine potential objects or concepts for the maritime domain system of systems. Figure 5 shows a concept diagram resulting from identifying 16 primary uses cases, selecting the concepts in the use case descriptions essential for system interoperability, and determining the relationships between the concepts. Several assumptions are made in the process leading to the development of this concept diagram. External sensors such as airborne or satellite sensors as well as inputs from human intelligence (HUMINT) are postulated to be linked to the system. Separate ontologies were assumed for sensors, sensor processing, fusion and command and control. This concept diagram forms a basis for developing an ontology for the example scenario involving a ship carrying a weapon of mass destruction. Object constraint language (OCL) expressions can be attached to elements of the concept model to describe constraints such as preconditions or post conditions that might apply. For example the attribute time tag associated with model elements can be defined as time of detection by sensor or time of data transmission, as appropriate. External Sensor Cue HUMINT Cue MDP Sensor Type Detection data Ontology Time tag Detects Ship Position Heading Speed ID External Intel Network Processing Network load Center Terrorist Alert Ontology Processing Fusion C2 Node Center Center Ontology Ontology Ontology Commands Develops Infers Responder Anomaly Position Ship Track Type Intercept point Track # Intercept time Position Triggers Range Heading Alert Capabilities Speed Update Database Weather Processing Center Weather alert Manifest Cargo Owners Crew Registry Deck plans Previous ports of call Engages Figure 5. Maritime Domain Protection Concept Diagram 7

8 Example Ontology Objects, attributes and object relationships that are developed using UML can be translated into machine readable form by utilizing an ontology language, such as resource description language (RDF,) that is based on the same idea of identifying objects in terms of properties, property values and property relationships as is UML. Therefore, an ontology developer can use the UML artifacts developed as part of our system of systems engineering methodology as guidelines for developing the ontology code. A snippet of an example class tree for a Mission Ontology of Combating Transport of WMD (CombatingTransportofWMD) follows, based on the concept diagram shown on Figure 5. In this ontology, ship manifests will be examined by content and vendor for irregularities. This is just a portion of the entire class tree that will be developed for this mission. This class tree displayed in RDF provides a common framework for expressing this mission information in a machine readable form that can be used by different applications without loss of meaning. Note some of the links are fictitious and for illustration purposes only. <rdf:rdf xmlns:owl=" xmlns:fips-10-4-ont=" xmlns:ucp=" xmlns:fips=" xmlns:rdfs=" xmlns:rdf=" xmlns:ucp-2003=" xmlns:milservices-ont=" xmlns:xsd=" xmlns:dc=" xml:base=" <owl:class rdf:about="#combatingtransportofwmd"> <rdfs:comment>defined in International Treaty</rdfs:comment> <rdfs:subclassof> <owl:restriction> <owl:onproperty rdf:resource="#homepage"/> <owl:allvaluesfrom> <rdfs:datatype rdf:about="&xsd;anyuri"/> </owl:allvaluesfrom> </owl:restriction> </rdfs:subclassof> <rdfs:subclassof> <owl:restriction> <owl:onproperty rdf:resource="#homepage"/> <owl:cardinality Conclusion This illustration underlines a feasible approach to developing a system of systems with information interoperability enabled by system of systems ontologies at different levels to accomplish a mission or achieve a desired effect. Key aspects of the ontologies such as classes, properties, taxonomy, core lexicon, data guidelines, and data procedures were identified by the developer of the ontology through the use of UML. We will extend this work by representing a system of systems in System Modeling Language (SysML 2005) and by using object constraint language to represent constraints between the classes and properties of the different layer of ontologies.. 8

9 References Arlow, Jim and Ila Neustadt, UML 2 and the Unified Process, Addison-Wesley, Upper Saddle River, NJ, Diggs, Don, Information and Decision, A Strategic Approach for Interoperability. 6 th Annual ONR Workshop on Collaborative Decision-Support Systems Proceedings, Quantico, VA, Sept. 8-9, 2004, pp Gomez-Perez, Asuncion, Mariano Fernandex-Lopez and Oscar Corcho, Ontological Engineering. Springer, London, Gruber, T. R., A Translation Approach to Portable Ontology Specification. Knowledge Acquisition, 5(2), 1994, pp Kogut, Paul, Stephen Cranefield, Lewis Hart, Mark Dutra, Kenneth Baclawski, Mieczyslaw Kokar, and Jeffrey Smith, UML for Ontology Development, The Knowledge Engineering Review, Vo.l 17, No. 1, 2002, pp Mandutianu, Sanda, Information Interoperability Engineering. 6 th Annual ONR Workshop on Collaborative Decision-Support Systems Proceedings, Quantico, VA, Sept. 8-9, 2004, pp OCL Osmundson, John, et al, Process Modeling: A Systems Engineering Tool for Analyzing Complex Systems. Systems Engineering, Vol. 7, No.4, 2004, pp Osmundson, John, and Thomas Huynh, A Systems of Systems (SoS) Systems Engineering Methodology. 1 st Annual System of Systems Engineering Conference Proceedings, Johnstown, PA, June 13-14, Quilan, Robin, Joint Forces Integration. 1 st Annual System of Systems Engineering Conference Proceedings, Johnstown, PA, June 13-14, Studer, R., V. R. Benjamins, and D. Fensel, Knowledge Engineering: Principles and Methods. IEEE Transactions on Data and Knowledge Engineering, 25 (1-2), pp , SysML Partners, 2005 Systems Modeling Language (SysML) Specification, Version 0.9, January, Unified Medical Language System 9

10 Uschold, M. and M. King, Towards a Methodology for Building Ontologies. IJCAI 95 Workshop on Basic Ontological Issues in Knowledge Sharing, D. Skuce editor, Montreal, Canada, 1995, pp Uschold, M. and M. Gruninger, Ontologies: Principles, Methods and Applications. Knowledge Engineering Review, 1996, Vol. 11, No. 2, pp Biographies John Osmundson is an Associate Professor with a joint appointment in the Systems Engineering and Information Sciences Departments at the Naval Postgraduate School in Monterey, CA. His research interest is applying systems engineering and computer modeling and simulation methodologies to the development of system architectures, performance models, and system trades of time-critical information systems. Prior to joining the Naval Postgraduate School in 1995 Dr. Osmundson worked for 23 years at Lockheed Missiles and Space Company (now Lockheed Martin Space Division) in Sunnyvale and Palo Alto, CA as a systems engineer, systems engineering manager, and manager of advanced studies. Dr. Osmundson received a B.S. in physics from Stanford University and a Ph.D. in physics from the University of Maryland. Tom Huynh is an Associate Professor of Systems Engineering at the Naval Postgraduate School in Monterey, CA. His research interests include algorithm developments, nonlinear estimation, optimization, simulation-based acquisition, system scaling, uncertainty management in systems engineering, and complex systems. Prior to joining the Naval Postgraduate School, Dr. Huynh was a Fellow with the department of Modeling & Simulation and Information Sciences at the Lockheed Martin Advanced Technology Center. He was also a lecturer in the Mathematics department at San Jose State University. Dr. Huynh obtained simultaneously a BS in Chemical Engineering and a BA in Applied Mathematics from UC Berkeley and an MS and a PhD in Physics from UCLA. Paul Shaw is a civilian with the Space and Naval Warfare Systems Command (SPAWAR) and a Navy Reserve Captain. He is the Navy s Functional Data Manager (FDM) for Command, Control, and Communication (C3) applications. In the Navy Reserve, he is a commanding officer and national mission lead for forward deployed combat repair, with deployed detachments in Al Asad, Iraq. As the C3 FDM, he is the Navy s C3 application portfolio manager and works on system interoperability and data modeling. Prior to government service, he was the President of a start-up company commercializing military technology for first responders. Additionally, he served as a CIO and a VP of a Technology Licensing Firm. He graduated from the Naval Academy and has two business Masters from San Diego State University. He is completing a Masters in Software Engineering from Naval Postgraduate School. He is a Certified Software Development Professional (CSDP) with the IEEE. 10