JOURNAL OF COMPUTING, VOLUME 4, ISSUE 5, MAY 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.

ORG

134

Repository-Based Architecture to support System of Systems Interoperability

Houda Benali, Narjs Bellamine-Ben Saoud and Mohamed Ben Ahmed
Abstract interoperability is the most important challenge when dealing with system of systems (SoS) architecting. Interoperability became more challenging when dealing with evolving architectures such as SoS architecture. In this paper we present our solution to support two levels of SoSI (SoS Interoperability) Model: programmatic, and constructive. We introduce an architecture that performs the integration of various stakeholders providing programmatic interoperability, and is repositorybased architecture (blackboard architecture) providing constructive interoperability. Index TermsSystem of Systems; Meta-Architecting; Repository-based architecture; Interoperability; Semantic Modeling.

1 INTRODUCTION

the internal structure of the system while the architecture interface is about the externally observable characteristics of the system. System of systems architecture is connector/relationship oriented architecture that emphasizes the interface, communication protocols and composition between the components [4]. In SoS, preexisting, heterogeneous, autonomous, distributed and independently governed systems cannot exchange significant matter and energy. They collaborate only through information exchange. To achieve architecting such a system, all component systems need a global interface to function [5-6]. SoS architecture could be considered as a connector/relationship oriented architecture. Architecting systems of systems differs from architecting monolithic systems. Classical systems architecting concentrates on optimizing individual stand-alone systems, while SoS architecting concentrates on selecting the right collection of systems to satisfy the customer requirements. SoS architecting is an abstract and meta-level process where requirements are fuzzy and uncertain. It is a network-centric, software intensive and people intensive. To architect an SoS we should use a collaborative emergent development that perform the integration of various stakeholders. Another property of SoS architecting is dynamism. In the other hand, stand-alone system architecting is in the domain specific systems level which involves several stakeholders. Architecting a stand-alone system is a controlled and static process. The article is structured as follows. We first define of the concept Systems of Systems by giving an overview of their characteristics. Afterwards, the article describes the challenges when architecting a System of Systems and H. Benali is currently preparing her PhD, on modeling and simulation development and interoperability in the RIADI-GDL Laboratory (research gives an overview of the proposed meta-architecture. In laboratory. the last section, we conclude and present an outlook on N. Bellamine Ben-Saoud is an Associate Professor of computer science at future developments. the (ENSI) and researcher in RIADI-GDL Laboratory (Tunisia).
Mohamed Ben Ahmed is Emeritus Professor at ENSI (University of La Manouba). His main research interests include: Documents Engineering, Automated Multilingual Analysis, Knowledge Engineering, and Ontological Engineering.

EVELOPING complex systems in a short timeframe is becoming a necessity. More organizations are going towards the integration of pre-existing systems and new systems into network-centric, knowledge-based Systems of Systems (SoS). Integration, as declared in [1], is the engineering process that creates or improves information flows between information systems designed for different purposes. What is critical and challenging in this engineering process is that the right data flows in the right form and the right meaning for the receiving system (and the people using it) to interpret the data correctly. These challenges must be addressed from the construction phase of the architecture. Architecture, as defined by ANSI/IEEE Std 1471-2000, is "The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution". Architecting is then the process of structuring a system. Successful architecture development is important as it plays a dominating role in integration of component systems [2]. There are two prevailing kinds of architecture [3]. Component oriented architecture that emphasizes component and capsulation of attributes and functions (e.g., object-oriented systems). And connector/relationship oriented architecture that emphasizes the interface, communication protocols and composition between the components (e.g., service-oriented systems). SoS architecting studies focus on interface mechanisms of the subsystems, which is mainly communication aspects between subsystems. The system architecture concerns

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 5, MAY 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

135

2 SYSTEM OF SYSTEMS DEFINITION AND CHARACTERISTICS

2.1 System of systems definition
The widespread explosion of Web accessible resources has led to new problems on the traditional tasks of query evaluation and efficient data access. In recent years the concept of system of systems (SoS) has emerged as a new approach to solving complex problems. The body of knowledge on SoS is in its infancy. While there have been many discussions, there is not a commonly accepted definition of SoS. Various fields and professions have produced their own definitions, and as such SoS are defined in the context of those fields and professions. Nevertheless, in all of these definitions, systems of systems are defined basing on their characteristics. In [6], the author has derived, from this variety of definitions, the following list of characteristics that he grouped into two levels of granularity, system-level and subsystemlevel characteristics. The author declares that these characteristics apply to all systems, not just systems of systems. Thus, being a system of systems is a matter of de-

gree rather than of kind, and a meter measuring the degree to which a system exhibits these characteristics would be useful to have. Thus, a system of systems is any system that lies towards the high risk ends of the meters for these system and subsystem characteristics. A System of Systems (SoS) is any system that is a relatively large and complex, dynamically evolving, and physically distributed system of pre-existing, heterogeneous, autonomous, and independently governed systems, whereby the system of systems exhibits significant amounts of unexpected emergent behavior and characteristics.

2.2 System of systems characteristics In [6], the author has derived, from this variety of definitions, the following list of characteristics that he grouped into two levels of granularity, system-level and subsystem-level characteristics. Table I gives some definitions of system of systems and subsystems characteristics as proposed by [6].

TABLE 1 SYSTEM-OF-SYSTEMS CHARACTERISTICS

Characteristics Types System characteristics Characteristics
Complexity

Definition
The degree to which a system is difficult for its stakeholders to understand and analyze, especially due to having a large number of components connected by many complicated interfaces

Evolution Negative emergence

The degree to which (in terms of rate and impact) the goals and requirements for a system (and its subsystems) change over time The degree to which the new behaviors and characteristics of a system that result (i.e., emerge) from the interaction of the systems subsystems are detrimental, unintended, and difficult to predict from the behaviors and characteristics of these individual subsystems

Size

The amount or magnitude of the system with regard to a suitable dimension. Depending on the type of system component to be emphasized by the definition, the size of a system can be defined and measured in many of the ways

Variability

the degree to which a single type of system simultaneously exists in multiple variants, versions, or configurations the degree to which the subsystems within a system are independent, stand alone and are individually useful, self-contained, and operationally independent (i.e., neither controlled by nor controlling other subsystems)

Subsystem characteristics

Autonomy

Governance

the degree to which the subsystems of a system are governed (e.g., specified, managed, funded, developed, owned, operated, maintained, and sustained) in a independent, decentralized, and uncoordinated manner.

Heterogeneity

the degree to which the subsystems of a system differ from each other in that they (1) have different goals, objectives, and requirements, (2) have different behavior and characteristics, (3) provide unrelated functionality, (4) belong to different application domains, and (5) are implemented using different technologies

Physical Distribution Reuse

the degree to which the subsystems of a system exist in different physical locations the degree to which the subsystems of the system have been reused regardless as to whether they are commercial-off-the-shelf (COTS), government-off-theshelf (GOTS), military-off-the-shelf (MOTS), organizational-internal reuse, open source, and freeware

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 5, MAY 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

136

3 A META-ARCHITECTURE OF COMMUNICATION: CHALLENGES AND PROPOSED SOLUTION

System of systems architecting process is similar to systems architecting processes but it is at a meta-level. Building such a meta-architecture needs a high level of interoperability and some evolution enablers. We note that the system architectures of the component systems do not play a direct role in the system composition process. Instead, it is the architecture interfaces of the component systems that represent the component systems in the composition process. Consequently, architecting a SoS focuses on connecting subsystems to a global communication architecture. We talk about a meta-architecture of communication where subsystems are presented by their architecture interfaces.

3.1 Challenges Two main challenges when developing a SoS are Interoperability and evolution. a. Interoperability challenge There are three levels of interoperability, as presented in the SOSI report [7]. A good architecting process must cover all these levels of interoperability: - Operational interoperability is closely aligned with the traditional definition of interoperability (the ability of systems to exchange relevant information), but it adds the notion of compatible (or complementary) operational concepts. - Constructive interoperability reflects the degree to which the different system design, engineering, and production processes and tools are able to exchange information in an understandable manner. - Programmatic interoperability expresses the ability of programs to exchange meaningful information about the management of the programs involved. This information can run the gamut from budget and schedule information to details on how to interpret risks. b. Evolution challenge In system of systems, the evolution is unavoidable and has become one of the main challenges facing SoS architecting. Development is evolutionary and adaptive over time, and where structures, functions, and purposes are added, removed, and modified as experience of the community with the individual systems and the composite system grows and evolves [8]. In general, a system evolution occurs when any of the following three basic situations happens [5]: - A change is introduced into a system as a consequence of redesign, redevelopment, modification or improvement, i.e., the evolution of a stand-alone system; - Two or more systems are integrated for improved business support; or - A new system is developed on the basis of existing systems with new functionalities or capabilities. c. Semantic Modeling The most important characteristics of a good SoS architecture are meaningful interoperability.

Meaningful interoperability between different systems that are operationally and managerially independent means exchange of relevant data between these systems. Data have structure and meaning. Relevant data should have clear description of the structure and clear definition of the meaning. Therefore, a SoS should have the potential not only to store vast amount of information, but also should be able to process the stored information that match content and meaning. We are talking about knowledge mining techniques that facilitate intelligent processing of stored data to discover semantic information. When dealing with meaning representation, a detailed study of semantic modeling is needed. Semantic modeling provides a richer data structuring capability for knowledge mining. In this section we present a brief definition of the most important semantic modeling techniques that are based on formal notations. Ontology An Ontology is the highest level of abstraction of the conceptual and semantic representation in a given knowledge domain, the Ontology Definition Metamodel (ODM) (www.omg.org/docs/ad/05-08-01.pdf). Four categories were suggested by [9] to classify ontologies: static, dynamic, intentional, and social. Ontologies that fall into the static category focus on things and their properties. Dynamic ontologies extend static ontologies to focus on such concepts as events and processes that is, how concepts in the real world change over time. Intentional ontologies attempt to explain abstract concepts like goals and objectives while social ontologies emphasize the concepts of values and beliefs. Nicola Guarino defines ontology as logical theory accounting for the intended meaning of a formal vocabulary and gives a formal representation of ontologies [10]. Latent Semantic Analyses Latent Semantic Analysis (LSA) is a theory and method for extracting and representing the contextual-usage meaning of words by statistical computations applied to a large corpus of text [11]. LSA is a fully automatic mathematical/statistical technique for extracting and inferring relations of expected contextual usage of words in passages of discourse [12]. DNA Computing The DNA memory is a searchable database of information stored in the sequences of a collection of DNA molecules. It is also a DNA computer that can do computations on the stored data by manipulating the contents of the test tube [13]. DNA memory construction is done by applying a four step process, as proposed in [13]: - Mapping records onto DNA sequences (coding strands); - DNA memory architecting. In this step, methods to search, retrieve and manipulate information stored in DNA are defined; - Defining protocols to process the queries strands for retrieval of information based on context and content; - Reading and converting back the output of the DNA memory into a readable format. DNA memory is formally defined as formal contexts and

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 5, MAY 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

137

concepts [14]: - Formal context: A formal context K=(O, A, I) consists of a set of objects O and attributes A, where I O x A (denoted oIa which means o has attribute a) - Formal concept: A formal concept of the context (O, A, I) is a pair (B, C) where B O, C A, C = B:={a A | oIa o B}, and B= C:={o O | oIa a C}

3.2 Proposed Solution This section presents our proposed solution to support programmatic and construction levels of SoSI model as depicted in figure 1. This paper presents the overall proposed solution without going into details of real implementation. It is about proposing a process for SoS construction.

Fig. 1. the proposed Meta-architecture to support programmatic and constructive levels.

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 5, MAY 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

138

a. Programmatic Level Programmatic level deals with solutions to support collaboration between organizational entities in SoS. In the context of SoS, many organizations must collaborate and coordinate efforts to achieve the SoS goal. Organizational entities could encompass one or many of these entities [15]: - Global system-of-systems entity represents the global capabilities; - Autonomous (or semiautonomous) constituents are entities with distinct management authorities. They can work with a degree of independence. - Funding organizations like appropriations committees - Oversight organizations like standard bodies - Contractual organizations Such collaboration necessitates a clear comprehension of organizational entities relationships. In [15] authors proposed the use of different Interoperability Maps: - Context Interoperability Map represents the view point of a represents the viewpoint of the system-ofsystems global entity responsible for the overall system of systems. - Node-centric Interoperability Map represents the standpoint of a constituent (what is visible to the constituent). This map is used in complex situations to analyze inconsistencies and conflicts between what one constituent believes to be important and what other constituents believe to be important. - Arc-centric Interoperability Map is used when relationships are complex or easily misunderstood. It makes explicit the assumptions that go into an influence relationship. A clear representation of the organizational entities relationships facilitates decision making. When architecting a SoS, the interoperability maps could be used in conjunction with decision matrix or with theory of social choice when making a joint decision. Context Interoperability map could be used to identify stakeholders. Subsystems in a SoS are managerially independent. The individual program managers have a high degree of autonomy. Nevertheless, they arent free to make decisions

that adversely affect other portions of the system of systems. Decisions affecting other program offices should be taken collaboratively. Node-centric Interoperability Maps and Arc-centric Interoperability Maps could be used in this context to identify concerned program offices. Videoconferencing is used in a distributed context which is a central characteristic of SoS. Videoconferencing can help defining and refining different types of interoperability maps via real discussions between all organizational entities. b. Constructive Level In the constructive level, we propose a Repositorybased Meta-architecture that emphasizes interfaces between a shared repository and the participant subsystems. The architecting process is composed of two steps: the repository construction and the interfaces building. Repository Architecture The architecture proposed in this paper is similar to blackboard architecture in the field of software engineering. Sub-systems of the SoS share a common data structure that is seen as an active Database. In blackboard architecture, every modification in stored data is automatically sent to concerned systems. Processes dealing with the automatic transmission of modified data are part of interfacing mechanism. We propose the use of multiagent technology to monitor these processes. An agent, called observer, notices updates to the blackboard and self-actualizing (in an event driven process) when there is new information to process. The internal structure of a SoS repository should store not only the content of data but also the structure and meaning of these data. Also, it should give mechanisms to process stored data to discover semantic information and to match content and meaning. In this section, we introduce our new methodology, which is based on combining two semantic modeling techniques: ontologies mapping and DNA computing. Figure 2 presents the overall process of the repository architecting.

Fig. 2. Ontology-based process for DNA Memory construction.

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 5, MAY 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

139

The process encompasses two steps: ontology construction and mapping, and DNA construction based on semantic net modeling. The main idea is facilitating attributes definition when developing the DNA memory. Ontologies are used in this step to map attributes that refer to the same concept but have different syntax. After concept mapping, the attributes referring to the same concept will be presented by a common attribute in the DNA strands as proposed in [16]. The first step, i.e. ontology construction and mapping, is now completed and we are working on the second step. Knowledge can be presented by class diagrams (concepts are presented by classes and concept properties are presented by attributes; Relations between concepts are given by different types of associations). We propose the process of figure 3 to transform these diagrams into Ontology Web Language (OWL) ontologies. OWL ontologies is being developed by the World Wide Web Consortium (W3C) Web Ontology Working Group, which had to maintain as much compatibility as possible with preexisting languages and is intended to be proposed as the standard Semantic Web ontology language (http://www.dsi.uniroma1.it/~estrinfo/ 1%20Ontology%20representation.pdf). OWL is also the most recent ontology language and is based on its predecessors such as RDF/RDFS. The first step in this process is Stereotyped Classes Dia-

gram construction. To perform this step, we have proposed stereotypes in table 1 to adapt UML concepts to ontologys concepts using Ontology UML Profile (OUP) in accordance with MOF standard [17]. Aiming to provide a generic approach, the proposed stereotypes could be applied to any UML class diagram regardless of the application domain. The second step is automatic generation of XML Metadata Interchange (XMI) file using for example Rational Rose tool and Unisys-XMI plug-in. Other tools could be used to generate the XMI file from an UML class diagram such as Poseidon for UML, which supports all requirements for the ODM proposed by OMG to support ontology development [18]. Finally, the generated XMI file is then transformed to OWL file using eXtensible StyleSheet Language (XSLT) processor. This processor executes a transformation code which was proposed based on the XMI file structure. This structure depends on the UML profile we have used to transform UML classes to stereoptyped classes. That is, any XMI file generated from UML classes diagram, that respects our proposed UML Profile, could be transformed into OWL file using our transformation code. A detailed description of the proposed approach of constructing and mapping of ontologies is given in [19].

Fig. 3. OWL ontology generation process from UML Classes Diagram.

Concerning the second step which is based on the first step, implementation is still ongoing. Interface Architecting An interface refers to a point of interaction between two systems. It presents a boundary across which two independent systems meet and act on or communicate with each other 1. In our case, an interface between the repository and the system to be integrated should be build as shown in figure 4.

During the SoS execution, sub-systems should interact with the repository. The interface architecture is composed of two parts. The first component of this architecture provides a Publishing/Subscribing process governing communications between the repository and sub-systems. The
1

second component is responsible for defining a formal mechanism to transform each sub-system data model to the DNA-based data model of the repository. In this paper, we introduce the first component which is now under development. To simplify the comprehension Publishing/Subscribing process, we start by giving a Petri Net (PN)2 as shown in figure 5 model which describes communications between sub-systems and the repository. A subsystem joins the SoS by publishing data to be seen by other subsystems and/or subscribing to data which are published by other subsystems. The Petri Net Model presented in figure 5 starts with a transition called Access. This transition is defined without an input place to report the
2

http://www.webopedia.com/TERM/I/interface.html

http://www.laas.fr/~robert/enseignement.d/index.html

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 5, MAY 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

140

fact that an infinite number of subsystems can be added. After joining the SoS, a subsystem can publish data to be seen by other subsystems or it can subscribe to data already published. Subsystems will be informed of changes in data for which they subscribed.

To implement this component, we are now testing the use of Portico RTI (Run Time Infrastructure of a HLA3-based (High LeveL Architecture) federation). This choice was derived from the fact that our proposed interface architecture is similar to the interface between the RTI and each federate in a HLA federation. In [19], we proposed a process to HLA Federation development using the Portico RTI which offers mechanisms to govern publishing/subscribing process when dealing with HLA federation. Giving the fact that Portico RTI is open source software, we can add other functionalities to meet our specific needs.

CONCLUSION

Fig. 4. The interfaces architecture of between the repository and each sub-system.

When dealing with interface architecture, the most important question is how to make subsystems integration effort minimum?. In this paper, a metaarchitecture was proposed to deal with different level of interoperability when integrating different systems into one global system alled System of Systems. The first level deals with organizational problems and performs solutions to facilitate collaboration between different stakeholders. The second level deals with SoS construction challenges. In this level a repositorybased architecture was proposed. This kind of architecture is based on processes governing communication between subsystems and the repository. As ongoing work, we are working on the validation of all steps of the proposed meta-architecture of communication. We intend as a first step to finalize the architecture of the DNA-based repository. We intend also to automatically generate DNA strands from data models of the integrated subsystems. All proposed solutions and processes will be tested in our domain of application, the Emergency Management Systems Modeling and Simulation.

REFERENCES
[1] E. J. Barkmeyer, A.B. Feeney, P. Denno, D. W. Flater, D. E. Libes, M. P. Steves, and E. K. Wallas, Concepts for Automating Systems Integration, Manufacturing Systems Integration Division Manufacturing Engineering Laboratory, February 2003. A. P. Sage, System of systems: architecture based systems design and integration. Keynote Speech of International Conference on Systems, Man and Cybernetics. 2005, October 10-12. W. Wang, W. Wang, Y. Zhu, and Q. Li, Service-Oriented Simulation Framework: An Overview and Unifying Methodology. SIMULATION: Transactions of the Society for Modeling and Simulation International. March 2011. L. Northrop (, June). Ultra-Large-Scale Systems: The Software Challenge of the Future. TECHNICAL NOTE: CMU/SEI (ISBN: 0-9786956-0-7) . Carnegie Mellon University. 2006. C. H. DAGLI, and N. Kilcay-ERGIN. System of Systems Architecting. In M. Jamshidi, System of Systems engineering for

[2]

[3]

[4]

Fig. 5. Petri Net Modeling Publishing/Subscribing process. Pub/Sub-S: Publisher/Subscriber Suspended, Pub/Sub-A:Active Publisher/Subscriber, Pub/Sub-E: Publisher/Subscriber in execution, CDB: Call Data Base, DF: Data Found, DNF: Data Not Found

[5]

http://www.ecst.csuchico.edu/hla/courses.html

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 5, MAY 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

141

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14] [15]

[16]

[17]

[18] [19]

Tthe 21st century (pp. 77-100). New Jersey: John Wiley & Sons, Inc., Hoboken. 2009. D. Firesmith, Profiling Systems Using the Defining Characteristics of Systems of Systems (SoS). TECHNICAL NOTE: CMU/SEI-2010-TN-001. Carnegie Mellon University. 2010, February. E. Morris, L. Levine, C. Meyers, P. Place, and D. Plakosh, System of Systems Interoperability (SOSI): Final Report. Pittsburgh: CMU/SEI-2004-TR-004. 2004. G. D. WELLS and A. P. SAGE. Engineering of a System of systems. In M. Jamshidi, System of systems engineering: innovations for the 21st century (pp. 44-76). United States of America: John Wiley & Sons, Inc. 2009. I. Jurisica, J. Mylopoulos, E. Yu, Using ontologies for knowledge management: An information systems perspective. Proceedings of the Annual Conference of the American Society for Information Sciences (ASIS99), Washington, DC. November 1999. N. Guarino, Formal Ontology and Information Systems, Proceedings of FOIS98, Trento, Italy, 6-8 June 1998. Amsterdam, IOS Press, pp. 3-15. 1998 T. K. Landauer, and S. T. Dumais, A solution to Plato's problem: The Latent Semanctic Analysis theory of the acquisition, induction, and representation of knowledge. Psychological Review , 104 , 211-140.1997. T. K. Landauer, P. W. Foltz, and D. Laham. Introduction to Latent Semantic Analysis. Discourse Processes, 25, 259-284. 1998. R. Deaton and J. Chen, Conceptual and Contextual DNABased Memory, In Knowledge-Based Intelligent Information and Engineering Systems, 8th International Conference, KES 2004 Wellington, New Zealand, September 20-25, 2004 Proceedings, Part I, Springer. 2004. B.Ganter, and R. Wille, Formal Concept Analysis. SpringerVerlag, Berlin. 1999 L., Brownsword, D. Fisher, E. Morris, J. Smith, and P. Kirwan, System-of-Systems Navigator: An Approach for Managing System-of-Systems Interoperability, Technical Note, CMU/SEI-2006-TN-019. 2006. Y. Tsuboi, Z. Ibrahim and O. Ono, Semantic Model for Artificial Intelligence Based on Molecular Computing, In Knowledge-Based Intelligent Information and Engineering Systems, 8th International Conference, KES 2004 Wellington, New Zealand, September 20-25, 2004 Proceedings, Part I, Springer. 2004. SISO Base Object Model Product Development Group, Simulation Interoperability Standards Organization (SISO) Guide for Base Object Model (BOM) Use and Implementation, SISOSTD-003.1-2006, 31 March 2006. D. Gaevi, D. Djuri, V. Devedi, Converting UML to OWL Ontologies, Communication of ACM 1-58113-912, pp. 487-488. 2004. H. Benali, and N. Bellamine-Ben Saoud, Towards a componentbased framework for interoperability and composability in Modeling and Simulation. Simulation Journal: Transactions of the Society of Modeling and Simulation International. 2010.