M&S within the model driven architecture

Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC) 2004 M&S within the Model Driven Architecture Andreas Tolk, Ph.D., James A. Muguira Virginia Modeling Analysis & Simulation Center (VMASC) Old Dominion University, Norfolk, Virginia [email protected], [email protected] ABSTRACT Currently, standardized distributed simulation systems are likely to follow the High Level Architecture (HLA) standard, not only because it is widely adopted in the United States for DoD applications, but also because it can be seen as the most matured M&S standard in this domain. However, the HLA focuses on the implementation level; thus it cannot solve problems on the conceptual level, such as validation, verification, or composability of models. The Discrete Event System Specification (DEVS) deals successfully with the conceptual challenges, but its application is limited to the academic community. The M&S community is still looking for a general method insuring interoperability on all levels, from the syntactic level via the semantic level to the pragmatic/dynamic level, and maybe even to the most general conceptual level. To this end, the communication-driven ideas of the HLA must be merged with the conceptually driven ideas of DEVS, preferably in a commercially viable way. One candidate is the Model Driven Architecture (MDA), proposed by the Object Management Group (OMG). The MDA can best be described as an overarching standard framework merging various middleware solutions and platform independent models of various application domains, using the Unified Modeling Language (UML) as the common concept gluing the various components together. This paper introduces the concepts of the MDA and shows, how the complementary ideas and methods of the HLA and DEVS can be merged into a well-defined M&S application domain within the MDA framework, allowing heterogeneous solutions as well as the migration from existing solutions to alternatives. The focus of this paper is the proposal of a framework of methods ensuring reusability, composability, and orchestration of events in a heterogeneous M&S and information technology environment, based on the migration of successful and accepted concepts. ABOUT THE AUTHORS Andreas Tolk is Senior Research Scientist at the Virginia Modeling Analysis and Simulation Center (VMASC) of the Old Dominion University (ODU) of Norfolk, Virginia. He received his M.S. in Computer Science (1988) and his Ph.D. in Computer Science and Applied Operations Research (1995) from the University of the Federal Armed Forces, Munich, Germany. He has over 14 years of international experience in the field of Applied Military Operations Research and Modeling and Simulation of and for Command and Control Systems. In addition to his research work, he gives lectures in the Modeling and Simulation program of ODU. His domain of expertise is the integration of M&S functionality into related application domains, such as C4ISR or web-based services, in particular based on open standards. James A. Muguira is a Ph.D. candidate at the Virginia Modeling Analysis and Simulation Center (VMASC) of the Old Dominion University (ODU). He received his B.S. in Information Science (1985) and his M.S. in Applied Physics (1997) from Christopher Newport University, Newport News, Virginia. He is working on the applicability and enhancement of engineering methods to support interoperability issues of simulation systems. He has several years of integration and software development experience and has conducted various integration projects, e.g., for NASA. 2004 Paper No. 1477 Page 1 of 13 Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC) 2004 M&S within the Model Driven Architecture Andreas Tolk, Ph.D., James A. Muguira Virginia Modeling Analysis & Simulation Center (VMASC) Old Dominion University, Norfolk, Virginia [email protected], [email protected] INTRODUCTION Currently, a number of trends are coming together in the modeling and simulation industry as a whole. The US Department of Defense (DoD) as well as the NATO nations and many other international partners are standardizing on the High Level Architecture (HLA) as a means to achieve interoperability among the various models used by the services. This is captured in their Modeling and Simulation (M&S) Master Plans (DoD, 1995; NATO, 1998). Academically, the Discrete Event System Specification (DEVS), as discussed in Zeigler (1976), helped to set up a common understanding of the challenges of creating interoperable simulation systems. DEVS is a mathematical formalism used to describe a discrete simulation system. The goal of DEVS is to employ mathematical models to specify a system in such a manner as to remove as much ambiguity as possible from the specification of that system. The result is a formal specification of the system that can used to mathematically reason about the system in question. DEVS has been around for a number of years and the research into the application of DEVS has reached a high level of maturity. Since its founding, DEVS has been extended in a number of different directions including the specification of continuous systems. Only recently, the connection of DEVS with software engineering methods has been established to enable the easier application of DEVS methods and formalisms in order to ensure an interoperable simulation development environment. Meanwhile, the commercial information technology (IT) world is moving towards a system definition and specification method that is known as the Model Driven Architecture (MDA) (see Kleppe et al., 2003), to support the interoperable development of distributed applications as well as the migration of legacy components to be reused under this new doctrine. The MDA is generic—in other words, not limited to a special application domain. The M&S and the information technology (IT) community have in common that they want to develop system components that interoperate seamlessly and simply; however, no bridge yet exists 2004 Paper No. 1477 Page 2 of 13 to apply the MDA to M&S challenges, although first interest on both sides has been expressed. The thesis underlying this paper is the following: while the HLA is a powerful standard on the implementation level, it is insufficient to solve problems related to higher levels of interoperability, as defined in Tolk and Muguira (2003). They introduce multiple levels of conceptual interoperability: technical/physical (connections), syntactical (protocol, formats), semantic (data model), pragmatic/dynamic (behavior, ontology), and conceptual (common concept, business model). While the HLA is sufficient up to the syntactical level (in particular when interpreting the HLA FOM as a special form of a data model), and in some special cases up to the semantic level, problems on the higher levels can be better dealt with using DEVS. Although first connections of DEVS to software engineering methods have been established, a generally accepted framework has not been developed. The MDA has the necessary means to deal with both issues; i.e., it can take the general concepts captured by DEVS and map them via software patterns to HLA implementations. The MDA can furthermore migrate legacy solutions towards HLA as well as towards alternative implementations, such as the web services or other structures used within the context of serviceoriented architectures, such as proposed for computer grids. In summary, based on a general description of the main problem—classes of meaningful interoperability between distributed heterogeneous simulation components and systems—this paper will describe the solutions of HLA and DEVS and use the MDA to provide a model of how these ideas can be merged into a more general framework to enable M&S within the MDA. THE GENERAL PROBLEM DEFINITION In general, the central problem to be solved is that of systems interoperation. To ensure meaningful interoperability among distributed heterogeneous components, three levels of systems interoperation need to be ad- Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC) 2004 dressed: the component level, the dynamic level, and the conceptual level. For the purposes of this paper, these terms are defined as follows: 1. 2. Component level – Any system is composed of components that interoperate by design. The main challenge in software engineering concerning reusability and composability is to ensure that these components can be isolated from the system, stored in some repository, and reused by other unrelated or loosely related systems. Most of the focus on component-level interoperation has been on the interfaces between components How can we ensure meaningful information exchange between components via these interfaces. Interoperation on the component level deals with the meaningful interchange of data via the component interfaces. Dynamic level – Dynamic interoperation deals with the idea of systems interoperating over time. In order for different systems to interoperate, one must consider the manner in which time is handled by each simulation: How can the execution of distributed and heterogeneous components be orchestrated? This can be done by aligning or mapping time-management processes. It can also be done via interfaces, if they comprise synchronization points or similar capabilities. Interoperation on the dynamic level deals with the orchestration of the execution and handling of timemanagement issues. Conceptual level – The final level of interoperation that needs to be addressed is that of conceptual interoperability. To address this issue the systems architect needs to assess how well the founding concepts of each system mesh—in other words, are the underlying assumptions similar enough to support a composition of the distributed components? This level implies transparent components, or at least components with a welldefined behavior. Assumptions and constraint are part of the underlying conceptual model. Black box solutions or interface-driven approaches cannot fulfill this requirement, as they do not cope with these aspects of the modeling process. Interoperation on the conceptual level deals with the alignment of the conceptual models underlying the components to be composed. In summary, there are three main software-engineering questions that must be answered to ensure meaningful interoperability of distributed and heterogeneous simulation components—among themselves and with other IT components—which includes real systems, such as sensors, weapon systems, or command and control systems. These questions are as follows: 2004 Paper No. 1477 Page 3 of 13 3. How to ensure semantically correct information exchange among distributed, heterogeneous components? How to orchestrate the execution of distributed, heterogeneous components? How to ensure conceptual composability of distributed, heterogeneous components? In practice, another relevant question is the availability of applicable migration concepts for legacy systems and components. New approaches are unlikely to be accepted by the M&S industry if they are connected with tremendous migration costs due to reprogramming efforts. The better a migration path is already supported by commercially viable tools and methods, the higher is the likelihood for acceptance by the M&S industry. Investment protection has a high practical value. These evaluations lead to the following requirements for meaningful interoperability between distributed, heterogeneous components: • • • • Methods for migration and reuse Standards for information exchange Orchestration of the execution Conceptual composability These four requirements will be used to compare HLA and DEVS solutions and will motivate the merging of such concepts under the umbrella of common software development standards embraced by the MDA. The intrinsic relation with validation and verification, such as in DoDD 5000.61, should be mentioned, although this is not in the scope of this paper. It has been dealt with in other papers, among others in Tolk’s discussion of composable mission spaces (2004). THE HIGH LEVEL ARCHITECTURE It goes beyond the scope of this paper to introduce HLA in detail. The interested reader is referred to the IEEE Standard 1516 for details. However, the main ideas of HLA concerning the four requirements will be dealt with in the necessary detail to prepare the ground for the later proposal to migrate these solutions towards MDA. Domains Dealt with by the HLA The central idea behind HLA is systems interoperation on the implementation level. Under HLA, several distributed and heterogeneous components—called feder- Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC) 2004 ates—are composed using a common set of services delivered by a common software infrastructure for data exchange into one federation. The HLA Standard HLA is defined by three standards: • • • The set of rules must be followed by federates and within the federation in order for systems to interoperate. The interface specification for the common information exchange and orchestration software, the Runtime Infrastructure (RTI), defines how to call the services of the RTI and how to provide the request callbacks. The object model template (OMT) is a common structure capturing and formatting information exchange requirements between the participating federates. RTI and RTI Services The communication infrastructure of the HLA is founded upon a set of services that are collectively referred to as the Runtime Infrastructure (RTI). The RTI services can be divided into the following categories: • • • • • • Federation management comprises all basic functions required to create and operate a federation, such as joining or leaving the federation. Declaration management ensures efficient data exchange management through information provided by federates defining data being published and subscribed to. Object management is responsible for the creation, deletion, identification, and other services at an object level. Ownership management comprises functions supporting dynamic transfer of ownership of objects and attributes during an execution to increase the flexibility. Time management is responsible for the synchronization of simulation data exchange and the orchestration of the execution. Data distribution management enables efficient routing of data among federates during execution, as not every federate needs every piece of data. Figure 1 shows the availability of RTI services during the execution of a federation. There are several RTI implementations available. The robustness of HLA and the applicability of the concepts have been proven 2004 Paper No. 1477 Page 4 of 13 by their use in several experimentations and simulation events, ranging from small-scale applications in the academic environment to events like Millennium Challenge 2002, in which M&S and real-world systems (weapon systems, command and control means, live ranges, etc.) were coupled under use of HLA. Startup Execution Shut Down Ownership Management Time Management Data Distribution Management Object Management Declaration Management Federation Management Figure 1. RTI Service Categories The Federation Development and Execution Process Although not standardized, the Federation Development and Execution Process (FEDEP) must be taken into account as well when looking at HLA in support of meaningful interoperability. The IEEE Recommended Practice 1516.3 documents the FEDEP in detail. The FEDEP is a guideline on how to use the HLA standards in the process of setting up a federation and executing it in support of the users’ needs. To this end, seven steps are defined, as follows: • • • • • • • Define the federation objectives. Perform conceptual analysis. Design the federation. Develop the federation. Plan, integrate, and test the federation. Execute the federation and prepare the outputs. Analyze data and evaluate results. The FEDEP puts HLA into a broader scope and connects the implementation-dominated standards to user requirements, which ultimately drive the federation objectives. HLA and the General Requirements HLA was never intended to address all requirements mentioned in the beginning of this paper; however, it is valid to evaluate how well HLA already fulfills them. Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC) 2004 Like its predecessors—the Distributed Interactive Simulation (DIS) protocol and Aggregated Level Simulation Protocol (ALSP)—HLA focuses on the implementation level, i.e., the coupling of existing systems and their reuse within several federations. None of the rules of the HLA deals with federate behavior alignment. The OMT describes the exchange of data between federates, and the RTI services are supporting the coupling of federates and their synchronization. If at all, the alignment of federate behavior is dealt with to a limited degree within the FEDEP. It seems fair to consider HLA a mature method for federate coupling on the component level. It has potential on the dynamic level, as at least time management for synchronization of federates’ execution is used. However, there is no real means to deal with conceptual interoperability. Summary of HLA Despite the broader objectives driving the FEDEP, HLA focuses on the implementation level. Information exchange is specified by the OMT, and orchestration is supported by time-management services implementing the main time-management ideas as having been developed for parallel and distributed simulation systems. Although generally accepted in the M&S community, in particular in the military domain, the commercial support of HLA solutions, including migration concepts and so on, is somewhat limited. Internal specifics of the federate as well as conceptual views are not well supported by the HLA, which has led to the recent efforts concerning “meaningful interoperability” in contrast to pure “technical interoperability.” The main shortcoming of HLA is that it allows one to compose components technically that cannot be composed conceptually. Many problems of composability as defined by Davis (2004) were never in the scope of the HLA designers. In summary, HLA offers a lot on the level of technical interoperability and technical connectivity as a necessary but not sufficient requirement for the interoperation of systems. In particular the RTI services are a mature implementation of M&S requirements concerning parallel and distributed simulation using heterogeneous implementations. THE DISCRETE EVENT SYSTEM SPECIFICATION As with HLA, a general introduction to DEVS goes beyond the scope of this paper. Again, the main ideas 2004 Paper No. 1477 Page 5 of 13 will be highlighted to motivate the application of MDA to migrate this valuable M&S knowledge and make it available to a much broader community in a meaningful manner in the near future. Domains Dealt with by DEVS The Discrete Event System Specification, or DEVS, is a mathematical formalism used to describe a discrete (vs. continuous) simulation system. The intent is to describe a simulation system, independent from whether it is distributed and comprises heterogeneous components or not. Therefore, its scope is much broader and more general than that of HLA. On the other hand, DEVS is not generally directly applicable to solve “real world problems,” such as setting up a federation to support a simulation event. Generally, the goal of DEVS is to reduce a system to a formal mathematical specification using methods that remove as much ambiguity as possible from the specification of that system. The DEVS formalism strives to track and capture the changes to the variables inside the system and as output generates piecewise-constant time segments that are the values of the systems variables over time (see Zeigler, 1999). The DEVS formalism is organized around a state machine with static internal variables and dynamic behaviors. The state machine definition, variable definitions, and dynamic behavior of the system are derived as the specification of that system is transformed from an informal to a formal status. All these efforts target the reduction—and ultimately the elimination—of ambiguity. Ambiguity is the possibility of having more than one interpretation of a process or procedure within the overall system—or the federation. The interoperation among the components of a system requires a precise determination of the possible behaviors involved in the interaction, semantically as well as dynamically. Ambiguity in the specification of the design of a system will likely lead to situations where the model does not perform as intended. DEVS is a mature approach to reduce ambiguity in the specification of lumped discrete model systems. To this end, DEVS specifies a spectrum from informal system ideas to formal system specifications. Generally, a system design starts out as a loose informal description. This loose informal description is transformed over time into a more precise specification of the types and possible ranges of variables and input and output states the model will represent. Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC) 2004 DEVS System Specification The DEVS formalism defines two aspect categories of models that need to be specified: static aspects and dynamic aspects. The static aspects are specified as follows. The mix of objects in the system can generally be considered to be static. These objects fall from the design into higherlevel components or natural organizations of logic captured for reuse. The interface to the component is exposed in some form of service for other objects or components to utilize. This interface hides the internal variables that a component will have. Some variables will have a dynamic changing number of items but the basic name is singular. The static aspects are dealing with objects and variables. The dynamic aspects are handled using diagrams. The number of dynamic interactions possible among a diverse but finite set of components is huge. For this reason, the dynamic interactions of a system must be rendered in Component Interaction Diagrams if any sense is to be made of the connections. These diagrams are used to study which components interact and the amount of interaction. In addition, Influence Diagrams are needed to gain the insight into component behavior that is required to understand which components in the system influence the others. It is this behavior of the component that is reused. The behavior is measured in terms of the number and types of inputs, the range, and number of outputs and any transformations known to happen during a state transition. This influences the specification of states. The basic model is a finite-state machine architecture. DEVS is concerned with specifying the information that captures the transitions between states. In summary, the structure of the model is defined by the set of inputs, outputs, and internal states; the behavior of the model is defined by the output produced upon a given input as well as the time advance. Atomic and Coupled Models The idea of atomic and coupled models is the last principal of DEVS to be discussed in this paper, as it is fundamental to the comparison of DEVS and HLA, and important when moving towards an MDA driven approach. Atomic models provide the basic functionality to be used by coupled models. They are defined by a set of input and output ports, internal variables, a time advance function, a set of transition functions, and a resulting output function. 2004 Paper No. 1477 Page 6 of 13 Coupled models result from composing atomic models or “lower level” coupled models. They comprise the set of components, hence building models, their own set of input and output ports, and a set of coupling specifications between the models, which includes transition functions between the ports and the models as well as between the models. In comparison with HLA, DEVS therefore provides a totally transparent view on the system and its components and sub-components down to the lowest level of resolution. Every state and state change is documented and reproducible, while the internals of federates are generally hidden within HLA. DEVS and the General Requirements The DEVS formalism is not really an engineering effort. It deals only implicitly with the levels of systems’ coupling. The strengths are in the conceptual domain. DEVS allows the specification of component behaviors, enabling the evaluation of whether two components are composable from their assumptions and constraints. This formalism furthermore decouples the behavior from its implementation details. While DEVS enables conceptual interoperability, it also protects the intellectual property of implementations. Unfortunately, the lower levels of interoperability are too technical to be dealt with by DEVS explicitly without misusing the formalism. Although synchronization points can be defined and cross-component functions can be defined, the technical details needed for the interfaces are hidden. In combination with software implementations, such as DEVSJAVA, the general applicability has to be sacrificed for the sake of the specific implementation. Therefore, DEVS is judged to have its strength in the conceptual domain, while component and dynamic interoperations are supported only limitedly. Summary of DEVS Several efforts have been initiated in the recent past to use DEVS within M&S implementation frameworks. In particular DEVSJAVA—as presented in Sarjoughian and Zeigler (1998)—should be mentioned. DEVSJAVA is based on the DEVS formalism and provides classes for implementing atomic and coupled models as well as functions to add ports, phases, and internal and external functions. UML diagrams already support this. Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC) 2004 However, even DEVSJAVA is not considered to be a mature software engineering approach, but rather the prototypical use of software engineering methods in support of M&S developments. Furthermore, no methods for migration or reuse of legacy systems are provided. Nevertheless, the applicability of software engineering concepts has been shown, and the approach can easily be extended towards the ideas underlying the MDA. In addition to the work at the Virginia Modeling Analysis and Simulation Center engaging the MDA, other ongoing research in the academic domain supports the thesis that DEVS can effectively be enhanced by software engineering methods, in particular UML and the MDA, which will be discussed in the following section. Of particular note is the work on merging UML and DEVS, which is underway at the Technical University of Ostrava, Department of Computer Science, in the Czech Republic (http://vondrak.cs.vsb.cz), and the University of Corsica, Department for Environmental Modelisation, in France (http://spe.univcorse.fr). Extensible Markup Language (XML) and the XML Metadata Interchange specification (XMI), the Unified Modeling Language (UML), middleware solutions supporting CORBA, Sun’s Enterprise JavaBeans, or Microsoft’s DOTNET, the Common Warehouse Metamodel (CWM), the Meta Object Facility (MOF), and many more. The core of the MDA uses UML, MOF, and CWM. They are mapped to support different middleware solutions, such as CORBA, and core functionality and pervasive services, such as transactions and event handling, and finally target various application domains, such as space or transportation. MERGING HLA IMPLEMENTATION AND DEVS CONCEPTS TO CREATE A M&S DOMAIN UNDER MDA Under the aegis of the Object Model Group (OMG), a commercial consortium comprising over 800 professional IT companies, the Model Driven Architecture (MDA) is currently under development. The MDA places the modeling process in the center of IT support to maximize interoperability and flexibility. Introducing the MDA Traditional system design efforts follow a process that creates lots of supporting documentation that rapidly becomes out of date as the system matures and is modified. This supporting documentation is used as the basis or starting point for the development of the executable system. The MDA changes this model by directly using the documentation artifacts, which are transformed into the system. In other words, the MDA combines the pattern-oriented software design and engineering paradigm with the use of human-readable models. To this end, the MDA merges different standards that have been developed and used separately into a common view by applying common metamodels. Without going into details, just a few of these standards that will become part of the MDA should be mentioned: the 2004 Paper No. 1477 Page 7 of 13 Figure 2. The MDA Architecture The core idea of MDA is to use a common stable model, which is language-, vendor- and middlewareneutral, and which is referred to as the platformindependent model. With the platform-independent model in the center, users having adopted the MDA gain the ability to derive code for the executable or platform dependent level. This is done by deriving platform-specific models from the meta-model. Even if the underlying infrastructure shifts over time, the meta-model remains stable and can be used to support various middleware implementations based on multiple languages, vendors, and platforms. To be able to do this, the MDA defines an approach to system specifications that separates the specification of the system functionality from the specification of the platformspecific implementation. Platform-Independent Models Programming today involves hand coding a custom algorithm to solve a specific problem. The solution is specific to the machine and language used by the programmer for implementation. The world of computer Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC) 2004 science has made some progress in platformindependent language design, but the bulk of the work involved in porting an application still rests on the programmer. The MDA is trying to break the edit, compile, and debug cycle by capturing the real work of the analyst in a platform-independent model (PIM). Instead of being left to age and rapidly become obsolete, the artifacts left by the analyst are the final specification of the system. The analyst uses the PIM to upgrade or apply changes to the system. The delivered system is completely generated from the PIM. The analyst works on and improves the PIM only, turning to platform-specific models to test ideas and deliver the system. Following the idea of the Common Object Request Broker Architecture (CORBA), another architecture successfully developed by OMG, two other conceptual ideas are used within the PIM: domain facilities models and pervasive service models. Subject matter experts of the domain, such as command and control or telecommunication, develop the domain facilities models. They comprise the knowledge about the domain in standardized, implementation-independent form. Pervasive services are generally applicable services used in various domains, such as event notification, object security, transactions, etc. Platform-Specific Models For each platform that the tool set supports, a series of libraries that produce the correct behavior make up the Platform-Specific Model (PSM). The PSM must correctly output the correct behavior for a given situation. The PSM is generated code. There are many complaints associated with generated code, related primarily to the efficiency of such code. Worrying about efficient coding of algorithms is fine on small projects having relaxed deadlines. However, today’s engineering projects are growing exponentially larger (measured in lines of code), and must be completed in geometrically shortening amounts of time. As the size and complexity of the projects keep growing, the community must change the way that business is done. The authors believe that generated code in an MDA-like environment is the correct path. The RTI services and the associated implementation are an example of a platform-specific model (namely HLA compliant) of services generally needed for distributed simulations. An alternative approach could be to implement the same set of services using web service or another implementation doctrine for serviceoriented architectures. 2004 Paper No. 1477 Page 8 of 13 Managing Heterogeneous Components The literature on MDA focuses on its potential as a software engineering method. However, there is also the potential use for management purposes: When MDA is applied in the context of re-engineering, following similar “inverse” mapping rules, a common platform independent model can be established as a formal representation of the conceptual model of the component. This platform-independent model can furthermore be integrated into the formal description of the mission space comprising all platform-independent models, hence concepts and functionality, of all participating components. In summary, MDA is a flexible software engineering method that can serve as a container for various application domains, middleware solutions, etc. It was identified as an applicable bridge between alternative and complementary implementations using heterogeneous IT environments. How these concepts can be used to merge HLA and DEVS to produce a new framework for M&S functionality in distributed and heterogeneous environments is the topic of the rest of the section. Bringing HLA and DEVS into the MDA We have already concluded that the HLA mainly addresses the lower levels of interoperation: the component and dynamic levels. The services of the HLA can best be mapped to pervasive services. Tolk (2002) provides a number of ideas for integrating the HLA and MDA directly, so combining the MDA and HLA is not new. DEVS defines the other end of the interoperability spectrum by applying formalisms to the type and nature of the data to capture about a system. This formal information capture allows DEVS models to interoperate at semantic and conceptual levels, since some assessment of model alignment can be made. Some authors, such as Zeigler et al. (1999), have mapped the DEVS onto HLA directly. In such mappings, the DEVS coupling specifications are transformed into HLA interactions. Furthermore, it should also be possible to map DEVS formalisms directly to UML models, and the research of the universities mentioned earlier show promising results. UML, on the other hand, is the language in which MDA models are formulated. If DEVS and HLA can be expressed in UML and UML is the core language of the MDA, the conceptual support of DEVS should be directly applicable to MDA, and HLA support can be mapped to the supporting services. In other words, the glue that can bind these two modeling paradigms together—DEVS and HLA—is the MDA. With its lay- Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC) 2004 ered architecture, the MDA provides support for modeling of systems and modeling of models. The MDA utilizes the Meta Object Facility (MOF) as a language for creating modeling languages. The MOF is a stand-alone modeling construct and, though powerful, still lacks formal rigor in the domain of modeling and simulation systems. This formal rigor is exactly what DEVS provides for the M&S domain. The MDA platform-independent model is based on exactly the ideas of DEVS: unambiguous representation of the conceptual model, formal specification of inputs and outputs and categorization of static and dynamic variables. The DEVS formalism will enable the systems architect to gather a standardized and reproducible set of artifacts for any system. A Case Study To serve as an example of the authors’ ongoing research, a tentative example of how to compose a PIM of a system will be given. This work contributes to the attempt to define a methodology for interoperation assessment. In addition to the theoretical aspects of composability, such as dealt with in Weisel (2004), this work focuses on the application of software engineering methods above the technical level to make the results of Weisel more easily applicable. As the methodology becomes more fully defined, a series of complete war game scenarios would be used to show proof of concept and serve as working examples. The next section will present a diagrammatic scheme to achieve a PIM. The diagrammatic scheme is backed up by a set of rules to connect and check the contents of the diagrams. Figure 3 shows the system model as defined earlier. System Sub-Model Process Sub-Model Object Sub-Model User Sub-Model Collaborative Services External Influences and Interactions External Interactions User Interfaces Figure 3. Links between Sub-Models The composition of a PIM starts by examining the system from four different aspects: the systems view, ob- 2004 Paper No. 1477 Page 9 of 13 ject view, process view, and user view. Using these four aspects, sub-models can be constructed, each of which will relate to the others and the rest of the system through a set of rules. The rule set ensures modelto-model and model-to-system integrity. One open research question is whether the rules set should be captured and sent with the other artifacts or whether it is general enough to code into the tool set. Consider a sub-set of the sequence of diagrams and rules that links an entire system together. Starting with the System Sub-Model, the designer captures information related toward the overall design and needs of the system. Many questions need to be answered, such as: what is the purpose or intent of the simulation, what are the components, where are they deployed, what interactions are there between components. The UML deployment diagram shows information about the components and their connections. Additionally, the UML sequence diagram, the UML activity diagram, and the DEVS component interaction and DEVS influence diagrams are used to capture information at the System Sub-model level. These diagrams as a whole should be consistent with each other and be machine consumable so that the information compiled into them can be extracted and audited. One outcome of the systems level sub-model will be the start of a system-wide data dictionary. As more sub-models are studied, the dictionary is further populated. The next sub-model is the Process Sub-Model, which captures information about the activities and processes of the system. The Process Sub-Model is concerned with a global process view of the system. The Process Sub-Model deals with the components' interactive behavior and system state specifications. The process sub-model can start with a UML activity diagram. This activity diagram needs to be automatically audited with the diagrams produced by the System Sub-Model. The UML activity diagram will have associated with it a UML collaboration diagram, a UML sequence diagram, and a DEVS component interaction diagram from the System Sub-Model. All these models need to remain consistent with each other; thus the more automation the MDA toolset could provide, the better. The Object Sub-Model captures information about the objects and components in the system. It provides insight into system composition and behavior of the components within the overall system. There are a number of related diagrams: the UML class, state, and sequence diagrams; and the DEVS influence and specification of state diagrams. Note that this is the submodel explicitly making use of DEVS extensions to UML to capture M&S-specific behavior, namely the Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC) 2004 objects’ behavior and the static plus dynamic aspects of their design. adjust prices and quantity until an agreement has been reached on both sides by mutual negotiations. The last sub-model is the User Sub-Model. The UML use case is used throughout the system to capture information on the nature of the interaction with any component or with the system as a whole. The User Sub-Model will affect the system-wide data dictionary, and the collaboration and activity diagrams from the Process sub-model already discussed. The evolution of the PIM starts with the analyses of the collaboration and the participating systems resulting in the collaboration diagram (Figure 4). We define for our model that buyer and seller interact through the use of order and lot messages. For simplicity reasons, we only model one buyer and one seller. The resulting sequence diagram is shown in Figure 5. Table 1 summarizes the diagrams and datasets that need to be completed in order to generate a PIM for two general systems. The main diagram is used to align the additional information comprised in the supporting diagrams, which have to be coupled via repository functions with the main diagram. These are preliminary results and have to be further evaluated, but they proved to be a good core set within the case study. Turkish Market Message = Order Buyer Table 1. Views and Diagrams of the Case Study Message = Lot Supported Main Supporting diagrams (coupled) View Diagram System view UML Deployment diagram DEVS Influence Diagram UML Sequence Diagram DEVS Component Interaction Diagram UML State Diagram of System Internals Data Dictionary Object View UML Class Diagram Data Dictionary UML State Diagram for Object Internals UML Sequence Diagram Object Interactions DEVS Influence Diagram DEVS State Transition Diagrams Process View UML Activity Diagram Data Dictionary UML Collaboration Diagram DEVS Component Interaction Diagram UML Sequence Diagram User View UML Use Cases Data Dictionary UML Collaboration Diagram UML Activity Diagram The following subsection gives an example to illustrate the method. Example: Turkish Market A complex example goes beyond the scope of this paper. Therefore, to facilitate the understanding of the method developed within the underlying research work, a simple example showing the implementation of a PIM for a Turkish market is given. A Turkish market is an oriental bazaar market where buyers and sellers 2004 Paper No. 1477 Page 10 of 13 Seller Figure 4. Collaboration Diagram of the Turkish Market Seller Buyer Lot Information Consult Business Logic Order Information Figure 5. Sequence Diagram of Seller The Seller advertises a lot and waits for a Buyer to issue an order. (In this case the seller could wait forever; however, the example is constructed to exemplify the method, not giving a real-world model.) If the buyer wants less or more than the current lot the seller may adjust the price or the amount of goods in the lot. Like wise the buyer will change the amount in the order and re-advertise. How the systems react is defined Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC) 2004 internally (where DEVS comes into play). The necessary internal states are captured in the state diagram based on DEVS transition analyses. Both sides need to be specified. The simple versions of the example are shown in Figure 6 (seller) and Figure 7 (buyer). For real-world examples, the necessary states are much more voluminous. Adjust Lot Quantity Adjust Lot Price Process Order Advertise Lot Receive Order Figure 6. State Diagram of Turkish Market (Seller) Adjust Order Advertise Order Process Lot Info Receive Lot Info Figure 7. (Buyer) State Diagram of Turkish Market Note that the analysis of necessary states can be supported by the application of the Levels of Conceptual Interoperability Model (LCIM) as given in Tolk & Muguira (2003). Academically, all states of a system should be transparent; practically, issues like intellectual property and commercial interests of system developers may speak against it. The use of a PIM for specification of federations is of interest of all sides: the user gets the necessary transparency; the developer can encapsulate his implemen- 2004 Paper No. 1477 Page 11 of 13 tation. All diagrams displayed are an example for a simple PIM of the Turkish Market. Platform-specific models (PSM) as the interim step for the execution of a simulation are generated from the amalgamation of information contained in the diagrams, tables and rules captured by the MDA tool set. To change the system, the architect returns to change the table and diagrams and then regenerates the system. The data that was used to form the diagrams was gathered using the DEVS formalism. Any two systems that have had the DEVS formalism applied can be compared since the same information will be captured for each system while at the same time the implementation details are hidden, protecting the commercial interest of system implementers. With this standardized set of artifacts, facilities of the MOF can be used to create transformations. The pervasive services for distributed simulation can now be used to connect these conceptually aligned models. Returning to the example of the Turkish Market: this set of artifacts (a collaboration, a sequence, and two state diagrams) is a simple PIM. Mapping these artifacts to federates, data elements of the Federation Object Model (FOM), and service calls of the RTI results in a PSM. The implementation would be rendered using the HLA infrastructure. A Seller would publish lot information and the Buyers would subscribe to lot information. Likewise, the Buyers would use interaction to signal order information with the Seller. Note that there is no reason not to use the same PIM to generate a set of web services and web service invocations resulting in the PSM for a web-based simulation. As proposed in Tolk (2002), this allows migration of the matured concepts underlying the HLA, in particular the services provided by the RTI, to alternative implementations, such as the use of web-based environments for distributed simulation. The results of the work done so far are encouraging. As DEVS is an overarching formalism, additional benefits are the possibility of auto-generation of information exchange descriptions in several forms, such as OMT tables or XML documents. Finally, the migration to HLA—or to another agreed to IT framework, e.g. web services or another service-oriented architecture type—is directly supported by means of the MDA. In particular for simulations dealing with the military domain, the domain-specific view of the Department of Defense Architecture Framework (DoDAF, 2003) should be used as a guideline. The DoDAF defines operational views (what operational activities have to be supported, user’s view), system views (what func- Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC) 2004 tionality supporting the activities is delivered by what systems and components, system analyst and designer’s view), and technical views (supporting interoperability standards enabling connection of the systems and components, implementer’s views). UML supports many of these views. (Atkinson, 2004). This topic is worthy of discussion in a separate paper, and should be mentioned only with respect to the ability to enrich DEVS semantically to enable applications as described in Adshead et al. (2001). Another alternative to capture the intent of the M&S component is using the Military Missions and Means Framework (MMF) as described in Sheehan et al. (2003). However, further evaluation is necessary before recommendations can be made. ble standard is true for MDA and UML within the M&S domain. LCIM DEVS/HLA MDA Level 5 Conceptual Interoperability Domain specific Business models, such as DoDAF Domain overarching Repository of PIM Level 4 Dynamic/Pragmatic Interoperability DEVS PIM Level 3 Semantic Interoperability DEVS Reference FOM PIM PIM-PSM-Mapping Level 2 Syntactic Interoperability HLA PIM-PSM-Mapping PSM Level 1 Technical Interoperability Net standards Web connectivity TCP/IP etc. Repository of PSM describing net/web solutions SUMMARY Figure 8. LCIM-DEVS/HLA-MDA Comparison HLA was introduced to couple existing simulation systems—called federates—to set up federations. The systems are treated as black boxes. The coupling uses the RTI, whose interfaces are standardized. HLA overcomes many shortcomings of earlier approaches and is a very mature method on the implementation level. The DEVS formalism is a mature approach to describe simulation systems in a way that provides insight into the systems’ internal states and state changes without having to reveal the implementation details. It focuses on a context-free description of the relevant internals of a system or a component, which may become a federate. The MDA is a software engineering approach whose acceptance is steadily growing. It uses patterns to map platform-independent models to platform-specific models, thus decoupling general solutions from implementation-specific details. It uses UML, CWM, and MOF for the independent models, and thus can be applied to describe DEVS diagrams as well as HLA concepts. Figure 8 shows the conceptual idea behind the approach described in this paper. Various publications accept the broad applicability of the MDA, but point out that due to the broad applicability it can never replace special domain solutions tailored to the need of the domain. The price for this highly efficient domain-specific solution, however, is the lack of general applicability. To this end, choosing between MDA and high-performance domain-specific solutions is choosing between broad interoperability within the community or high performance solutions not applicable and reusable in related domains. The same discussion that is valid for every widely applica- 2004 Paper No. 1477 Page 12 of 13 In summary, the MDA enables the efficient use of DEVS for software and systems engineering, reuses HLA concepts efficiently, and allows the migration to new IT infrastructures while supporting simulation management. Additional conceptual views, such as described in domain-specific approaches like the DoDAF, can be merged into the general concept described in this paper. The feasibility of the approach has been proven in several IT domains already. The gap to be bridged is of a cultural nature; it is not a technical gap. ACKNOWLEDGEMENTS The research work underlying this paper was in partfunded by the Defense Modeling and Simulation Office (DMSO), the U.S. Air Force Joint Synthetic Battlespace (JSB-AF) Initiative and General Dynamics – Advanced Information Systems (GD/AIS). REFERENCES Adshead, S., Kreitmair, T., Tolk, A. (2001). Definition of Active Layered Theatre Ballistic Missile Defense (ALTBMD) Architectures by Applying the C4ISR Architecture Framework. In Proceedings of the Fall Interoperability Workshop, Orlando, FL Atkinson, K. (2004). Modeling and Simulation Foundation for Capabilities Based Planning. In Proceedings of the Spring Interoperability Workshop, Arlington, VA Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC) 2004 Davis, P. and Anderson, R. (2003). Improving the Composability of Department of Defense Models and Simulations. RAND Corporation Department of Defense Directive (DoDD) 5000.59-P (1995). DoD Modeling and Simulation (M&S) Management. Washington, DC Department of Defense Directive (DoDD) 5000.61 (2003). DoD Modeling and Simulation (M&S) Verification, Validation, and Accreditation (VV&A). Washington, DC DoDAF (2003). Department of Defense Architecture Framework (DoDAF). Washington, DC Institute for Electronics and Electrical Engineers. (2000). IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA). IEEE 1516, IEEE 1516.1, and IEEE 1516.2 Institute for Electronics and Electrical Engineers (2003). IEEE Recommended Practice for High Level Architecture (HLA) Federation Development and Execution Process (FEDEP). IEEE 1516.3 Kleppe, A., Warmer, J., Bast, W. (2003). MDA Explained The Model Driven Architecture: Practice and Promise. Addison-Wesley North Atlantic Treaty Organisation (1998). Modelling and Simulation Master Plan. Document AC/323 (SGMS)D/2 NATO NATO Parr, S. and Magee, R. (2003). Making the Case for MDA. In Proceedings of the Fall Simulation Interoperability Workshop, Orlando, FL 2004 Paper No. 1477 Page 13 of 13 Sarjoughian, H. and Zeigler, B. (1998). Devsjava: Basis for a DEVS-based collaborative M&S environment. In Proceedings of the 1998 SCS International Conference on Web-Based Modeling and Simulation, volume 5, pages 29-36. San Diego, CA Sheehan, J., Deitz, P., Bray, B., Harris, B., Wong, A. (2003). The Military Missions and Means Framework. In Proceedings of the I/ITSEC 2003, Orlando, FL Tolk, A. (2002). Avoiding another Green Elephant – A proposal for the Next Generation HLA based on the Model Driven Architecture. In Proceedings of the Fall Simulation Interoperability Workshop, Orlando, FL Tolk, A. (2004). Composable Mission Spaces and M&S Repositories – Applicability of Open Standards. In Proceedings of the Spring Simulation Interoperability Workshop, Arlington, VA Tolk, A. and Muguira, J. (2003). Levels of Conceptual Interoperability Model. In Proceedings of the Spring Simulation Interoperability Workshop, Orlando, FL Weisel, E. (2004). Models, Composability, and Validity. Dissertation at the Old Dominion University, Norfolk, VA Zeigler, B. (1976). Theory of Modeling and Simulation. Academic Press, pp. 21-25. Zeigler, B., Ball, G., Cho, H., Lee, J., Sarjoughian, H. (1999). The DEVS/HLA Distributed Simulation Environment and its Support for Predictive Filtering. In SIMULATION: Special Issue on The High Level Architecture, Volume 73, No. 4