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 Soft ware 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.