Implementation of Service-Oriented Architecture for an Integrated Simulation, Training and Experimental Environment

Transcription

1 Implementation of Service-Oriented Architecture for an Integrated, Training and Experimental Environment Jason Keir; Christopher Millmore Virtual Environments & Laboratory (VESL) School of ITEE Abstract. Service-Orientation can be described as the decomposition of a complex system into its component elements for the development of a structure that provides the functionality required by the end user. Therefore, Service-Oriented Architecture (SOA) is the development of an architectural environment through which these element-functions can be implemented to provide those services. SOA was developed for the enterprise community to facilitate better understand of what business functions are required for the proficient and professional delivery of customer services. This philosophy, along with the design and implementation of service-oriented architectures has potential benefits for improving the delivery of the services required within integrated simulation, training and experimentation environments currently being used throughout the world. This paper highlights shortcomings of current simulation integration technology by analysing several architectures currently implemented within integrated simulation networks. An introduction to the development of a Service- Oriented Architecture for use within an integrated simulation and training network is explored. The capability and functionality improvements that this architecture provides over current technology will be highlighted in support of its introduction. Further, the paper will discuss negative aspects in the implementation of such an architecture and propose several possible remedies for these drawbacks. 1. INTRODUCTION With an increase in training requirements for Single and Joint Service, and International Defence Force Training in recent times, a fully integrated approach to training and simulation is mandatory. With the advent of Distributed Interactive (DIS) and High Level Architecture (HLA) within the last decade a high level of integration has been made possible. The interconnection of military asset simulators, command and control systems and constructive simulations has enabled an integration of training not previously experienced in the military. Now with the desire, and some would say need, to include virtual simulations and live data feeds from field exercises into the integrated training environment some problems are being experienced. One of the main problems is entity interaction resolution, and ownership of entity attributes, e.g. when data conflicts exist between normally autonomous systems within the integrated network of systems. Whilst DIS and HLA provide a significant level of interconnection and/or integration within the training and simulation fields, the development of architecture to help remedy the problems faced by these integration architectures must be investigated. A project was commissioned by Army Wing, Australian Regular Army, to investigate the range of currently available alternative integrated system architectures and provide recommendation of which architectures would potentially satisfy the future requirements of Army s simulation and training networks [9]. The investigation was performed by two students from UNSW, ADFA campus. The project included investigation into several currently available system integration architectures, including the incumbent HLA and DIS architectures. A range of architectural alternatives were then investigated, including Enterprise Application Integration (EAI) and Service Oriented Architecture (SOA), from which a recommendation could be made for implementation in future system integrations. SOA was determined the best of these alternatives from which the design of a future system integration architecture could be developed. The preliminary design of such an architecture was developed and proposed by the project team. An abbreviated description of this architecture is provided in the latter part of this paper. 2. DISTRIBUTED INTERACTIVE SIMULATION DIS is documented within the four components of IEEE Standard for Distributed Interactive [7]. This standard was developed to provide a network protocol facilitating the communication of simulation entity states to other discrete distributed simulations. This architecture was developed using the US Army s SIMNET [8] program and has been utilised throughout the simulation environment for over 10 years. DIS is capable of transmitting a range of data including a variety of entity related characteristic and state information. This data exchange occurs through the definition of Protocol Data Units (PDUs) for each of 67 currently detailed in the standard [5]. Additionally, DIS

2 also transmits information associated with the simulation application itself, i.e. Information relating to the operation of the simulation application across the network. With the recent integration of live and simulated exercises, DIS is also used to communicate information pertaining to the existence and state of live entities into the DIS network. DIS is based upon the following six basic concepts: a. No central computer controls the entire simulation, b. applications are autonomous and are responsible for maintaining the state of on or more simulation entities. c. A standard protocol is used for communicating ground truth data, d. Changes in the state of entities are communicated by the simulation applications, e. Perception of event or other entities is determined by the receiving application, and f. Dead reckoning algorithms are used to reduce communications processing time. Whilst many of the above concepts provide advantages in allowing simulations to remain discrete, these same advantages become disadvantages in a fully integrated network of systems. The main disadvantage of DIS is that for each additional participant within the DIS network an exponentially increasing number of connections between these participants are required, thus causing an increasing bandwidth requirement. Moreover, with an increase in PDUs to describe additional functionality, within the network and individual entities, a further increase in bandwidth requirements is needed to transfer that information within a timely manner [11]. Additionally, with no one computer controlling the interaction between entities within the DIS network, entity resolution cannot successfully occur. Thus, entity state conflicts may exist potentially causing the integrated simulation to be less effective. 3. HIGH LEVEL ARCHITECTURE IEEE STD , IEEE Standard for Modelling and High Level Architecture Framework and Rules is sponsored by the Interoperability Standards Committee of the IEEE Computer Society [6]. IEEE 1516 is the governing standard for HLA and outlines the requirements of HLA federates and federations, and associated rules to facilitate consistent implementation of HLA [10]. HLA is a systematic method of enabling the connection and transfer of data between otherwise independent systems [15]. These systems can be either simulations or other applications requiring access to a variety of different levels of simulated abstraction [3]. HLA was developed for the interconnection of autonomous simulation applications in an attempt to provide an integrated environment. The main difference between HLA and DIS is that only one member within the federation has control of entity characteristics, thus providing for an integrated network of systems. This integrated environment could then be used to facilitate a comprehensive range of simulation, training and experimental tools for the United States Department of Defense [4]. The Australian Defence Force (ADF) also utilises HLA to provide an integrated simulation, training and experimental capability. The collection and connection of simulations and applications are known as a federation. The federation is constructed in a manner that all information pertaining to the integrated network is transmitted via communications channel. Information applicable to individual members of the federation is addressed to those members, and information applicable to all federation members being broadcast, thus greatly reducing the bandwidth requirements of the integrated system. HLA s main advantage over DIS is that it is capable of performing networked simulation with either real-time or logical time based synchronization. This provides the ability for integration of virtual and constructive simulation [2]. HLA also supports aggregation and disaggregation of entities and units, thus facilitating the use of military command units as well as individual entities. Another advantage of HLA over DIS is through the pre-definition of HLA Federation Object Models, which greatly decreases the bandwidth requirement for data transmission [10]. However, HLA does have its disadvantages. The bandwidth decrease over DIS is offset with the cost of greater complexity in the system network operation. Also, whilst supporting aggregation, it suffers from the possibility of sub-entity characteristic conflict, especially if different simulations control aggregated entities with common attributes. These disadvantages, especially the latter, affects that the use of HLA, whilst better then DIS, is still limited in its use to provide a comprehensive integrated, network system. 4. SERVICE ORIENTED ARCHITECTURE SOA is an architectural framework primarily designed for implementation within the business world. SOA breaks down the business model into elements along with associated interaction between those elements. Each of these elements are then considered to be services, which are combined and recombined to form and describe the functions with differing scenarios and needs of a business [1]. Service Oriented Architecture provides a synergy between the core business of an organization and the information technology that supports the core business. Thus, a business can be divided into four main service domains, each containing and performing specific roles

3 within the complex system that makes up the business. Figure 1 illustrates the four domains, along with their interaction [1]. 5.1 Business Services The business service domain describes the uses of the system, e.g., Training and Experimentation. The following are some known activities that would be categorised as business services [12]. Command Training Training of commanders through the use of command and control systems fed with either/both simulated or live environment data. Mission Rehearsal Training of members prior to deployment to either field training of conflict zones. Small Unit Tactical Training Initial and continuation training of small units in tactical techniques used within exercise and operational areas. Figure 1: SOA Domains The business services domain represent the activities that are performed in response to customer needs. The application services domain is responsible for providing the necessary components, which supplies these business services. Infrastructure services provide the foundation for service operation i.e. providing an execution platform and utilities for the services being provided. Finally, the Enterprise Service Bus (ESB) facilitates the interconnection and interaction of the other three domains to complete the business framework. Figure 2 illustrates a basic implementation of SOA [1]. Figure 2: SOA Architecture Implementation 5. INTEGRATED SIMULATION USING SOA The domains and roles of service oriented architecture can be easily aligned to represent the needs of an integrated simulation network. The following provide the translation of these business related domains to that of the simulation environment. In each case the list of items provided is by no means exhaustive, however these lists provide sufficient detail to describe two proposed SOA implementations. Strategic/Operational Training Control of medium to large-scale single service, joint service, unilateral or multilateral level training exercises. Experimentation and Decision Support Provides facility for problem definition, exploration of possible solution and gain understanding of how changes to different parameters can affect decision outcomes. 5.2 Application Services The application services offer the tools through which the business services are provided. These services may include both hardware and software, and form the core part of the SOA implementation. With two proposed methods of implementation open to the development of a simulation and training network, the services represented in the application domain will vary. The application services for each implementation will be discussed in detail below [12]. 5.3 Infrastructure Services The infrastructure applications facilitate the integration of the training network through the connection of hardware, operating system, and software applications. These applications provide a variety of services ranging from network protocol, data integrity, network and system monitoring, and connectivity of application services within the networked training environment. These services may be represented by the integration and network applications, protocols and platform monitoring applications currently utilised in any networked environment [12]. 5.4 Enterprise Service Bus With the implementation of an ESB similar to that of HLA interaction of autonomous components through a centralized communications channel can be achieved. However, in SOA the communications channel may be implemented as a service, thus not only the control of data, but also the manipulation of that data [12].

4 One method of providing communication through the ESB is via the use of an XML-based message schema. Coalition Battle Management Language (CBML) is one possible solution providing interoperability between Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance Systems in a joint service and/or multilateral environment [13, 16]. 5.5 Entity Resolution The issue of entity interaction resolution remains within DIS or HLA integration solutions. If using current discrete applications, it is suggested that an external interaction resolution be performed with the results parsed into the application for processing. This external application would form the core service which would be responsible for the interaction of entities, synchronisation of events, and control of world physics. This core application could also be implemented using newly developed module-base applications which parse all necessary simulated or real environment data for entity resolution. 6. THE DEFENCE INTEGRATED SIMULATION AND TRAINING ARCHITECTURE (DISTA) With the recommended design of DISTA to be based upon that of SOA, there appeared to be two distinct realisations that could be implemented. The first, identified as Application-Based Services (ABS), utilised the existing application services, however provided a higher fidelity of integrated entity resolution then currently available. The second, Module-Based Services (MBS), proposed the building of sub-system components that could be combined to provide the systems necessary, then have these systems integrated to fulfill the framework required. Both these architectures provide the necessary framework to facilitate a successful simulation, training and experimental framework for the future. Figure 3 diagrammatically shows the domains of a Service Oriented Architecture implementation of the proposed Defence Integrated and Training Architecture [14]. T r a i n e e s I n s t r u c t o r s Business Services Command Training Mission Rehearsal Decision Support and Experimentation Small Unit Tactical Training Strategic/ Operational Training and Training Services 1PS Constructive Application Services C2 System and Training Data Bus Training Performance Monitoring Platform and Operating System Control and Monitoring Network Integration Control and Monitoring Infrastructure Services Real World Interface Entity Interaction Resolution Figure 3: Defence Integrated and Training Architecture Domains * 6.1 Application-Based Services The ABS implementation of SOA is one in which all applications are independent services, however an independent entity resolution service provides the integration of the otherwise discrete applications. A combination of the following applications could provide the components of such a system. First Person Immersive Environment any application that is capable of simulating a 3D virtual environment in the first person view. This is highly effective for training soldiers, e.g. Virtual Battlefield System (VBS). Command and Control System (C2 System) this is an application that allows access to C4ISR assets, in the form of via voice, video and data, in order to assist a commander in his decision making process. This application can be either simulated or real. Constructive a wargaming simulation application in which allows dynamic parameter changes to provide a constantly varying real-world. /Physical/Virtual Entity Interaction Resolution The entity resolution service is critical to the success of the networked simulation and training environment. This service provides resolution of all entity interaction within the networked training environment, and includes interaction between physical, virtual and simulated assets within the training environment. It allows for an accurate method of resolving combat between numerous simulations. Mission Recording and After Action Review These applications facilitate the capturing of temporal and event data pertaining to all individual and group units within the integrated training network. This data includes a wide range of attributes such as; unit position, health, damage or decisions made by commanders to provide complete and comprehensive replay of any training performed using the networked training environment. 6.2 Module-Based Services The MBS implementation of the Service Oriented Architecture requires the design and development of a modular component based architecture. Each component provides building blocks of applications needed to support functionality requirements of a simulation and training network. The following is a list of services and their intended use within the integrated training network. Again, this list is not exhaustive * Adapted from The domains of SOA, Bieberstein et al, Figure 3.1

5 however it shows the concept of this architectural solution. Graphics Engine this set of services provides a multitude of graphics and display functions to enable visual interaction with the vast array of constructive, virtual and/or immersive simulations, command and control facilities, replay tools, and data representation applications necessary within an integrated training network. Interfaces this set of services will enable both human and machine/network interface with the variety of constructive, virtual and immersive simulations within the training network. /Physical/Virtual Entity Interaction Resolution Again, this service provides the resolution of entity interaction within the networked environment. Physics Engine The physics engine enables the introduction of real world physical properties to entities within simulations. This provides simulated entities to have mass, size, interaction characteristics, etc and enables collisions and other physical interactions between simulated and physical entities, within the training network. Mission Data, Video and Audio Recording These services facilitate the capturing of temporal, event and other data pertaining to all individual and group units within the integrated training network. This data includes a wide range of elements such as; unit position, health, damage, communication between entities or units, or even decisions made by commanders, to provide a complete and comprehensive replay capability of any training performed using the networked training environment. Module-based services should be built in such a way that their integration forms complete applications, performing similar roles to those of the currently existing discrete applications. With the design of modular services, performing specific roles, a wide range of applications can be compiled using different modules. Due to the modularization of the applications the existence of multiple instances of any one module may exist within the network. Figure 4 demonstrates an example of several applications being compiled from the same array of smaller modularized services. First Person Immersive Graphics Engine Training and Application Command and Control System Interfaces Physics Engine Constructive Module-Based Services Data/Video /Audio Recoder After Action Review Visualiser Entity Interaction Resolver Figure 4: Applications from Module-Based Services 7. CONCLUSSION DIS and HLA have and will continue to facilitate the partial integration of networked simulations and application into the future. However, these legacy architectures only provide a limited degree of integration. To provide the higher level of fidelity necessary to facilitate true integration and assimilation of systems these legacy architectures will need to move aside and allow implementations of recently developed architectures, such as SOA, to be built in there place. The major disadvantages of SOA type architectures are that increased complexity and perhaps increased bandwidth requirements may be necessary. Additionally, this increase in degree of system complexity comes with the additional expense of implementation of a new architecture. However, advantages of SOA include its inherent ability to facilitate the use and reuse of element components from a system of systems approach, and support platform and operating system independent interoperability. 8. FUTURE WORK Whilst it was determined that the implantation of SOA could improve the level of integration in an integrated simulation, training and experimental network it would necessitate the utilisation of increased bandwidth and system complexity. Future work should be carried out to quantify these increases, and possibly investigate methods of reducing any impact upon hardware and network capability. REFERENCES 1. Bieberstein N, Bose S, Fiammante M, Jones K, Shah R, Service-Oriented Architecture Compass Business Value, Planning, and Enterprise Roadmap, Chapter 1 Introducing SOA, IBM Press, New Jersey, USA, Clark P, Ryan P, Zalcman L, Advanced Distributed for the Australian Defence Force, DSTO- GD-0255, Air Operations Division Aeronautical and Maritime Research Laboratory, DSTO Melbourne, Victoria Australia, October 2000

6 3. High-Level Architecture Rules, Federate Rules, IEEE P1516/D1 April 1998, US Department of Defence 4. High Level Architecture, United States Department of Defense Defense Modelling and Office, [Sep 2006] IEEE1278.1a-1998 IEEE Standard for Distributed Interactive Application Protocols, approved 14 March IEEE Standard for Modelling and (M&S) High Level Architecture (HLA) - Framework and Rules, IEEE STD , IEEE-SA Standards Board, Approved 21 September IEEE Standards Online, Computer Standards, accessed Sep 2006, 7. Jones A, The Future of DoD Modelling and : Strategies, Plan, and Partner, Keynote address at the 17 th Interservice/Industry Training Systems and Education Conference, Albuquerque, New Mexico, November, Keir J, Millmore C, Introduction, Section 1.1, Architectural Alternatives for the Defence Integrated and Training Architecture, School of Information Technology and Electrical Engineering, ADFA, UNSW, Ibid, TENA, JSAF and the High Level Architecture Gateway, Section Ibid, Architectural Alternatives, Section Ibid, Service Oriented Architecture, Section Ibid, Coalition Battle Management System, Section Ibid, Defence Integrated and Training Architecture, Section Kuhl F, Weatherly R, Dahmann J, Creating Computer System An Introduction to the High Level Architecture, Chapter 1 - Introduction, Prentice Hall, New Jersey, Sudnikovich W P, Pullen J M, Kleiner M S, Carey S A, Extensible Battle Management Language as a Transformation Enabler,, Vol 80, No 12, December 2004