Service Oriented Simulations Concept Per M. Gustavsson; University of Skövde Högsolevägen, SE-541 28 Skövde, Sweden
[email protected]
Tomas Planstedt; Gunnar Karlsson; Christoffer Brax; Åsa Björk; Modeling and Simulation Ericsson Microwave Systems AB Storgatan 20, SE-541 30 Skövde, Sweden
[email protected] [email protected] [email protected] [email protected] Abstract. In the effort to provide simulation support to the future Network Based Defence (NBD) that are currently being applied by the Swedish Armed Forces (SwAF), and the similair work within US and NATO, the authors opinion is that simulation should be treated as any other services, existing in the operational systems. Meaning that architecture should be conformant between the operational and simulated systems, for a start use the same infrastructure. The choice so far for simulation is the High Level Architecture (HLA). During the author’s participation in ongoing work supporting NBD, questions have gradually been raised if HLA is the simulation path to walk. In the Core Enterprise Services (CES) and Swedish Armed Force Enterprise Architecture (FMA) Services IT-Kernel, core services are specified and HLA do address a lot of non-simulation specific services giving unwanted redundancy. However, the services already defined may with some enhancements deliver the same services addressed within FMA Services ITKernel. The Next Generation HLA could be more than just a simulation standard if it utilizes the FMA ideas. In this paper the authors present the ongoing work, as it stands today, with Service Oriented Simulations, that is an outlook for simulation using the architectural structuring, services, components and infrastructures concepts evolving in FMA and Global Information Grid (GIG). The focus of the work is to enable interoperable simulation support for the whole system lifecycle – Acquisition, Development, Training, Planning, In-the-Field decision support, System removal – within NBD, entailing that the architecture for simulation is uniform regardless of its application and giving end-users the capability to focus on what to simulate instead of how to simulate.
1.
INTRODUCTION
In this paper we present the major ideas behind the concept of service-oriented systems within the SwAF. A framework for simulation using Service Oriented Architecture (SOA) concepts is introduced. Ideas for enabling HLA to meet the requirements of SOA are also presented. 2. THE CHANGE Ever heard of Revolution in Military Affairs (RMA)? Looking back at the military history there has been a lot of RMA along the way, for example when automobiles, airplanes, submarines, aircraft carriers, wireless communication etc occurred for the first time, changing the war fighting for ever. One thing that the warfighter1 can be sure of is that constant change will be the normal condition. The challenge is to use this dynamic in a positive manner. War and Peace is obsolete to use since when the Armed Forces conduct operative missions it will be in some sort of crises or conflict [1]. To handle this change The Joint vision 2020 document[2] as well as the Swedish 1
warfighter – could also be a civilian or government employee that has a mission to accomplish.
FMLS2010 document[3] tells us the NCW/NBD visions. The work in implementing this vision in SwAF is done through the development of the future business model FMA. [4] This new technology land winnings and those yet to come lead without doubt to an increased amount of information that a warfighter needs to sort and filter. The full impact of information overload has not yet been seen. Developers are still in the phase where they cheers joyfully, “Hey, I just got this system connected with that one and they exchange information” but it’s not always that the whole process is really thought through. But warfighters, vendors and developers must not forget that Network-Centric means networking in a broader sense than just focus on technology; Systems, Business, Organizations, Personnel, Information and Technology all represent different views of the networking architecture[1]. Focusing only upon technology is not sufficient enough. The view must change so that the horizon gets broader enabling that the development of simulation support for the future is based on all the good work being done. 3. THE NEEDS The warfighter, regardless of it is in a simulation or in the real system may need accurate, timed, adequate,
recognizable information, and it should be delivered ondemand. Depending on the warfighters mission the need of information varies in quantity and quality and the information sources might change over time. The overall approach – methodology, information exchange models, architecture, design, communication etc. – in building systems of the future ought to be the same regardless of what system that is to be built so that the systems are fully interoperable and back and forward compatible. 3.1 The solution for the future Currently the Global Information Grid (GIG), the NATO Net Enabled Capabilities (NNEC) and the Swedish Armed Force Enterprise Architecture (FMA) all enables interoperability in a layered structure: i.e. at the Technological, Syntactical, Semantically, Dynamical/Pragmatically and Conceptual interoperability [5, 6]. The GIG, the NNEC and the FMA are all built on system views containing the perspectives, Enterprise Services (capabilities), Enterprise Systems, Enterprise Functions, and Enterprise ability organized as a Capability Package (CP) with Technical,- Information- and Personnel components. In order to achieve interoperability in reality as well as in the simulation domain we suggest that Service Oriented Architecture (SOA)2 should be embraced in the HLA standard to take care of the technical interoperability problem of services. 4. SERVICE CONCEPT The service concept within FMA is straightforward and describes the interaction between a consumer3 and a provider. The consumer receives something with a value (the service) from a provider, in exchange for some suitable compensation. Unfortunately often an equality sign is put between service and interface leading software developers to think that just the use of CORBA makes the system service oriented. The service description is essential and do not only describes data structure/interface but also the provided capability, quality and the service verified usage. A service is on a higher level where the used technology is of subordinated significance. Services are there since they live longer than its implementation. It is presumable true, that even the cave men4 cleaned their homes using some kind of tools in the cleansing work. Back in 1865 the Whirlwind5 made it easier to clean the house and in 1907 the electrical “suction sweeper”
2
A service-oriented architecture is essentially a collection of services. These services communicates with other services, sharing information data etc. 3 Notice that the consumer is placed before the provider indicating that the consumer needs are in focus. 4 Men – It is even more presumable true that women actually did the cave cleaning. 5 The first hand-pumped vacuum cleaner in the United States was the “Whirlwind,” a wood and canvas contraption that appeared in 1865.
2
appeared. The technology has made it easier but the service specification is the same – Freshness.
S
SD
P
Figure 1 – Service Provider, Consumer and Service Description. The FMA Services (FMAS) is based on loose coupling between consumers and providers. The Service should not reflect the way the provider implements the service allowing multiple implementations of FMAS. The data/information properties should be generic and kept at a level that still has a meaning for the consumer and the interface and service goal needs to be well documented. [4]
To benefit from SOA descriptions of the services and a mechanism for connecting services to each other need to be defined. In the work within the FMA a reference implementation has been developed addressing these two issues. The result implies a possibility to enabling the GIG, NNEC and FMA to entail interoperability both horizontal and vertical. For an example, the SwAF Mission Capability Package (MCP) is built upon a system view containing the perspectives system, business, personnel, organisation, information technology and environment. It constitutes a framework (SwAF Architecture Description Framework, ADF) to describe capability requirement, formalized as Enterprise Services, within a standardized development process (ISO 15288). The purpose of EA is to establish a common foundation, regarding development methodology, including conception, development and production processes and relations between various parts of a system [3]. Within this work the technical core service is an enabler which give the ability to provide other IT-infrastrucural services. Some of them are introduced in the reference implementation (OpenSIS[7]). At least two services were needed as core: the naming service and security service. 5. SERVICE ORIENTED SIMULATIONS So, will this NBD change the usage of the simulation systems? Not necessarily, if there is no need from warfighters to exploit the potential of the emerging systems that are developed.
The idea of Service Oriented Simulations is to 1. Use the FMAS in the same way as it is used for NBD; utilize
enriched ability to conduct war fighting in a more precise, effective, efficient way and with anticipation prevent the actual conflict, situation turnover to a weapon mission 2. Use the simulation community developed standards and all the lessoned learned knowledge. 3. Use the Software Engineering knowledge in methods for developing software and also the various standards, techniques, mechanisms that provides realtime, distributed systems, databases and artificial intelligence. These three parts gives the Service Oriented Simulations idea[8]. When enabling the warfighter with a whole new set of tools for conducting their business it is not particular hard to imagine that in the process of learning and using these new system a variety of new desires and requirements will arise. One such desire that already has been identified is In-the-Field decision support; since the service concept in the FMAS implemented in OpenSIS makes it possible to connect to a service provider it is presumed true that if this service provider also provides a model of its service it is no harder to connect these models into a simulation that it is to build a real situation adopted system through a SitSyst6 builder. Simulation has, still is and will be used in the whole lifecycle of the system i.e. Acquisition, Development, Training, Planning, In-the-Field decision support and System removal. Now is the time to enable simulation infrastructure with the same transparency that are within the FMAS enriching the NBD vision further. 5.1 Some thoughts about Modeling and Simulation Looking at NBD, NSN and considering simulation as a part of those future systems and their environment, it seems likely to believe that simulation will be more used in the future. It do not seem enough to patch current standards one-step at the time without an M&S vision. One such vision could be to use the key features stated within NBD and apply them to modeling and simulation. Fast and efficient to use: M&S should be fast and efficient to use so that warfighters can practice and experiment together. The outermost usage is in planning, training and decision support systems. Fast and efficient to develop: M&S should be fast and efficient to develop. There must be easy to use support for building models, simulations, scenarios and simulation infrastructures on demand. Enable transparency: M&S should be transparent so it is easy and smoothly too adapt to legacy, current and future systems. Handle constant change: M&S should manage to exist in a constant changeable environment eager to support whatever arising simulation needs. M&S should also 6
SitSyst – Situation Adapted System Configurations Tool
3
have a readiness for extension of participating federates in runtime. Secure: M&S should have the same security as the operational system. A warfighter does not want an opponent to see his ideas, during training, planning and/or in-the-field simulations. 5.2 HLA adoption How does HLA adopt to the NBD key features in 5.1. It both does and does not. Since the intention of HLA was not to be the common interoperabilty framework for both operational and simulation. HLA is built for simulation.
So HLA is not a path to take for the future? It might be if it incorporate ideas from Model Driven Architecture[9] and turns towards Service Oriented Simulation thinking. 5.3 Use of the FMAS So, if specific simulation services are identified, described and implemented, how well will FMAS support simulation? Fast and efficient to use: If the FMA work is a success for the joint C4I systems it will also be sufficient for the simulation services. The warfighter will use the same methodology for both the operational and simulated systems. Planning, Training and experimentation in the systems can start early since simulation services and model services are built upon FMAS enabling early usage of simulation. Fast and efficient to develop: If the FMA work gives the General Design Principles needed to build services. And SitSyst gives the easiness in configuration. Modeling and simulation will use the same concepts, information exchange models, interfaces and also takes benefit in that there are services of mutual interest such as log and replay, system management, security, directory lookup, grid computing, real-time guaranties and distributed databases. Also, the process will be more efficient since the focus will rely on what to simulate and not how to connect things with each other. Enable transparency: If FMA can handle it and simulation is a part of it. It will be as transparent as the rest of FMAS Handle constant change: If FMAS can handle constant change in its architecture likewise the operational services, then also the simulation and models services will handle constant change. When building a simulation the need to know all possible systems that should participate in the simulation is not necessary a priori. In an operational mission where the situation changes and resources are reallocated or added the FMA/(GIG) enables communication between various systems. Systems, previously not connected, can join in the
operation seamlessly. Since the communication channel exists and data types are declared instant access to the implemented system models will also be gained. Secure: Since FMAS does have APIs for both HW and SW security support and the operational system is securely connected the simulation will also be secure with the same authorization policies. The warfighter does not want an opponent to see his ideas, when training, planning and in-the-field and maybe his partners should not be able to see everything either. Tunneling might be requiered if the security is software plugin-based. 5.4 Simulation Services In finding applicable services the basis is FMA, HLA, CES and subordinate applicable work has been used.
Since HLA[10] is the most useful simulation standard and do address a lot of simulation and non-simulation services, however not described in FMAS taxonomy, it is used as a foundation in finding simulation services. Federation Management is not a pure simulation service since creation, dynamic control, modification and deletion of a federation is like the basic services in FMAS, CES. So it is not needed to use from HLA. For example the synchronization point service and restore service are not only exclusive for simulation. Declaration management (DM) implies that a federate should declare their intention to generate information. This service is there to ensure that only relevant data is transmitted over the network when federates start to deliver data. But is this not also a non-simulation specific service? Object management deals with registration, modification and removal of object instances and the primary function is to reflect attribute values and update attribute values. If no one requests information there is no need to send out any on the network. It is also those who requested the information in the DM that gets updates. This is neither unique to the simulation domain. The same principle is in the FMAS. Ownership management is when joint modeling is to be used; a model is updating another models parameters. This service needs to be in the NBD world since the warfighter might have the authority to use all enable weapon services within a certain range. When a platform with a weapon service (object/attribute in HLA) enters this region the allowance control of weapon fire is controlled by the warfighter in command. Not the platform commander. Time management is the only specific simulation services found so far that needs to be especially addressed by the simulation community. It is not needed by it self in the NBD but if simulation should be used in HLA, time service should be used.
4
Data distribution management deals with reducing network traffic and irrelevant data. Hereby clustering objects that exchange information with each other and once again a service not unique for simulation. Support services is specific to HLA and are not of special interest in the Service Oriented Simulation concept since change of the other will also change the need for special support services.
The majority of the non-simulation specific areas addresses Distributed Real-Time, Database and Information Fusion issues and are either already addressed within FMA, FMAS, GES, and CES or addressed in their specific research areas. However, the services must be there to enable simulation interoperability and also for the overall usage of the future NBD systems. 5.5 Modeling and Simulation Requierements Modeling and Simulation should be able to handle constant change, give rich flexibility, and be technology independent, the service lives longer than its implementation provide secure joint simulations. The use of FMAS concept together with general design principles that are emerging in FMA, regarding nonsimulation specific services will be used in developing the simulation service structure. The same methods, tools and information models will be used so that duplication of work is minimal. Enabling the simulation developer to focus on what to simulate not how. 6.
NEWIDS – IMPLEMENTATION
Our approach has been evolved during the last five years and an experimental platform called NeWiDS – Net Wide Distributed Simulations has served as our reference implementation. The experiments has tried variarity of implementations in how service oriented simulations should be implemented. The Development in its essence The development of the NeWiDS during the past years has been closely connected to the MjUKT 7competition and is briefly described in the following chapter. During the start at 2001 and a CORBA framework that lived to 2003 when HLA was introduced and a more rigid use of the ideas from FMAS and Service Oriented Simulation was used. A number of services was developed to support remote startup and execution control of models, dynamic loading of scenarios and robust restart of the system with save points. Some of the ideas described in [11] has coincidentally been used. NeWiDS 2004 supporting MjUKT 04 is implemented upon the OpenSIS and well aligned with the concept within Service Oriented Simulations from FMAS. The
7
MjUKT – A 24 hour software competition by Ericsson and University of Skövde, Sweden
key to good simulation is a good Time management service.
Federate
im
During 2001-2003 a lot of work consisted of looking at distribution mechanisms and guarantee real-time performance. From 2003- up until now the focus has been in using FMAS and/or HLA as the base for Service oriented Simulations. 6.1 Present Currently NeWiDS is used in two internal projects at Ericsson as the simulating infrastructure and the work of implementing the Service Oriented Simulation Services continuous along with the writing of a cookbook and building GUI-tools to support the user. NeWiDS and the Service Oriented Simulations will be used as one of the platforms for Information Fusion research at University of Skövde, Sweden 7. BEYOND HLA EVOLVED From the work of using Modeling and Simulation (M&S) in demonstrating the benefits of net orientated systems as well as using M&S as a tool within the C4I systems the comparision described in paragraf 5 a comparision between HLA and Service Orientation is made in brief.
One of the conclusions made was to examine additions the HLA standard need to address in order to meet the needs in GIG, NNEC, SwAF Enterprise Architecture (EA) when it comes to both simulation services and non-simulation services. At least two services are needed as core: the naming service and security service. 7.1 HLA/ RTI One could look at a RTI as an implementation of HLA e.g. an instantiation of a number of adoption services providing the simulation capability (History and Future) into the GIG, NNEC and EA. Hence, why not use the same naming/active directory mechanisms in both domains and enabling the same methods and taxonomy to be used and achieving interoperability between the two domains?
ple m
1 AbstractCapability
1
n
en
t 1..*
Capability
CapabilityList
Figure 2 FCOM class diagram
In the figure above (Figure 2) an example architecture is presented. The model is intended as a basis for discussions in order to find a structure, the entities, the capabilities and so forth that enable to suggest a FCOM that follows the ontology and semantics within HLA entailing a smooth evolving of HLA. The main idea is that a list of capabilities is connected to a federate. The capability list could be aggregated into more capabilitylists that also could be aggregated enabling a dynamic architecture in expressing capabilities. ISR: Model
C2: Model
Execute: Model
Information: Communica tion:Transmission: Model Model Model
FCOM CapabilityList
Type Federate
de scibes in
has
Capability
Federate
Platform: M odel
de scribes in
Fe derate List
Figure 3 FCOM instance
An example FCOM instance is shown in Figure 3 above. An HLA-federate consists of a several models for different parts of a modeled system each contributing to the total federate capabilities. The FCOM (a CapabilityList) for the federate is composed of capability lists for each model within the federate. Each capability list is in turn composed of capabilities or capability lists).
7.2 Naming/Active directory The next step is to explore how a naming/active directory can be constructed. One idea is to add a Federate Capability Object Model (FCOM) that enables an active directory full dynamic naming service application to be developed entailing the vision within the GIG, NNEC and SwAF EA.
Methods/Interfaces for communicating with the FCOM are also needed to be addressed within the work of the future work. One such method that is already identified is findFederateByCapabilites(). Enabling to ask other federates what other capabilities they have.
In order to complete this mission theoretical as well as practical we suggest that the HLA, GIG, NNEC, EA, SOA, Web Services, OpenSIS[7] etc Architectures/structures should be used as a foundation to deliver results that suggests standard changes for HLA.
8. CONCLUSION There is a growing consensus among many simulation developers that the HLA standard does not apply in NBD. Therefore the Next Generation HLA needs to meet the wider needs and expectations within NBD, NCW and NSN domains. The work conducted here and
5
the future proposed work entails that HLA will be the simulation standard to use, perhaps not only for simulation purposes. REFERENCES 1. Göran Skogsberg, NBF Vision Leding - En idéskiss ur ett samhällsperspektiv, 2004.
2.
United States. Joint Chiefs of Staff., "Joint Vision 2020." Washington, D.C.?: Joint Chief of Staff, 2000.
3.
Försvarsmakten Högkvarteret., "Målbild för utveckling av försvarsmaktensledningssystem 2010," 2003.
4.
G. Öhlund, J. Bendz, P. Johannisson, and P.-G. Jönsson, "The Swedish Armed Forces Enterprise Architecture," 03E-SIW-049, 2003.
5.
A. Tolk and J. A. Muguira, "The Levels of Conceptual Interoperability," presented at Fall Simulation Interoperability Workshop, Orlando, Florida, 2003.
6.
A. Tolk, An Agent-Based Decision Support System Architecture for the Military Domain: IOS Press B.V., 2004.
7.
"OpenSiS," http://www.OpenSIS.org, 2003.
6
8.
P. M. Gustavsson, Å. Björk, C. Brax, and P. Planstedt, "Towards Service oriented Simualtions," presented at FallSIW 04, Orlando, Florida, 2004.
9.
A. Tolk, "Avoiding another Green Elephant - A proposal for the Next Generation HLA based on the Model Driven Architecture," presented at 2002 Fall Simulation Interoperability Workshop, Orlando, 2002.
10. S. I. S. Committee, "IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) - Framework and rules," IEEE 1516-2000, 2000. 11. A. Tolk and J. M. Pullen, "Ideas for a common Framework for Military M&S and C3I Systems," presented at 2003 Euro Simulation Interoperability Workshop, Stockholm, 2003.
Acknowledgements The work with Service Oriented Simulation could not be performed without the efforts from all employees at the Modeling and Simulation office, Ericsson Microwave Systems AB. A special remark must also be made to the productive innovative co-operation with University of Skövde. One must not forget all discussions that have been held with FMV and Pitch and other customers, competitors and users.
