• No results found

1.1. Motivation and Goals

The study of interoperability has been conducted to suggest a methodology to integrate different systems distributed over the network systems. The integrated system called the System of Systems (SoS) is differentiated from a single monolithic system in that it requires interoperability among its constituent systems [1]. SoS engineering has priority on interoperability on the development of command and control (C2) capabilities for joint and coalition warfare [2-4]. From the research of interoperability, models with levels of interoperability describing technical interoperability and the complexity of interoperations [5-7] are suggested in the SoS research groups. The model of levels of interoperability is reinterpreted in the different applications such as telecommunication and software to search their own interoperability levels.

As a result, [8] introduced linguistic levels of interoperability divided into three levels: pragmatic level, semantic level, and syntactic level. The pragmatic level stresses data used in relation to data structure and context of application. The semantic level has a low level focusing on definitions and attributes of terms, and a high level focusing on the combined meaning of multiple terms. The syntactic level focuses on a structure and adherence to the rules that govern that structure. The linguistic levels interoperability concept provides a simultaneous testing environment at multiple levels.

18

Interoperability between heterogeneous software systems is an important issue to increase software reusability in the software industry. Many methods are proposed to implement interoperable systems using distributed computing infrastructures such as CORBA, HLA and SOA [9-11]. Those infrastructures can provide communication channels between software systems with heterogeneous environments. SOA (Service Oriented Architecture) provides a more flexible approach to interoperability than others because it provides platform independence and employs neutral message passing with Simple Object Access Protocol (SOAP) to communicate between a service and a client [12-15].

The research groups of DEVS modeling and simulation have been interested in interoperable DEVS modeling and simulation in order to enhance model composability and reusability with DEVS models and non DEVS models in different languages and platforms. The problem to interoperate heterogeneous DEVS models with DEVS simulators is that DEVS simulators implement the DEVS modeling formalism in diverse programming environments (e.g. DEVSJAVA, ADEVS, PythonDEVS) [27, 28]. Though the DEVS formalism specifies the same abstract simulator algorithm for any simulator, different simulators implement the same abstract simulator using different codes. This situation inhibits interoperating DEVS simulators and prevents simulation of heterogeneous models. Also, each simulator can not provide platform-neutral message passing.

The interoperable DEVS simulation has been tried to develop the interoperable framework through DEVS standard to simulate DEVS models generated in the different

19

languages and platforms. Some research of interoperability on DEVS has been studied along with HLA and SOA [10, 11]. Prior work includes DEVS/SOA which Mittal and Rico developed using web services [11]. However, it provides only platform interoperability because it employs JAVA serialization which converts JAVA objects into byte array to send messages to simulators. This restricts interoperation to simulators based on JAVA. To add the language interoperability to the platform interoperability, we apply neutral message passing and the SOA environment. The interoperability on DEVS uses simulator level interoperability that uses common simulator interfaces to simulate DEVS models. The simulator interface describes a minimum agreement being able to implement a simulator class using different languages such as JAVA, C++, and C#. This approach strengthens model reusability because DEVS modeling and simulation separates models and simulators. To increase model composibility, we apply a new construct called the DEVS namespace which is a specific XML namespace to define unique message types used at DEVS models in the DEVS simulator services. It provides semantic interoperability when we integrate different DEVS simulators.

The main contribution of this study is to design and implement interoperable DEVS simulation environment using SOA and DEVS namespace. The interoperable DEVS simulation environment is categorized to the design of DEVS simulator service and DEVS simulator service integrator. The DEVS simulator service provides not only simulator level interoperability, but also model level interoperability. Also, through the DEVS namespace, we can couple DEVS simulator services with same message types. In an interoperable DEVS environment, web services represent DEVS simulators

20

embedding specific DEVS models. They have minimum agreement for simulator and information of input/output ports which have specific data types described in DEVS namespace.

1.2. Organization of the Dissertation

Background knowledge, discrete event system modeling and simulation, SOA, and interoperability studies are discussed in the chapter 2. Chapter 3 addresses the overall system architecture of DEVS simulator service interoperability consisting of system of interoperability of DEVS simulator services, DEVS namespace, and DEVS simulation service integration and execution. Chapter 4 explains implementation of DEVS namespace and DEVS simulator services. In chapter 4 we demonstrate two DEVS simulator services using JAVA and VC++ with DEVSJAVA and ADEVS, respectively.

The example of integration of DEVS simulator services is presented in section 4. In chapter 5, we present application of interoperability of DEVS simulator services. The track display and negotiation systems are integrated among DEVS simulator services implemented with different languages. The testing agents system is implemented using DEVSJAVA modeling and simulation and DEVS simulator services with real time simulator. In chapter 6, we discuss the difference between concept level and implementation level in DEVS simulator service, as well as some issues about web service and platform. The dissertation’s summary and future work are presented in chapter 7.

21