Simulation Interoperability Workshop, Paper 09F-SIW-022

1

Composability Requirements for the Open Unified Technical Framework

Jeffrey S. Steinman, Ph.D. (Contractor) Craig N. Lammers (Contractor) Maria E. Valinski (Contractor)

Joint Program Executive Office, Chemical and Biological Defense Software Support Activity

Space and Naval Warfare Systems Center, Pacific

53560 Hull Street San Diego, CA 92152-5001

(858) 605-1646

steinman@warpiv.com, craig.lammers@warpiv.com, maria.valinski@warpiv.com

Key Words: Open Unified Technical Framework, OpenUTF, Parallel and Distributed Simulation, PDES, PDMS, HPC, FMS,

Multicore, Manycore, Publish/Subscribe, OpenMSA, OSAMS, OpenCAF, WarpIV Kernel

ABSTRACT: This paper outlines and presents a list of twenty-five key composability requirements for the Open Unified Technical Framework (OpenUTF) that is being developed for use by the Joint Program Executive Office for Chemical and Biological Defense (JPEO-CBD) and several other programs. The need for such a framework has been identified in the CBD Modeling and Simulation (M&S) Strategic Plan, which has been signed and is now being implemented by the CBD M&S Integrated Product Team (IPT). This strategic plan impacts all common and crosscutting M&S within the CBD community. Many factors motivate the need for change in how M&S capabilities are designed, developed, tested, validated, operated, and used to solve a wide variety of real-world problems. Applications include analysis, acquisition, test and evaluation, training, planning, and live decision support. With budgets tightening and new multicore computing technologies demanding radically different programming methodologies, it is imperative to establish a common framework that facilitates flexible software composability, scalable parallel and distributed performance on a wide variety of computing platforms, and interoperability within net-centric environments. Twenty-five key requirements are elaborated upon in this paper. The benefit of establishing each requirement is discussed, along with technical approaches taken from the open source reference implementation. Based on the reference implementation and past efforts, the requirements listed in this paper are realistic and fully implementable. 1.0 Introduction

Chemical, Biological, Radiological, and Nuclear Defense (CBRND) heavily relies on M&S due to prohibitive development costs of systems and important safety concerns involved with live testing of deadly agents. JPEO-CBD recently drafted a comprehensive M&S strategic plan that will bring about important long-overdue change much needed by the broad community.

There is an emerging need for change in M&S…

Over the past 10 years, many M&S tools have been developed for the DoD that are not in use today, primarily because they (1) do not easily interoperate with other tools, (2) run too slow, and/or (3) are too expensive to maintain. Life-cycle support is not always provided for critical tools that are used infrequently. In addition,

computing technology is rapidly migrating towards multicore chip designs [26], which means that most computationally intensive M&S tools will soon become obsolete unless they are able to make the transition to parallel computing. The DoD M&S community must address these serious problems soon [46].

The problem is not that we need to do things better… We need to do things differently!

The kind of change we need is revolutionary, not

evolutionary.

An Open Unified Technical Framework (OpenUTF) [47] has been proposed as a cost-effective, high-performance, scalable, service-oriented, software development framework for implementing net-centric Modeling and Simulation (M&S) and Service Oriented Architecture

2

(SOA) [42] applications for the Chemical and Biological Defense (CBD) program. The need for a standards-based unified technical framework is described in the CBD M&S Strategic Plan [22]. This plan was recently signed by the Joint Program Executive Officer for CBD, and is being implemented by the CBD M&S Integrated Product Team (IPT) [23] that spans across all relevant M&S organizations within the CBD community. Several key organizations and simulation programs are now migrating their models into this framework.1 The list of users and sponsors outside CBD is also growing.2

Figure 1: The proposed OpenUTF is a government-managed collection of open systems and tools developed and maintained by individual organizations. These open systems operate within a common technical framework based on the OpenMSA, OSAMS, and OpenCAF synergistic architectures.

The OpenUTF Kernel provides an open source core infrastructure for the technical framework. United States government programs have unrestricted use of this open source kernel [48,52]. It is based on three synergistic architectures known as (1) Open Modeling and Simulation Architecture (OpenMSA) [40], (2) Open System Architecture for Modeling and Simulation (OSAMS) [43], and Open Cognitive Architecture Framework (OpenCAF) [50].3 These three architectures facilitate the development and execution of composable models [8] and/or services that transparently interoperate in real, scaled, or logical time.

1 A pilot program is underway to integrate relevant CBD

models into the OpenUTF. Participants include Edgewood Chemical and Biological Center (ECBC), Dugway Proving Ground (DPG), Naval Surface Warfare Center (NSWC), Dahlgren, and others.

2 Users include the Air Force Research Laboratory (AFRL) Rome NY and the High Performance Computing Modernization Program [19] efforts at SPAWAR Systems Center (SSC), Pacific.

3 These architectures have been within the Simulation Interoperability Standards Organization (SISO) [33] Parallel and Distributed Modeling and Simulation Standing Study Group (PDMS-SSG) [31].

Various time management modes are supported in a manner that is transparent to models [49]. The mapping of user-developed software components to composite structures that are automatically distributed across processors is performed dynamically at run time. All modern platforms ranging from portable laptops to supercomputers and mainstream operating systems4 are seamlessly supported [25]. Communications through shared memory and/or across networked computing platforms is automated through elegant event-scheduling mechanisms that are coordinated in abstract time. The OpenUTF provides an incremental strategy that (a) supports the integration of legacy systems, (b) provides several programming models to parallelize existing systems for execution on multicore computers, (c) promotes a migration strategy of existing software models and services, and (d) provides a technical framework for developing next-generation scalable composable software components.

2.0 Twenty-five OpenUTF Requirements

This section outlines and describes twenty-five high-level requirements that are essential for supporting the scalable, composable, and net-centric computing [1,29] interoperability goals of the OpenUTF.

2.1 Separation between Engine and Models

Requirement #1: The general-purpose event-scheduling engine and its modeling framework constructs must remain separate from actual user-defined services and models. The engine must not contain any application-specific code.

Benefit: This maintains a clean separation between the technologies necessary to support high-performance, scalable, net-centric applications from the user-defined applications themselves. The resulting benefit is easier to develop and maintain models, along with a more robust technical framework. Technologists are able to transition technologies into the OpenUTF, while Subject Matter Experts (SMEs) and scientists are provided the necessary software modeling constructs to represent their complex systems in a clean manner.

Technical Approach: The OpenMSA provides well-defined technology layers that are necessary to support this requirement. The OSAMS and OpenCAF architectures, contained by the OpenMSA, provide elegant modeling constructs for applications to use in representing their specific systems.

4 Operating systems currently supported by the OpenUTF

reference implementation are (a) Windows XP/Vista, (b) Mac OS X, Linux, and all other UNIX systems such as Solaris, HP-UX, AIX, IRIX, etc.

3

2.2 Optimized Communications

Requirement #2: The underlying high performance communications framework must be standardized, abstracted from application code, and highly optimized on different computing platforms for robust operation and performance.

Benefit: Application-specific services and models are represented using high-level programming constructs and are not concerned with low-level interprocess communication mechanisms. Event-scheduling operations between composites residing on different processors is automated through this high-speed communications layer.

Technical Approach: A standard high-speed communications interface has been designed, reviewed, optimized, and developed by multiple organizations over the past 15 years. Universal communication services have been specifically defined to support parallel discrete-event simulation applications on all imaginable mainstream-computing architectures. Benchmarks have consistently shown that performance on mainstream computing platforms is significantly better than other message passing infrastructures.

2.3 Abstract Time

Requirement #3: The representation of time must be abstracted in a manner that transparently supports both scaled real-time [5] and logical-time modes of operation. User-written software models and/or services operate transparently in either mode. For logical time modes of operation, time must be represented in a manner that supports rigorous repeatability when running in parallel and distributed M&S [15] computing environments. This means that all events within a simulation run must have unique time tags.

Benefit: Abstract time allows the OpenUTF to support many types of applications in a uniform way. This promotes software interoperability, which lowers the cost of software development, integration, and testing efforts. Operational services and models alike are able to interoperate within the same framework, which is ideal for testing and evaluating software systems.

Technical Approach: Time is represented as a complex data type. Operator overloading in C++ allows time to be used as a continuous double-precision variable, but with additional tie-breaking fields that guarantee each event has a unique time tag. Users can manually set tie-breaking priority fields. However, the OpenUTF automatically sets hidden tie-breaking fields to ensure that every scheduled event has a unique time tag.

2.4 Scheduling Constructs

Requirement #4: After user-defined software components are plugged in, distributed, constructed, and initialized, all processing occurs through time-tagged events. This includes data distribution, interactions, notifications, and interrupts that might affect the behavior of user-defined software components. Applications never directly invoke methods on composites that might reside on other processors.

Benefit: Scheduling constructs unify how computations are performed in scaled real-time and/or logical time.

Technical Approach: After plugging in software components, applications essentially turn the thread of control over to the framework, where their distribution, construction, and initialization occur. Initial time-tagged events are scheduled for software components during the initialization phase. The OpenUTF then processes events as execution proceeds forward in abstract time. Events potentially schedule new events to propagate computations over abstract time. Optimized high-speed communications facilitate event scheduling and time synchronization between compute nodes using shared memory and/or network protocols [44,53].

2.5 Time Management

Requirement #5: Time management modes must be selectable at run time. Time management is a mechanism for coordinating event processing in a time-abstracted application. Services and models must operate in a manner that is transparent to the time management mode selected at run time. Time management modes include (a) sequential, (b) parallel-conservative lookahead-based [13,14], (c) parallel-conservative topology-based [6], (d) parallel-optimistic [20,28,34,37] with flow control to promote stable execution, (e) parallel five-dimensional [45], and (f) scaled hard/soft real time [49].

Benefit: Allowing the time management mode to be selectable at run time promotes interoperability and reuse for user-defined software services and models under a wide variety of usages.

Technical Approach: Programming constructs provided by the OpenUTF for user-defined software components must never be specific to the time management mode selected during execution.

2.6 Encapsulated Software Components

Requirement #6: A universal set of programming constructs for plug-and-play user-defined software components must be provided to support encapsulated

4

services and models. Components provide an abstraction for models and/or services.

Benefit: Software components provide a standard construct for implementing services and models. This promotes composability, interoperability, reuse, and scalable performance in a unified manner.

Technical Approach: An OpenUTF-provided C++ component provides the base class for plug-and-play software services and models. Other associated user-defined classes can be freely developed within user-defined components.

2.7 Hierarchical Composition

Requirement #7: Hierarchical organizing and grouping of user-defined service and model components must be dynamically performed at run time. The composition structure of user-defined components must never be hardwired.

Benefit: This promotes a highly flexible way to organize collections of interoperable components.

Technical Approach: A composition file is used to specify hierarchical component relationships, along with their performance parameters. The OpenUTF automatically constructs components according to these relationships.

2.8 Distributable Composites

Requirement #8: The OpenUTF must provide a way to define distributable composites that are hierarchically composed of components. Composites are automatically distributed across computing nodes during execution. The components residing within each composite are instantiated on the same node as the composite. Applications must be able to distribute and create composites during initialization. Applications must also be able to dynamically create and delete composites during execution in abstract time. Applications are able to optionally specify node placement of dynamically created composites.

Benefit: Distributing composites across processors supports scalable high-performance operation in networked multicore computing environments.

Technical Approach: Entities that are composed of model components, collections of related services, and/or simulation objects are represented as composites that are distributed across computing nodes. User-defined objects within the components of a composite can invoke methods on other objects. However, formal event-scheduling techniques are required to support interactions

between composites, which may reside on other processors and/or systems.

2.9 Abstract Interfaces

Requirement #9: Abstract interfaces must be provided to efficiently support mutual interactions between components that reside within a composite. User-defined components never directly invoke methods of other user-defined components. Scoping and filtering constructs must be provided that limit which registered components respond during service invocations.

Benefit: This formalism is essential in maintaining plug-and-play interoperability. Software components must never depend on specific implementations of other software components. This formalism also supports dynamically swapping different model representations in and out of the execution environment.

Technical Approach: User-defined interfaces are created with special macros in C++ that automatically code-generate functions for dynamically registering methods on user-defined objects that are capable of supporting the interface, unregistering their methods, and actually invoking the abstract services. Hierarchical scope resolution and/or string-based tags can be used to filter which components are allowed to respond when an abstract interface is invoked. Each component is associated with at least two tags, which are the type of component and the name of the component. Additional tags can be assigned to components. Scope resolution can localize abstract service invocations to occur on component subtrees that reside within a composite.

2.10 Interaction Constructs

Requirement #10: Interaction constructs must be provided to support the scheduling of interactions in abstract time between composites and/or entities residing within other applications. Directed and undirected interactions must be supported. To support generic interoperability, interaction parameters must be passed in a packed data structure that is easily translated into other formats such as HLA parameter-handle pair sets, XML, DIS Protocol Data Units (PDUs), etc.

Benefit: The interaction formalism promotes standards-based interoperability with other systems, such as the High Level Architecture (HLA) and web services.

Technical Approach: Run-time classes are used to pack and unpack parameters associated with interactions. The OpenUTF distributes undirected interactions to subscribers, while efficiently delivering interactions to one or more specified recipients for directed interactions.

5

2.11 Publish/Subscribe

Requirement #11: Publish and Subscribe services must be provided to automatically distribute exportable attributes of federation objects between (a) composites, and between (b) components residing within a composite. Interest management, with specially optimized support for range-based filtering, must be provided to efficiently distribute data in a scalable manner to subscribers based on dynamically changing object discovery criteria [27,36,38,39]. Services include object discovery, removal, and the reflection of modified attributes.

Benefit: The publish/subscribe data distribution formalism provides a scalable way for composites to discover information about other composites. It also promotes standards-based interoperability with other systems, such as HLA and TENA, which do not operate under the OpenUTF Kernel. Data distribution is almost always the performance bottleneck for large sequential, parallel, and distributed M&S systems. Providing an optimized capability is challenging, but will greatly benefit all users.

Technical Approach: Publish and subscribe services, combined with scalable interest management, are provided in a distributed and automated manner. Object discovery, removal, and reflection of updated attributes services are provided. Operator overloading in C++ captures updates to published attributes. Unlike the HLA approach, this eliminates the need for model developers to be concerned with coordinating the packaging and dispersal of updated attributes. Multiple updated attributes are automatically bundled by the OpenUTF Kernel into packed messages to optimize data distribution. A multidimensional and multiresolution Hierarchical Grid (HiGrid) data structure efficiently computes overlaps between publisher and subscriber interest expressions.

2.12 Data Translation Services

Requirement #12: Efficient general-purpose data translation capabilities must be provided to allow services, models, and other integrated software systems with disparate data models [21,32,60] to effectively communicate. Data translations specify input object-attribute mappings to output object-attribute targets. Translations must support (a) different object names, (b) different attribute names, (c) unit conversions (d) non-linear mappable translations, (e) attributes spread between multiple objects, (f) the handling of missing data, and (g) multistage translation capabilities. In addition, multiple data formats, such as XML and HLA packed attribute handle pair lists must be supported.

Benefit: Data translation services extend interoperability to larger collections of services, models, and systems.

Technical Approach: Translation services work within a user-defined layered translation-mapping framework where attribute translation dependencies are registered and translations are automatically triggered whenever objects are discovered and/or attributes are modified.

2.13 Execution of Multiple Applications

Requirement #13: Multiple OpenUTF applications must be able to operate as a single execution without necessarily sharing service and/or model component code.

Benefit: It may not always be possible to distribute software service and/or component implementations between organizations. Therefore, applications with different components must still be able to efficiently operate in scalable parallel and distributed computing environments.

Technical Approach: Each application defines its set of composites, components, and events. The OpenUTF assigns integer identifiers for each of these types that would be normally be inconsistent between applications unless a global mapping is provided. Furthermore, the OpenUTF uses a clustering mechanism that keeps track of which nodes have which types of composites. The clustering mechanism makes sure that composites are not created on nodes that do not provide the necessary software components.

2.14 Platform Independence

Requirement #14: The OpenUTF must support multiple platforms, operating systems, compilers, and networks. For operating systems, this includes Windows XP/Vista, Mac OS X, Linux, and other forms of UNIX such as Solaris, HP-UX, IRIX, AIX, etc. Compilers supported must include gcc and Microsoft Visual Studio. Networks include standard TCP/IP and UDP/IP protocols over common physical links such as Ethernet.

Benefit: Platform independence is required to support composability across all computing systems.

Technical Approach: Minimize (a) operating system, (b) compiler, and (c) network protocol system dependencies. When required, abstractions to system or platform-specific services are provided through universal interfaces defined by compiler directives. OpenUTF software is developed and tested on a wide variety of platforms, which helps ensure platform independence.

2.15 Scalability

Requirement #15: The OpenUTF Kernel must scale in terms of number of nodes, computations, time scales, memory consumption, message throughput, message

6

bandwidth, and scenario size. Flow control techniques must be provided to ensure stable operation for all use cases. The overall scalability for specific applications will depend on actual service and model implementations. The framework cannot be expected to scale better than the actual application implementation.

Benefit: Scalability across all dimensions is critical to support large complex scenarios.

Technical Approach: The OpenUTF Kernel addresses scalability in its OpenMSA layered architecture, which includes advanced time management techniques that provide flow control to ensure stability. All internal data structures and parallel-computing algorithms are distributed with no central bottlenecks and are designed to scale on the largest supercomputers.

2.16 Support LVC Interoperability Standards

Requirement #16: The OpenUTF Kernel must support integration with Live, Virtual, and Constructive (LVC) interoperability standards [3]. This specifically means that the OpenUTF will provide integration with (a) the High Level Architecture (HLA) [16,17,18,24,61], (2) Distributed Interactive Simulation (DIS) [9,10], and (3) Test/Training Enabling Architecture (TENA) [51].

Benefit: LVC interoperability standards are widely used in legacy systems. Supporting LVC interoperability standards will provide potential integration with existing systems.

Technical Approach: The OpenUTF has carefully defined publish/subscribe and interaction services that were carefully designed to work with all LVC interoperability standards.

2.17 Web Services

Requirement #17: The OpenUTF Kernel must support integration with XML-based [55] web services [12,59]. This includes XML Schemas [56], Web Service Definition Language (WSDL) [58], Simple Object Access Protocol (SOAP) [57], and Universal Description Discovery and Integration (UDDI) [7].

Benefit: Web services are heavily used by the Internet community and are well suited to support many net-centric DoD applications. Numerous existing tools support web services.

Technical Approach: The OpenUTF reference implementation is currently integrated with an open source tool, known as gSOAP, to support web services. Other web service tools and frameworks such as C# and the Microsoft .net programming environment can be

supported as well. The Run Time Class (RTC) parser in the OpenUTF Kernel is able to parse XML documents.

2.18 Cognitive Behavior Representation

Requirement #18: The OpenUTF Kernel must provide an Open Cognitive Architecture Framework (OpenCAF) that is capable of representing complex intelligent behavior with intuitive modeling constructs.

Benefit: Hard-coded complex behaviors are difficult to implement and maintain. The OpenCAF will provide a much more expressive way to represent and maintain intelligent behavior.

Technical Approach: The OpenCAF is designed to represent (a) thoughts, stimulus, and cognitive thinking processes, (b) dynamically changing goal-oriented behaviors, (c) the exploration of multiple behavior branches, and (d) decision optimization [4].

2.19 Stochastic Modeling Constructs

Requirement #19: The OpenUTF Kernel must provide a generic way to explore probability-based random outcomes in a manner that is independent of whether Monte Carlo techniques (i.e., multiple replications) are used, or five-dimensional simulation techniques (single run does the equivalent of multiple replications) are used.

Benefit: Both Monte Carlo [2] and five-dimensional [45] simulation techniques are required to support statistical analysis of complex problems. Abstracting branch exploration is necessary to unify model representations for both modes of operation.

Technical Approach: The OpenUTF supports both standard Monte Carlo excursions and five dimensional execution modes where Bayesian branching capabilities are provided. Multiple independent simulation excursions can be managed by the built-in grid-computing framework that is able to farm replications to available computing resources across distributed computing environments.

2.20 Geospatial Representations

Requirement #20: The OpenUTF Kernel must provide support for both (a) round and (b) ellipsoidal geospatial coordinate systems. In addition, basic entity motion algorithms and range-finding/intercept utilities must be provided in both rotating and inertial coordinate system reference frames. Motion algorithms must provide analytically correct position, velocity, and acceleration vectors at any point in abstract time.

7

Benefit: Moving battlefield entities must be represented in standard geospatial coordinate systems that are well-understood by services, models, and legacy systems.

Technical Approach: The OpenUTF provides numerous well-tested motion algorithms, entity orientation services, and generalized coordinate system transformation utilities to meet this requirement.

2.21 Software Utilities

Requirement #21: The OpenUTF Kernel must provide a suite of software utilities that automatically support rollbacks and simplify model development.

Benefit: Reusable software utilities significantly lower the cost and simplify software development.

Technical Approach: About 1/3 of the kernel library code provided by the open source reference implementation are software utilities. Examples include random number generation, container classes, vector and matrix algebra, statistical analysis, curve-fitting routines, data parsers, rollbackable operations, persistence, etc.

2.22 External Modeling Framework

Requirement #22: The OpenUTF Kernel must provide an External Modeling Framework (EMF) interface to real-world systems wishing to directly connect to primary OpenUTF applications. The EMF must coordinate the progression of abstract time with the primary OpenUTF application.

Benefit: The EMF provides a more direct and efficient interface to primary OpenUTF applications than other LVC and web-service interfaces. It also provides rollback support for offline analysis and data visualization.

Technical Approach: The EMF integrates publish/subscribe rollback capabilities and several time-synchronization protocols within a common interface that interacts with the primary OpenUTF application. Time barriers are created and removed by the EMF to synchronize time advancement with primary OpenUTF simulations.

2.23 Output Data Formats

Requirement #23: The OpenUTF must provide a standard and traceable way to output generated event data to files, visualization tools, distributed blackboards, and/or databases. Data produced by OpenUTF applications must be accessible across heterogeneous distributed computing environments. Visualization tools must be provided to assist users analyze results of OpenUTF executions.

Benefit: Standardizing output data formats will promote better interoperability with mainstream commercial and open source analysis tools such as Matlab, Scientific Tools for Python (SciPy), and/or trace file readers.

Technical Approach: The OpenUTF provides a distributed blackboard capability where output data generated by OpenUTF applications can be maintained in a named workspace. Multiple remote users distributed across a network can visualize and analyze the data in a collaborative environment. The workspace can be connected to Matlab or SciPy to support advanced mathematical analysis operations. The OpenUTF also provides a trace file capability that records event-processing information (e.g., time of each event, which composite simulation object processed the event, which events scheduled which other events, etc.) and application-specific logged data. A graphical analysis tool is able to read the trace file and display logged data over time. Full analysis capabilities for logged data will eventually be provided.

2.24 Test Framework

Requirement #24: The OpenUTF must provide an automated test framework that is capable of running standard tests and analyzing their output for correctness. User-written services and models must be provided with one or more tests that help verify and potentially validate implementations [11].

Benefit: An automatic regression test framework will catch errors and help maintain the quality of the software. Validation tests that compare output with well-known empirical and/or theoretical results will also help streamline VV&A efforts [30].

Technical Approach: A Python-based regression test framework provided by the OpenUTF Kernel currently searches and finds test scripts that specify how to (a) run tests, and (b) analyze their generated output. Tests are organized in different categories (e.g., developer unit tests, system tests, benchmarks, backward compatibility, tutorials and training examples, etc.) to verify correct operation, and whenever possible, to validate correct results.

2.25 Community-wide Participation

Requirement #25: The OpenUTF must support and encourage community-wide participation in development and use of capabilities.

Benefit: Organizations are able to contribute their unique expertise, which benefits all users. The combined capabilities provided by a community-wide supported OpenUTF would reduce the cost of software development

8

while significantly promoting advanced next-generation capability to users. Participation includes commercial industry, academia, research laboratories, and government programs.

Technical Approach: Open source strategies help encourage community-wide participation. The OpenUTF encourages participation from (a) service and model developers who are subject matter experts, (b) LVC interoperability run-time infrastructure developers who are distributed computing technologists, (c) web-service developers who are Service Oriented Architecture (SOA) experts, and (d) various composability, visualization, and analysis tool developers.

3.0 Summary and Conclusions

The paper provided an overview of twenty-five key requirements of the Open Unified Technical Framework (OpenUTF) that is currently being developed for use by the Chemical, Biological, Radiological, and Nuclear Defense (CBRND) program, as well as other programs. Many of these requirements are either fully or partially fulfilled in the existing WarpIV Kernel reference implementation [41] of the OpenUTF Kernel. Figure 2 shows percent completed of each requirement.

Figure 2: Percent complete of each requirement in the WarpIV Kernel reference implementation of the OpenUTF Kernel.

4.0 Acknowledgements

The authors of this paper would like to thank Dave Ferris, Chief Systems Engineer, Joint Program Executive Office for Chemical and Biological Defense (JPEO-CBD), who directs the Software Support Activity (SSA) Modeling, Simulation, and Integration (MSI) Team. The authors of this paper would also like to thank both Doug Hardy, Software Support Activity program manager, and John

Wrigley, Technical Lead of the MSI Team for their encouraging support of the OpenUTF concepts.

The authors of this paper would like to thank Karen Roth, Dr. Timothy Busch, Dawn Trevisani, and Mike Gacek for their continuing support and technical insight in real-time Air Force command and control operational systems requiring Dynamic Situation Assessment and Prediction (DSAP).

The authors of this paper would finally like to thank Bob Pritchard, Program Manager of the Joint Virtual Network Centric Warfare (JVNCW) program and High Performance Computing Director at SPAWAR Systems Center Pacific, for supporting the development of many of the LVC and web-based interoperability capabilities for the OpenUTF referenced in this paper. Bob Pritchard has also been a strong supporter of the PDMS Standing Study Group, and is a proponent of open source software methodologies.

5.0 Author Biographies

JEFFREY S. STEINMAN, President and CEO of WarpIV Technologies, Inc. received his Ph.D. in High Energy Physics from UCLA in 1988 where he studied the quark structure function of high-energy virtual photons at the Stanford Linear Accelerator Center. Upon completing his Ph.D. dissertation, Dr. Steinman worked at the Jet Propulsion Laboratory/CalTech in the area of parallel and distributed computing technologies on hypercube supercomputers.

Dr. Steinman developed the Synchronous Parallel Environment for Emulation and Discrete Event Simulation (SPEEDES) framework in 1990 as the next-generation replacement for the Time Warp Operating System (TWOS). This work transitioned to industry in 1996, when Dr. Steinman joined the staff at Metron, Inc., where he formed a new High Performance Computing Division. SPEEDES eventually transitioned into several mainstream programs including BMDS SIM, JMASS, JSIMS, EADTB, and many other smaller programs and/or R&D efforts. In 2000, Dr. Steinman left Metron to join RAM Laboratories as Chief Scientist where he directed all of their high-performance computing R&D programs.

Dr. Steinman formed WarpIV Technologies, Inc. in 2005 to focus on the development of new technologies such as five dimensional simulation, composable plug-and-play modeling architectures, and open system standards for high performance computing. He is helping establish next-generation command and control architectures for the Air Force Research Laboratory at Rome, New York. He also provides technical guidance for the Joint Virtual Network Centric Warfare (JVNCW) program that is

9

sponsored by the Test and Evaluation (T&E), Science and Technology (S&T), Network-centric Systems Test (NST) program. JVNCW models military communications on supercomputers.

Dr. Steinman currently provides technology and open systems architecture support for the Joint Program Executive Office, Chemical and Biological Defense (JPEO-CBD), Software Support Activity (SSA), where he is helping to establish and implement its long-range M&S strategic plan. This paper was sponsored by JPEO-CBD, SSA, through the Space and Naval Warfare Systems Center, Pacific (SSC-Pacific) in San Diego, CA.

Dr. Steinman has published more than 60 papers and articles in the field of high performance simulation, has five U.S. patents in high performance M&S technology, is a frequent invited speaker at conferences, seminars, and forums, and is the principle designer/developer of the open source WarpIV Kernel Reference Implementation of the OpenMSA, OSAMS, and OpenCAF architectures. Dr. Steinman is currently heading the newly formed Parallel and Distributed Modeling and Simulation Standing Study Group (PDMS-SSG) that operates within the Simulation Interoperability Standards Organization (SISO).

CRAIG N. LAMMERS, Vice President and Senior Analyst at WarpIV Technologies, Inc., currently provides technical support for the JPEO-CBD, SSA, and is the program manager of an effort with AFRL, Rome Labs conducting new research and development in parallel and distributed simulation to support formal estimation and prediction of complex systems using the WarpIV Kernel. His professional interests are in the areas of modeling and simulation, artificial intelligence, user interface design, and music. Mr. Lammers received his Bachelor of Science degree in Industrial and Systems Engineering from the University of Michigan, Dearborn in 2001, where he graduated with high honors.

MARIA E. VALINSKI, Vice President and Senior Software Engineer at WarpIV Technologies, Inc., currently provides modeling, simulation, and integration support for the JPEO-CBD, SSA, and is the lead software engineer for the Joint Virtual Network Centric Warfare (JVNCW) program that involves modeling wireless communications on supercomputers using the WarpIV Kernel for the Navy, Army, and Air Force. Ms. Valinski received her Bachelor of Science degree in Computer Science from East Stroudsburg University in 1997.

6.0 References

1. Alberts, David S., 2002. “Information Age Transformation, Getting to a 21st Century Military.” ISBN 1-893723-06-2 (pbk.)

2. Anderson Mark, and Whitcomb Patrick, 2000. “DOE Simplified, Practical Tools for Effective Experimentation.”

3. Bizub Warren, Cutts Dannie, 2007 “Live Virtual Constructive (LVC) Architecture Interoperability Assessment.” In proceedings of the 2007 Interservice/Industry Training, Simulation & Education Conference (I/ITSEC).

4. Busch T., "Modeling of Air Operations for Course of Action Determination" in Enabling Technologies for Simulation Science VI, Alex Sisti and Dawn Trevisani Editors, Proceedings of SPIE Vol. 4716, pp 35-40, (2002).

5. Buttazzo, Giorgio C., 2005. “Hard Real-Time Computing Systems.” Predictable Scheduling Algorithms and Applications Series, Vol. 23.

6. Chandy, K., and Misra, J. 1979. “Distributed Simulation: A Case Study in Design and Verification of Distributed Programs.” IEEE Transactions on Software Engineering. Vol. SE 5, No. 5, pages 440–452.

7. Curbera, Francisco, Ehnebuske, David, and Rogers, Dan, 2002. “Using WSDL in a UDDI Registry Version 1.07, UDDI Best Practice” May 21, 2002. http://www.uddi.org/pubs/wsdlbestpractices.pdf.

8. Davis P., and Anderson R., 2004. “Improving the Composability of Department of Defense Models and Simulations.” Prepared for the Defense Modeling and Simulation Office (DMSO). RAND National Defense Research Institute.

9. Distributed Interactive Simulation - Application protocols, IEEE 1278.1A-1998.

10. Distributed Interactive Simulation - Communication Services and Profiles, IEEE 1278.2-1995.

11. DoD Modeling and Simulation Office (DMSO), Department of Defense Verification, Validation and Accreditation Recommended Practices Guide, November 1996.

12. Extensible Modeling and Simulation Framework (XMSF) Challenges for Web-Based Modeling and Simulation. Findings and Recommendations Report: Technical Challenges Workshop, Strategic Opportunities Symposium, October 22, 2002.

13. Fujimoto, R. 1988. “Lookahead in Parallel Discrete Event Simulation.” International Conference on Parallel Processing. Vol. 3, pages 34–41.

14. Fujimoto, R. 1997. “Zero Lookahead and Repeatability in the High Level Architecture.” In Proceedings of the 1997 Spring Simulation Interoperability Workshop (SIW).

15. Fujimoto R., 2000. “Parallel and Distributed Simulation Systems.” John Wiley & Sons, Inc., 605 Third Avenue, New York, NY 10158-0012.

16. HLA Framework and Rules, Version IEEE 1516-2000. 17. HLA Interface Specification, Version IEEE 1516.1-2000. 18. HLA Object Model Template, Version IEEE 1516.2-2000. 19. High Performance Computing Modernization Program

(HPCMP), http://www.hpcmo.hpc.mil/community/SAS/Portfolio/cta_description.php#FMS

10

20. Jefferson D., 1985. “Virtual Time.” ACM Transactions on Programming Languages and Systems, Vol. 7, No. 3, pages 404-425.

21. Joint Consultation Command and Control Information Exchange Data Model. http://www.mip-site.org/publicsite/04-Baseline_3.0/JC3IEDM-Joint_C3_Information_Exchange_Data_Model.

22. Joint Program Executive Office (JPEO) Chemical and Biological Defense (CBD) Modeling and Simulation Strategic Plan.

23. Joint Program Executive Office (JPEO) Chemical and Biological Defense (CBD) Modeling and Simulation Integrated Product Team Charter.

24. Kuhl Frederick, Weatherly Richard, and Dahmann Judith, 2000. “Creating Computer Simulation Systems, An Introduction to the High Level Architecture.” Prentice Hall PTR, Upper Saddle River, NJ 07458.

25. Lammers C., Valinski M., Steinman J., 2009. “Multiplatform Support for the OpenMSA/OSAMS Reference Implementation.” In proceedings of the Spring 2009 Simulation Interoperability Workshop (SIW).

26. Manycore Computing Workshop, 2007. Sponsored by Microsoft. Participation was by invitation only. http://science.officeisp.net/ManycoreComputingWorkshop07/Program.aspx

27. Morse K., Steinman J., 1997. “Data Distribution Management in the HLA: Multidimensional Regions and Physically Correct Filtering.” In proceedings of the Spring Simulation Interoperability Workshop. Paper 97S-SIW-052.

28. Mutschler David, 2005. “Parallelization of the Joint Integrated Mission Model (JIMM) Using Cautious Optimistic Control (COC).” In proceedings of the Summer Computer Simulation Conference (SCSC), 2005.

29. Network Centric Warfare, Department of Defense Report to Congress, July 27, 2001. http://www.dod.mil/nii/NCW/.

30. Pace, D. K., “Verification, Validation, and Accreditation (VV&A),” In Applied Modeling and Simulation: An Integrated Approach to Development and Operations, D. J. Cloud and L. B. Rainey, editors. Pp. 369-410, McGraw-Hill, New York (1998).

31. Parallel and Distributed Modeling and Simulation Standing Study Group (PDMS-SSG) Terms Of Reference (TOR).

32. Reilly Sean and Briggs Keith (Editors), 1999. “Guidance, Rationale, and Interoperability Modalities for the Real-Time Reference Federation Object Model (RPR-FOM) Version 1.0.” Simulation Interoperability Standards Organization.

33. Simulation Interoperability Standards Organization (SISO), http://www.sisostds.org.

34. Steinman Jeff, 1993. "Breathing Time Warp." In proceedings of the 7th Workshop on Parallel and Distributed Simulation (PADS93). Vol. 23, No. 1, Pages 109-118.

35. Steinman Jeff, 1993. "Synchronization of Parallel and Distributed Interactive Military Simulations Using SPEEDES." In proceedings of the 1993 Summer Computer Simulation Conference. Pages 701-710.

36. Steinman Jeff and Wieland Fred, 1994. "Parallel Proximity Detection and the Distribution List Algorithm." In proceedings of the 1994 Parallel And Distributed Simulation Conference. Pages 3-11.

37. Steinman Jeff, 1996, “Scalable Synchronization of Distributed Military Simulations.” In proceedings of the 1996 Object Oriented Simulation Conference. Pages 247-252.

38. Steinman Jeff, Tran Tuan, Burckhardt Jacob, Brutocao Jim, 1999. “Logically Correct Data Distribution Management in SPEEDES”, In proceedings of the 1999 Fall Simulation Interoperability Workshop, Paper 99F-SIW-067.

39. Steinman Jeff, 2004. “The Distributed Simulation Management Services Layer in SPEEDES.” In proceedings of the Spring 2004 Simulation Interoperability Workshop, paper 04S-SIW-98.

40. Steinman J. and Hardy D., 2004. “Evolution of the Standard Simulation Architecture.” In proceedings of the Command and Control Research Technology Symposium, paper 067.

41. Steinman J, 2005. “The WarpIV Simulation Kernel.” In proceedings of the 2005 Principles of Advanced and Distributed Simulation (PADS) workshop.

42. Steinman Jeffrey, 2007. “Modeling & Simulation in a Service Oriented Architecture (SOA) World.” In Chemical ad Biological Defense Quarterly, Volume 4, Issue 2.

43. Steinman J., et. al., 2007. “A Proposed Open System Architecture for Modeling and Simulation.” In proceedings of the Fall 2007 Simulation Interoperability Workshop, 07F-SIW-044.

44. Steinman Jeff, 2007, “WarpIV Kernel: High Speed Communications.” In proceedings of the Fall 2007 Simulation Interoperability Workshop, 07F-SIW-045.

45. Steinman J., et. al., 2008, “Simulating Parallel Overlapping Universes in the Fifth Dimension with HyperWarpSpeed Implemented in the WarpIV Kernel.” In proceedings of the Spring 2008 Simulation Interoperability Workshop, 08S-SIW-025.

46. Steinman J., 2008. “The Need for Change in Modeling and Simulation.” Article to be published in Chem-Bio Defense Quarterly.

47. Steinman J., Lammers C., Valinski M., 2008. “A Unified Technical Framework for Net-centric Systems of Systems, Test and Evaluation, Training, Modeling and Simulation, and Beyond…” In proceedings of the Fall 2008 Simulation Interoperability Workshop (SIW). Paper 08F-SIW-041.

48. Steinman Jeff, 2008. “Open Source Licensing and the WarpIV Kernel.” In the proceedings of the Fall 2008 Simulation Interoperability Workshop, 08F-SIW-065.

49. Steinman Jeff, 2009. “Introduction to Parallel and Distributed Force Modeling and Simulation.” In proceedings of the Spring 2009 Simulation Interoperability Workshop. Paper 09S-SIW-021.

50. Steinman Jeff, Lammers Craig, and Valinski Maria, 2009. “A Proposed Open Cognitive Architecture Framework (OpenCAF).” To be published in the proceedings of the 2009 Winter Simulation Conference.

11

51. TENA, The Test and Training Enabling Architecture, Architecture Reference Document. Foundation Initiative 2010 Project Office.

52. WarpIV Kernel Public Source License, Version 4.0, October 29, 2008.

53. WarpIV Technologies, Inc., Copyright © 2007, “High Speed Communications Package, Programming Guide: Version 1.5.”

54. Web Services Description Language (WSDL) 1.1. W3C Note 15 March 2001. http://www.w3.org/TR/wsdl.

55. World Wide Web Consortium, Extensible Markup Language (XML) 1.0 (Fourth Edition), W3C Recommendation 16 August 2006. http://www.w3.org/TR/2006/REC-xml-20060816/.

56. World Wide Web Consortium, XML Schema: Formal Description, W3C Working Draft, 25 September 2001.

http://www.w3.org/TR/2001/WD-xmlschema-formal-20010925/.

57. World Wide Web Consortium, SOAP Version 1.2 Part 0: Primer, http://www.w3.org/TR/2003/REC-soap12-part0-20030624/.

58. World Wide Web Consortium, Web Services Addressing 1.0 – WSDL Binding, http://www.w3.org/TR/2006/CR-ws-addr-wsdl-20060529/.

59. World Wide Web Consortium, Simulation Reference Markup Language, http://www.w3.org/TR/2002/NOTE-SRML-20021218/.

60. XSL Transformations (XSLT), Version 1.0. http://www.w3.org/TR/xslt.

61. Yu Lois, Steinman Jeff, Blank Gary, 1999. “Adapting Your Simulation for HLA.” SIMULATION, Vol. 71, No. 6, December 1998. Pages 410-420.