OneSAF Objective System: A Simulation Toolbox



OneSAF Objective System: A Simulation Toolbox

Keywords: OneSAF, Computer Generated Forces (CGF), Semi Automated Forces (SAF), Simulation Toolbox

ABSTRACT: The OneSAF Objective System is not your grandfather’s computer-based simulation. It is the Army’s next generation simulation toolkit that will provide a composable entity-level simulation to serve the Army’s three modeling and simulation domains spanning training, experimentation, and acquisition. It provides a suite of tools automating what have been largely computer science intensive activities in legacy computer-based simulations in the areas of software development, simulation pre-event, event execution, and post-event activities. When fielded in FY06 the OneSAF Objective System will offer a significant improvement over existing simulation systems by allowing users to compose a wide range of complete simulation systems from a set of component-based tools, develop new or extend existing tools, as well as compose new single or multi-resolution entities, units, and associated behaviors from existing physical and behavioral software components. This article describes the engineering strategy behind the OneSAF Objective System toolbox and highlights the software engineering and composition toolset.

Introduction

Typically simulations have been written to satisfy specific needs. Design decisions are focused around the best way to satisfy those needs, with little if any consideration of how users might modify the simulation after fielding to suit emerging and dynamic requirements. OneSAF Testbed Baseline (OTB) was a breakthrough in this area, since it was delivered with the source code. A user needed to be an accomplished C programmer, be a subject matter expert in military doctrine and tactics, and be specially trained; however, the user did not have to pay the developer to make enhancements.

OneSAF Objective System (OOS) will be a further leap ahead. In many cases, the user can modify entities, units, behaviors, and even the overall composition of OOS without being a programmer and without recompiling any of the software. The user’s ability to tailor OOS to meet the specific needs of a simulation experiment or exercise is referred to as composability. Different configurations of OOS are referred to as compositions.

This paper will describe how OOS has been architected and constructed to allow the user maximum flexibility. First we discuss the requirements that drove the composability approach. Next we describe the engineering strategy behind the OOS toolbox and then highlight the software engineering and composition toolset.

User Requirements Driving a Simulation Toolbox Approach

OneSAF Objective System (OOS) must meet the needs of three distinct M&S domains: ACR, TEMO, and RDA [1]. The ACR domain, Advanced Concepts and Requirements, focuses on detailed analytical experiments to explore options for future capabilities. For ACR validated and verified models, traceablity of model implementation, and the ability to extract data from the simulation for analysis are very important. In addition, repeatability and the ability to run “parameter sweeps” are also vital.

The TEMO domain, Training Exercises and Military Operations, focuses on staff training exercises. For TEMO, large entity counts, intuitive interfaces, simulation execution in synch with wall clock time, and easy scenario generation are important. The RDA domain, Research Development and Acquisition, conducts experiments like those of ACR, but usually with a shorter time horizon; ACR studies tend to look further into the future than do those of RDA. A platitude often used to describe the differences between the three domains is that for TEMO the behavior of the simulation has to look right; for ACR and RDA it has to be right.

The different foci of the three domains lead to very different fidelity requirements. Fidelity refers to the faithfulness of the model to the real-world object being modeled. Often fidelity is equated to model detail and computational requirements, as they are typically, but not necessarily, related. For most entities, units, behaviors, and even terrain, OOS supports three levels of fidelity: low, medium, and high.

An example of different levels of fidelity is dismounted infantry (DI) entities. Low-fidelity DI’s sense and shoot, but they only move along routes designated by the simulation operator, will not avoid obstacles, and will not react as a unit. Low-fidelity entities are comparable to entities in Janus or Joint Conflict and Tactical Simulation (JCATS). Medium fidelity OOS entities are more like those in OTB. They sense and shoot, but orders can be given to units, such as platoons and companies. Those units, though represented and simulated as individual entities, will move in formation and react to contact in doctrinally correct manners. If given a route to move along that is blocked, medium fidelity entities will look for bypasses. Often medium-fidelity entities have more and better sensors and weapons than their low-fidelity counterparts. High-fidelity entities have all the capabilities and attributes of medium-fidelity entities; however, they are enhanced in some way. They might have a high-fidelity missile fly-out model, rather than Army Materiel Systems Analysis Activity (AMSAA) provided Ph/Pk values. They might have sensor models that have greater detail, or they might have a higher-fidelity mobility model.

Low-fidelity, high-entity-count simulations support staff training, course of action (COA) development, and COA analysis (TEMO). Medium-fidelity simulations support staff training, detailed COA analysis, mission rehearsal, and mission execution monitoring (TEMO). They can also support concept definition and tradeoff analyses (ACR and RDA). High-fidelity, low-entity-count simulations support detailed analyses appropriate for research, system tradeoff analyses, etc. (ACR and RDA).

It is useful to mix fidelity within a simulation experiment or exercise, and the OOS composability facilitates the use of mixed fidelity. As an example, a user might want to have low-fidelity entities in the “wrap around” area on the flanks of the operations, medium-fidelity entities in the area of interest, and perhaps high-fidelity in the focus area for the experiment (e.g., SOF entities clearing a building or hijacked airplane). The developers of OOS ensure that the interactions between low-, medium-, and high-fidelity entities are consistent.

This composable, toolbox approach allows users to tailor the simulation to meet their requirements. High-fidelity entities consume more CPU cycles, so the user can select high-fidelity entities where they are needed, but use low- or medium-fidelity entities elsewhere to not bog down the entire simulation. This toolbox approach pervades OOS development and characterizes terrain databases (i.e., OOS terrain databases can be low-fidelity with high-fidelity inserts where needed), physical models (e.g., rotary winged aircraft flight dynamics), environmental effects, sea-state modeling, entities, units, and behaviors. The toolbox approach makes OOS uniquely suitable for use by the ACR, TEMO, and RDA domains.

OOS Key Engineering Strategies

The initial OneSAF task orders were awarded in mid 2000. Now, as OneSAF nears the end of its third major development iteration a few key enterprise, system, and software engineering concepts standout as enablers to the progress made to date. The following sections touch on these key enablers for the generation and integration of over one million lines of working code that continues to grow and evolve as part of the OneSAF’s iterative and incremental development process.

Enterprise Engineering

An Enterprise is defined as [2] “an organization (or cross-organizational entity) supporting a defined business scope and mission. An enterprise includes interdependent resources (people, organizations, and technology) who must coordinate their functions and share information in support of a common mission (or set of related missions).” For OneSAF this equates to a mission of creating a simulation toolkit that supports the Army’s ACR, RDA, and TEMO domains. The organization is led by Program Executive Office-Simulation Training and Instrumentation (PEO-STRI) who is responsible for developing the simulation toolkit. Active members of the organization include the Training and Doctrine Command (TRADOC), each of the Army M&S domains, and the contractor work force that will implement the system.

Apart from other programs at PEO-STRI, the OneSAF Program Management Office is acting as the lead integrator across the OneSAF enterprise. A key and novel aspect of the OneSAF enterprise engineering effort is the organizational collocation and close coordination between enterprise stakeholders: TRADOC, domain representatives, government developers, and contractors. To facilitate this development environment PM OneSAF created the OneSAF Integration and Development Environment (IDE) and accessed specific modeling and simulation expertise through the Simulation Training and Instrumentation Command PEO-STRI Omnibus Contract. There are currently nine active task orders covering the OneSAF architecture and integration (A&I) effort, modeling and environmental representation development, knowledge acquisition, and other tool-based development tasks supporting the pre-event, event, and post-event simulation phases [3].

The task order acquisition strategy offers additional flexibility over other strategies in that task orders can be added, deleted, or modified in response to evolving understanding of the requirements, contractor performance, and budgetary constraints.

Product Line System and Agile-based Software Engineering

In 1995 the Software Engineering Institute (SEI) began exploring software-oriented product line development to understand the relationship between architectural patterns, software reuse, and rapid software production [4]. The research resulted in a number of SEI sponsored product line development workshops and a variety of published papers and books on the practice of software intensive system product line development [5].

The research concentrated on finding the essence of rapidly and cost effectively creating new software products by looking within the software development industry and to other industry’s (manufacturing, food service, etc.) for lessons learned and insights [4, 5]. The resulting product line development concepts for software intensive systems rely heavily on developing a robust set of core assets that can be used in a variety of settings and to support multiple customers [5].

The OneSAF Product Line development approach drives at rapidly producing a set of system compositions using common architectural, process, documentation, and code-level assets that address the wide range of OneSAF requirements. To do this the entire OneSAF enterprise is involved and as a normal part of development continually review development decisions to ensure they leverage core assets and are free of a “not invented here” mentality.

To effectively identify and develop the core asset base the Government and A&I team agreed to integrate agile-based development concepts with a traditional, top-down, requirements-based engineering approach. The compromise was necessary to mix the right amount of top-down requirements-based traceability and accountability with the right amount of agility and the ability to show progress with executing code [6, 7, 8]. Finding this correct mix is still an issue of great debate in the software development industry. [9]

These key concepts paved the way for crafting the OneSAF software engineering environment and the ensuing composition tools as described in the following sections.

OOS Software Engineering Tools

The software engineering tools are used to build and extend OOS. For the OneSAF program, this toolkit evolved into an Integrated Development Environment (IDE), supporting all facets of the software development life cycle. This IDE is central in the development, management, and communication of the OneSAF system.

In selecting the development toolkit, the OneSAF team made a conscience decision to keep development and maintenance tool costs low by relying on Open Source tools wherever possible. In fact, there are no commercial tools required to build or modify the majority of the OneSAF baseline.

The Open Source version control tool, the Concurrent Versioning System [10] (CVS) is the backbone of the OneSAF IDE. It is used throughout all parts of the IDE for various phases of software development. The OneSAF team uses CVS to house development artifacts in Software Development Folders (SDF), software code, data, knowledge-based artifacts, and all contract data requirements lists. In addition, the content of the OneSAF development website is housed and managed through CVS. OneSAF developers interact with CVS to push content changes to the version controlled form of the website. Periodically, custom-built services automatically update the live website based on the contents of the CVS module.

The OneSAF development website acts as the communications center for the IDE. It specifically supports geographically distributed development, and relies on Secure Socket Layer (SSL) technology to encrypt communications from the server to an accessing client. This environment provides the same and complete access to information and tool support for both local and distributed developers. The site itself uses all Open Source tools to accomplish its mission, including Apache [11] for the Webserver, Tomcat [12] as the Java Servlet Server, and OpenSSL [13] for communication encryption. The website provides access to programmatic schedules; development, management, and test plans; process, requirements, architecture, design, and training documents, and the SDFs. Additionally, the website allows access to WebRT [14] enabled peer review, defect, risk, and action item tracking tools.

The processes guiding OneSAF are described in the Electronic Process Guide (EPG). The EPG provides a hyperlinked flowchart-like diagram of the OneSAF development processes, including program and risk management, systems and software engineering, and integration and test. The EPG provides developers with direct access to processes at their desks without having to dust off thick binders.

The OneSAF team uses a formal commercial requirements tracking tool to maintain system and software requirements. These requirements are exported to HTML for incorporation on the website. Software development teams then create Object-Oriented Analysis & Design (OOA&D) products in a commercial, round-trip Unified Modeling Language (UML) modeling tool, and then publish views to the development website.

The majority of OneSAF code is rendered in Java, [15] and developers are free to select a coding environment of their choosing. Most developers utilize the Open Source tool jEdit [16], a Java-based text editor with extensive plug-in support. Code building for OneSAF uses the Open Source Apache Ant [17] tool. Ant provides services similar to 'make', and inherently supports cross platform compilation, a key requirement for OneSAF. All of Ant's build files are specified in XML, allowing OneSAF developers to work with already familiar syntax, since XML is used in specifying OneSAF data.

The OneSAF development approach stresses automated regression testing, based on the Agile Development/Extreme Programming [18] concepts. OneSAF developers create automated unit and component tests based off of the Open Source JUnit [19] framework. This framework provides a consistent testing methodology allowing tools such as Ant to automate the regression tests. The OneSAF program has literally thousands of automated JUnit style tests that execute several times every day. These tests are critical for developers to understand the impact of changes on the system.

Since OneSAF is largely a Java-based development effort, OneSAF developers document code and Application Programming Interfaces (APIs) using Javadoc [20]. Javadoc documentation is rendered as specially tagged comments within source code. Javadoc commentary can then be extracted from source code and transformed into web-viewable documentation of APIs. Additionally, since javadoc comments follow a certain structure, OneSAF uses tools such as Doc Check [21] to detect if API documentation is missing or incomplete.

Perhaps the most important automated Software engineering tool for OneSAF is BuildBoy. BuildBoy is a custom-created tool to automate build and regression testing. The tool listens for changes to a version controlled baseline, and upon detection checks out the baseline, executes a clean software build and associated Junit regression tests, reports the results on the OneSAF development website, and emails the instigator of any compilation or test failures. BuildBoy gives developers and managers an accurate and current picture of the baseline’s status. During development, BuildBoy will complete over half a dozen OneSAF software builds and regression test cycles each day.

Finally, the software engineering toolbox would not be complete without a debugging tool. OneSAF directly supports source-level debugging by embedding the Open Source JSwat [22] debugger within the OneSAF toolkit. OneSAF can be launched inside of the JSwat environment allowing OneSAF developers to inspect the internal execution state of the system while it is running.

OOS Composition Tools

While OOS provides tools across the pre-event, event execution, and post-event phases of a simulation event the System and Battlespace Composers set OneSAF apart from previous simulations. These tools empower end-users to compose new products with a GUI that previously required highly skilled software developers. All of the composition tools are being used to construct the base set of compositions to be delivered with OneSAF. Not only does this allow end users to use and modify the compositions, but also ensures that the tools are sufficiently robust prior to delivery.

System Composer

The OneSAF System Composer is a graphical tool allowing users to construct OneSAF System Compositions from existing software components. Traditionally, this task required software developers to create specialized “glue” code to link the components together. The System Composer instead allows a user to drag together a collection of components, graphically specify relationships between them, potentially set properties of those components, and save the result into an executable that can be launched in the future. Once created these compositions can be executed using a lightweight application launching tool called the Runtime Loader.

OneSAF's system composition approach extends the JavaBeans [23] component architecture with meta-data. JavaBeans specifies an interface pattern for components to ensure that components and composition building tools, such as OneSAF's System Composer, can discover characteristics of the components without a priori knowledge. Essentially each time the System Composer is executed, it traverses the set of available components and compositions and discovers their properties, interfaces, and dependencies. This information is used to assist the user of the system composer to make valid and complete choices when constructing an executable. OneSAF’s meta-data extension includes direct dependencies on other components and any specific component restrictions such as dependencies on specific Operating Systems. The System Composer uses component meta-data as guidance, for example, to include all of a component's dependencies automatically in a composition if that component is included.

OneSAF software components range in complexity and size from an individual algorithm with 50 lines of Java code, up to a representation of the environment with over 300,000 lines of C++ code. Non-Java code can be plugged into this architecture, or “componentized”, by creating a Java interface around that code to correspond with the component interface pattern. There is no minimum set of components for a OneSAF System Composition.

Battlespace Composers

The battlespace composers support a form of composition specialized for the military simulation domain. The battlespace composers know about the types of model components that make up an entity, unit, or behavior as well as how model components represent data, so they can offer services to users to distinguish different types of equipment such as an M1A2 from a T80 tank. All of the battlespace composers represent their compositions in XML. There are three battlespace composers: Entity Composer, Unit Composer, and the Behavior Composer.

The Entity Composer allows a user to construct battlespace entities: tanks, aircraft, individual combatants, etc. from models such as turrets, hulls, sensors, and weapons. A user interacts with the Entity Composer by selecting specific models to represent that entity. Users select models and model resolutions to meet there specific simulation needs. For example, a high resolution human mobility model could be used in an Entity Composition to support an urban operations scenario with few entities, alternatively a low resolution human mobility model might be used in modeling a crowd, where large entity counts are needed to provide context for the issues under study. Users can attach as many sensors and weapons to an entity as desired. Once composed, entities can be created in a scenario, or added to a Unit Composition.

The Unit Composer allows the user to create hierarchical collections of entities. Through the Unit Composer, the user populates an organization chart with entity compositions. The user can specify command and support relationships, formation location, as well as communications roles on the various radio networks. The Unit Composer allows embedding previously composed units into other organizations.

The Behavior Composer provides the user with a flowchart-like graphical language to describe an entity’s or unit’s behavior over time. The output of the tool is an XML formatted composite behavior. Composite behaviors are combinations of primitive behaviors and other composite behaviors. Primitive behaviors are the most atomic level of behaviors. Primitives are created in software, by developers, and are not able to be changed using the Behavior Composer. Behavior primitives contain meta-data that describe its inputs and outputs, as well as the behaviors or physical models the behavior requires to operation, such as mobility models for a movement type behavior. The requirements help reduce scenario runtime errors by ensuring valid physical model and behavior component relationships.

Summary

This article highlights the OneSAF simulation toolkit, its development environment, and its user-oriented composition enabling tools. The paper starts by introducing the OneSAF system, its user community, and their wide range of requirements. This is followed by an overview of the key engineering concepts enabling a simulation toolkit development strategy. Next, the paper highlights the OneSAF software engineering tools and ends with a description of the system and battlespace composition tools.

The OneSAF Objective System promises a wealth of new modeling and simulation lifecycle tools when deployed in FY06. This coupled with a modern extensible software architecture will deliver a robust simulation toolkit for experimentation, analysis, and training across the Army’s modeling and simulation domains for years to come.

References

1. One Semi-Automated Forces (OneSAF) Operational Requirements Document (ORD) Version 1.1, 21 May 2001.

2. A Practical Guide to the Federal Enterprise Architecture, Chief Information Officer Council,Version 1.0 February 1.0. February 2001,

3. Wittman, Robert; Harrison, Cynthia. “The STRICOM Integrated Development Environment (IDE)”, Paper 13, SimTeCT, 2002, Melbourne, Australia.

4. Clemens, Paul; Northrop, Linda. (2002) Software Product Lines Practices and Patterns, Addison Wesley.

5.

6. Boehm, Barry. (2002) “Get Ready for Agile Methods, With Caution”, Computer, January 2002 Volume 35, pp 64-70.

7. Boehm, Barry; Hansen, Wilfred. “The Spiral Model as a Tool for Evolutionary Acquisition.” CROSSTALK May, 2001.

8. Highsmith, Jim; Cockburn, Alistair: (2001) “Agile Software Development: The Business of Innovation”, Editor Barry Boehm, IEEE Computer September 2001, New Jersey

9. McMahon, Paul. “Bridging Agile and Traditional Development Methods: A Project Management Perspective.” CROSSTALK May, 2004, Vol. 17, No. 5.

10.

11.

12.

13.

14.

15.

16.

17.

18.

19.

20.

21.

22.

23.

24.

Author Biographies

ROBERT L. WITTMAN JR. currently works for the MITRE Corporation supporting the OneSAF program. He has been part of the U.S. DoD M&S community since 1990. He holds a B.S. in Computer Science from Washington State University, a M.S. in Software Engineering from the University of West Florida, and a Ph.D. in Industrial Engineering from the University of Central Florida.

DERRICK J. FRANCESCHINI works for Science Applications International Corporation (SAIC) as the OneSAF Product Line Architecture Development (PLAD) Manager.  Previously, Mr. Franceschini was the OneSAF Testbed Baseline (OTB) Project Engineer and the ModSAF Project Engineer.  His work has centered around Modeling and Simulation (M&S) and M&S Architectures.  Mr. Franceschini is an Open Source zealot.

John R. Surdu is an infantry officer currently serving as the Project Manager for OneSAF. He has been working in the M&S community on and off since 1995. He earned a B.S. in Computer Science from West Point, an MBA from Columbus State University, an M.S. in Computer Science from Florida State University, and a Ph.D. in Computer Science from Texas A&M University.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download