OneSAF: A Product Line Approach to Simulation Development

Robert L. Wittman Jr.MITRE CORPORATION

3504 Lake Lynda Drive, Suite 155Orlando, FL 32817407-208-1320 x225

rwittman@mitre.org1

Cynthia T. HarrisonU.S Army Simulation, Training and Instrumentation Command (STRICOM)

12350 Research Parkway Orlando, FL 32826407-384-3845

cindy_harrison@stricom.army.mil

Keywords: OneSAF, Computer Generated Forces (CGF), Semi Automated Forces (SAF), ProductLine Development, Product Line Architecture

ABSTRACT: One Semi-Automated Forces (OneSAF) is the United States (U.S.) Army’s next generation simulationsystem being developed to provide an integral simulation service to the Advanced Concepts and Requirements(ACR), Training, Exercises, and Military Operations (TEMO), and Research, Development, and Acquisition (RDA)domains. With requirements ranging from closed-form analytical support to command level human in the looptraining, OneSAF will be an HLA compliant entity level simulation. OneSAF will provide simulation of individualbattlefield components such as soldiers, tanks, and helicopters through aggregate units, to the Brigade level,operating in either a completely automated mode or under the control of the training audience via their organiccommand and control systems or role players using a OneSAF Graphical User Interface (GUI). Simulation entities,units, behaviors, and the synthetic environment will be composable to provide the greatest flexibility to the user inrapidly meeting the scenario requirements for a simulation event. Composition will allow not only ordinary taskorganizations to be defined with doctrinally correct behaviors and ordinary equipment sensor combinations, butwill also support new concepts in combining equipment and sensor pairs as well as new equipment and behaviorcombinations. These ambitious requirements force a new tactic in simulation development. This paper describesthe innovative Product Line approach the U.S. Army’s Simulation, Training and Instrumentation Command(STRICOM) is using to manage the OneSAF development. In doing so it details the combination of Military subjectmatter experts and organizations, processes, and technologies that went into the development of the OneSAFconcept and the integrated repository that houses the OneSAF operational and technical requirements, governmentdirected reuse requirements, and the Product Line Architecture Framework (PLAF).

NOTICE

This technical data was produced for the U.S. Governmentunder Contract No. DAAB07-01-C-C201, and is

subject to the Rights in Technical Data—Noncommercial Items Clauseat DFARS 252.227-7013 (NOV 95)

© 2001 The MITRE Corporation

1 Introduction

The One Semi-Automated Forces (OneSAF) ObjectiveSystem is the United States (U.S.) Army’s nextgeneration, composable, entity based simulation system.

It is being developed to provide an integral simulationservice to the Advanced Concepts and Requirements(ACR), Training, Exercises, and Military Operations(TEMO), and Research, Development, and Acquisition(RDA) domains. With requirements ranging fromclosed-form analytical support to command level human

in the loop training, OneSAF will be a High LevelArchitecture (HLA) compliant entity level simulationproviding a common solution for a broad range of userrequirements. In order to realize this vision aninnovative product line management and developmentapproach has been selected.

The primary purpose of this paper is to describe theorganizations, the foundational technical products, andthe technologies enabling OneSAF to pursue thisproduct line solution.

1.1 Background

The OneSAF concept originated in January 1996following an extensive study that came to theconclusion that the Army was caught in a wastefulspending cycle, making identical or similarenhancements to legacy simulations across threedifferent user domains.

Furthermore, it was determined that none of the existinglegacy simulations were capable of being extended toprovide comprehensive support of emerging Armyfunctional requirements and technical standards.

Realizing this, the Army decided the best approach forovercoming the problems associated with the multitudeof aging simulations was to create a single general-purpose entity level simulation. This solution relies onusing lessons learned from successful simulationprojects like the Modular Semi-Automated Forces(ModSAF) simulation, and the Close Combat TacticalTrainer (CCTT) SAF. [6]

In May of 1997 the Deputy Commanding General(DCG), Training and Doctrine Command (TRADOC)approved the Mission Needs Statement (MNS) forOneSAF which stated [7]:

“The need for OneSAF capabilities is not a response toa specific warfighting threat against the force; the needis driven by the guidance to reduce duplication of M&Sinvestments, foster interoperability and reuse acrossM&S domains, and meet the M&S requirements of thefuture force.”

Shortly thereafter, a Cross-Domain Integrated ConceptTeam was established to design a simulation acquisitionstrategy, draft a program management plan, and beginharmonizing user requirements. This effort has evolvedover the past 4 years and is now culminating incontracts being awarded for development of theOneSAF Product Line Architecture and the variouscomposable products and components.

2 Army Community Involvement

The Army had a monumental task in coordinating thevarious user domains, the combat developer, and theacquisition community in order to create a singleoperational and technical vision for OneSAF. Thissection describes the various Army organizations thathave been involved in OneSAF program since itsinception. We begin with an introduction to the threeuser domains in order to provide the necessary insightinto their roles within the OneSAF program. This isfollowed by a description of TRADOC and STRICOMand their role in the OneSAF acquisition. Finally, theorganizational constructs that have evolved during theOneSAF concept formulation and initial contractingphases are explained.

2.1 Advanced Concept Requirements Domain(ACR)

The ACR domain is under the direction of theTRADOC Analysis Center (TRAC). This community isprimarily interested in the analytical application ofmodeling and simulation. Their intended uses ofOneSAF include the following:

• To explore new and advanced concepts with respectto equipment, organizations, doctrine, andoperational environments,

• To develop and evaluate tactics and OperationalPlans for organizations at Brigade and below,

• To create data that can be used as input to otherclosed form analytic simulations, and

• To provide training associated with a specificlocation prior to real-world deployments. [7]

2.2 Training Exercise and Military OperationsDomain (TEMO)

This domain is led by TRADOC’s National SimulationCenter (NSC) located in Ft. Leavenworth, KS. Theirfocus for OneSAF includes

• Unit training – OneSAF will be used as asimulation driver for round out forces,

• Unit commander and staff training at battalion andbelow in a training exercise, workshop, or seminarenvironment,

• Unit Division commander refresher training, and

• As a mechanism to link live, virtual, andconstructive Synthetic Theater Of War likeenvironments. [7]

2.3 Research Development and AcquisitionDomain (RDA)

The U.S. Army Materiel Systems Analysis Activity(AMSAA) leads the RDA domain with the primarypurpose of Simulation Based Acquisition (SBA). Theyoperate out of the Aberdeen Proving Grounds inMaryland and expect to use OneSAF in support of

• Weapon systems development and productimprovement using appropriate military settingsand context,

• Technical development, test, and evaluation supportfor Army modernization objectives, and

• Communications design and laydown experiments.[7]

2.4 TRADOC Program Office, OneSAF (TPOOneSAF)

TPO OneSAF is the Combat Developer for OneSAFand is responsible for development of the OneSAFOperational Requirements Document (ORD) [7]. TheTPO OneSAF has made significant contributions indefining specific cross-domain requirements withsupport from the RDA, ACR, and TEMO usercommunities.

2.5 Simulation, Training and InstrumentationCommand (STRICOM)

STRICOM serves as the Materiel Developer forOneSAF. The Commander of STRICOM was delegatedas the Milestone Decision Authority (MDA) forOneSAF by the Army Material Command in May of2000 concurrent with the official standup withinSTRICOM of the Product Manager OneSAF (PMOneSAF) office. STRICOM/PM OneSAF has been andcontinues to be the focal point for all OneSAF conceptexploration efforts and development contracts. AsOneSAF transitions out of concept explorationSTRICOM will use its existing STRICOM OmnibusContract (STOC) as the vehicle to access the simulationand software development expertise to create OneSAF.PM OneSAF also provides the coordination function toensure the User Domains remain involved in thecontracting and simulation development process.

2.6 OneSAF Overarching Integrated ProductTeam (OIPT)

The fundamental purpose of the OIPT is to ensure theOneSAF program understands and is responsive to thestrategic guidance of the MDA. In a nutshell, the MDA

decides whether the OneSAF program is meeting itscost, schedule, and performance requirements andshould continue to receive funding. The OIPT also hasa range of senior management responsibilities fromcoordinating the various OneSAF activities to acting asan independent watchdog for cost, schedule andperformance and providing these insights back to theMDA. The group is led by an MDA designee and ismade up of representatives from the OneSAF ProgramOffice, the TRADOC Project Office (TPO), the ArmyModel and Simulation Office (AMSO), the ACRdomain, the RDA domain, and the TEMO domain. [8]

In order to meet its objectives, the OIPT created threesubordinate IPTs: the requirements IPT, the OneSAFTestbed Baseline (OTB) IPT, and the Architecture IPT.

The Requirements IPT was focused on capturingOneSAF requirements across all domains and assessingthem for commonality and variability. This groupmaintains the MNS and the Operational RequirementsDocument (ORD) in addition to recommending specificrequirement prioritization to the OIPT.

The OTB IPT controls the OTB development process.This includes tracking and scheduling of userrequirements, verifying the user feedback process isexecuting smoothly, and ensuring new and relevanttechnologies are integrated into the OTB.

These two IPTs are important in their own right.However, the remainder of this paper concentrates onthe products of the Architecture IPT as this group hasprovided the technical underpinnings of the OneSAFdevelopment process.

2.7 OneSAF Architecture Integrated ProductTeam (A-IPT)

The OneSAF A-IPT was chartered, in support of theOIPT, in April of 1999 under the leadership of theOneSAF Chief Engineer [9]. Primary membershipincludes representatives from the OneSAF TPO, theACR, RDA, and TEMO domains, as well as supportfrom the MITRE Corporation. At inception, the team’sprimary responsibility was to develop a Product LineArchitecture Framework to support and bound theOneSAF procurement process. In doing so the groupperformed various experiments and conceptexplorations to assess and understand the OneSAFarchitectural driving requirements such as scalability,distributed simulation, and optimistic and conservativetime management schemes. The group activelydeveloped products during the period of April 1999through December of 2000.

The products and technology involved will be discussedin later sections but the primary contributions of theArchitecture team include the Product Line ArchitectureFramework (PLAF), the Technical RequirementsDocument (TRD), the Operational Concept Document(OCD), and the Reuse Direction and Guidance (RDG)Document. All of these products are housed andcontrolled in what is termed the OneSAF ElectronicInformation Environment.

2.8 Web Based OneSAF Electronic InformationEnvironment

All of the relevant government OneSAF information isavailable electronically through the OneSAF Web Site(www.onesaf.org). This website was initiated to serveas the repository for both the OneSAF Objective Systemand the OTB. Both public and private (useraccount/password) access are supported. It is intendedto be the one stop-shopping site for OneSAF relevantdata. The private website, in addition to offering webbased search and information access also providesinteractive chat collaboration tools and A-IPT meetingnotes and briefings. At the heart of the private section isthe OneSAF Electronic Information Environment builtupon the commercially available Dynamic ObjectOriented Requirements System (DOORS). [16] Thelogical layout of the DOORS repository is shown infigure 2.1. It holds all of the current governmentgenerated products and will eventually hold thecontractor developed specifications and designs. Inaddition DOORS is used to hold the traceabilitymappings from architecture and design specificationsand other development artifacts back to the operationalrequirements.

Figure 2.1, Electronic Information Environment LogicalLayout

3 The OneSAF Technical Foundation

The A-IPT created a number of technical productsbetween April 1999 and December 2000 with the goalof articulating the government’s product line conceptsand requirements to the modeling and simulationdevelopment community and other externalorganizations. These products supplement the OneSAFORD and are intended to be used as direction andguidance in the development of the OneSAF ProductLine. As mentioned earlier, the A-IPT products includethe PLAF, TRD, OCD, and the RDG Document.

The intent of the government direction is to reduce costand development timelines and increase overall systemperformance. Although other implementations can begenerated it is incumbent on the contractingorganization to present compelling evidence ofsubstantial lifecycle savings in order to change thedirection.

The PLAF is intended to identify basic products,components, and interfaces that support the entirety ofthe OneSAF requirements. It also relates a set ofguiding principles for the product line basedarchitecture. It is envisioned that the OneSAFArchitecture and Integration contractor will revise andextend the PLAF to become the formal OneSAFProduct Line Architecture Specification (PLAS) thatfully specifies the architectural products, components,interfaces, and services.

Finally, the TRD and OCD are considered transitionalproducts intended to provide tools for the Architectureand Integration contractor to construct the OneSAFProduct Line Requirements Specification (PLRS) andthe final Operational Concept Document (OCD).

3.1 Product Line Architecture Framework(PLAF)

The OneSAF Product Line Architecture Framework(PLAF) was developed over a period from mid 1999through October 2000. For OneSAF the product lineconcept is driven by the need to support multiple userdomains with a variety of end state uses. Thus thevariability of a product ranges across severaldimensions:

1) The type of supporting infrastructure (singleprocessor hosted simulation to a distributed multi-processor, multi-host simulation),

2) The type of human interaction ranging fromHuman-in-the-loop (HITL) simulations for training

and mission rehearsal situations to closed formanalytic uses of the simulation.

3) The use of specific applications, AAR, simulatedentity composition, etc. for each user domain.

The initial software development process used inunderstanding the design impacts driven by therequirements was based on a tailored derivation of theTexel/Williams Software Development Processdescribed in detail in [10]. This process describes a usecase based approach intended to explain the objects andinteractions starting at the user interaction level andending with pure software representations. This processwas modified and used only in the conceptualexploration phases, prior to contract award, to focusstrictly on the OneSAF domain user’s perspectivesinstead of internal software design. Together theproducts of this analysis (the End State Scenarios,Operational Architectures, OneSAF Use Cases,OneSAF Lifecycle, and User Categories) makeup theOneSAF Operational Concept Document (OCD). Thisinitial analysis also laid the foundation for the productsand components described within the OneSAF PLAF.

The PLAF is to be used to guide the definition ofindividual components, their services, and interfaces sothat they can be independently developed and thencombined to support a variety of products and systemconfigurations. It is left to the OneSAF Architectureand Integration contractor to determine and provideappropriate definition to the extent to which thecomponents and products can be combineddynamically, during run-time, or statically, duringcompile time.

The PLAF supports a hierarchical composition processto create specific system configurations to support thedifferent user domains. A pictorial representation, takenfrom [11], is shown in figure 2.2. At the highest levelproducts are combined to create the systemconfigurations. The products are complete units offunctionality such as an After Action Review product.Products themselves are made up of one or morecomponents. Components are the elements that can bedeveloped independently and therefore must havecomplete service and interface definitions along with aformal documented process for combining and ensuringthat the overall performance requirements are met.

Figure 2.2, OneSAF Product Line Structure

Figure 2.3, again taken from [11], shows the initialbreakout of system configurations, products, andcomponents using a layering approach. The top blockshows the end user configurations supporting theTEMO, RDA, and ACR domains. Next the productlayer is given showing the products necessary tocompose a complete system configuration. Under eachproduct is a list of the components that need to bedeveloped or harvested through reuse to support theproduct. There may be a number of “same name”components that are developed in order to support thevariability of the OneSAF requirements. Thesecomponents will need to be easily interchanged in orderto support the end user system configurations.

Figure 2.3, the OneSAF Product Line ArchitectureFramework

This section defines the current set of Products and thecomponents that can be composed by the user to createOneSAF system configurations that are suitable for anyparticular use case. The descriptions provided here areconsistent with those contained within the OneSAFTRD but are presented as high level summaries. The

TRD provides the detailed requirements for each of theidentified PLAF Products and Components [12].

3.1.1 Military Scenario Planner Product

The Military Scenario Planner supports the definition ofa Military Scenario Specification in eXtensible MarkupLanguage (XML) that will be used in future simulationevents. It provides a GUI-based mechanism forselection of force structure, overlays, and controlmeasures that bound the scenario. It may also useoperational graphics generated by organic C4I systems.It is a goal of this product to be able to produce militaryscenarios that can be shared by multiple simulations(e.g., WARSIM and COMBATXXI). The MilitaryScenario Development Environment (MSDE)Component is the single component within the MilitaryScenario Planner.

3.1.2 Model & System Composer Product

The Model & System Composer Product supports thecreation of a composite entity, behavior, orenvironmental element from a collection of primitivecomponents. Metadata associated with each primitiveconstrains the process in the creation of allowableconstructs. At a system level, the composer supportsthe creation of tailored applications from desiredsoftware modules or artifacts. The components withinthis product are briefly described below:

The Entity Composer will provide the capability toconstruct entities like tanks from supporting constructslike tracks, turrets, guns, etc. Information describing thenew entity can then be entered within the entitycomposer tool. The entity composer will also allowbehaviors and physical models to be bound to specificentities.

The Unit Composer will provide the capability toconstruct military units (organizations) from other unitconstructs. Information describing the new unit canthen be entered within the unit composer tool. The unitcomposer will also allow behaviors to be bound tospecific units.

The Behavior Composer will provide the capability toconstruct complex behaviors from other primitivebehavior types. Complex behaviors, along with theirrelevant metadata, will be specified in an XML basedBehavior Specification Language. Informationdescribing the new behavior can then be entered withinthe behavior composer tool.

The OneSAF Environment Composer will provide theuser the capability to compose the syntheticenvironment to include, but not limited to, geographiclocation, terrain representation and resolution, featurerepresentation and resolution, atmospheric effectsrepresentation and resolution, bathymetricrepresentation and resolution, etc.

The OneSAF System Composer will provide the userthe capability to compose and tailor the product lineproducts and components to create a specific systemconfiguration (create combat simulation from highresolution entities/units, configure executive to run asfast as possible, repeatable mode, etc.).

3.1.3 Simulation Generator Product

The OneSAF Simulation Generator Product provides aGUI-based mechanism for the selection of theappropriate terrain and environmental information,forces, factional relationships, non-combatantorganizations, data collection information and otherelements necessary to capture the requirements of thescenario at execution. The selection process is supportedby the examination of metadata describing eachelement. The Generator uses the XML Military ScenarioSpecification created by the MSDE component as abasis for extension. The Simulation Generator supportsassociation of synthetic entities with map based controlmeasures and temporal order execution sequences. TheSimulation Scenario Specification is stored in an XML-based format for further processing by the TechnicalManager Product. The Components within this Productare briefly described below:

The OneSAF Simulation Scenario DevelopmentEnv ironment (SSDE) provides the GUI-basedmechanism for the selection of the appropriate forces,factional relationships, non-combatant organizations,and other elements necessary to capture therequirements of the scenario at execution. It updates theSimulation Scenario Specification with this additionaldata.

The OneSAF Environment Database GenerationEnvironment(EDGE) Component provides the GUI-based mechanism for the selection of the appropriateterrain and environmental data necessary to capture therequirements of the scenario at execution. It updates theSimulation Scenario Specification with this additionaldata.

The OneSAF Data Collection Specification Tool(DCST) will allow the user to identify the data items ofinterest for collection during simulation execution. It

updates the Simulation Scenario Specification with thisadditional data.

3.1.4 Technical Manager Product

The OneSAF Technical Manager Product will provideGUI-based mechanisms and the services to supportexercise configuration and setup. The componentswithin this product are briefly described below:

The OneSAF Simulation Executable Builder parsesthe XML Simulation Scenario Specification andprovides the user tools to partition the scenario into sub-elements and build required executables. TheSimulation Executable Builder extends the scenariospecification by embedding a partitioning scheme andexecutable assignments.

The OneSAF Simulation Configuration Tool(SCT)will provide a GUI-based mechanism for theconfiguration of hosts and networks that will participatein a OneSAF execution. The SCT will use the XMLSimulation Scenario Specifications to guide assignmentof software to appropriate computational hosts. TheSCT downloads required executables that are built bythe Simulation Executable Builder to the hosts andhands control over to the Simulation Control Product.

The OneSAF Federation Development Tool willprovide a GUI-based mechanism for supporting theHLA federation development process. This tool shallsupport OneSAF Simulation Object Model (SOM) toFederation Object Model (FOM) mapping in support offederation execution.

The OneSAF Performance Modeling Tool willprovide a GUI-based mechanism to predict runtimeperformance of a particular OneSAF scenario via asimulation of OneSAF execution.

The OneSAF Blaster/Network Loader Tool willprovide a GUI-based mechanism to assess networkperformance and capacity to support a OneSAFexecution. The Blaster/Network Loader Tool willprovide applications for benchmarking absoluteperformance for network comparisons. In addition, fora given network layout the Blaster/Network Loader toolshall provide utilities for estimating network resourcerequirements for a given scenario.

3.1.5 Simulation Core Product

The OneSAF Simulation Core Product will provide thefoundational OneSAF simulation services/executive and

core modeling capabilities and shall provide a GUI tomonitor and control these services. The simulationservices include, but are not limited to, time and eventmanagement, random number generation and streamservices, probability distribution library services, RTIinterface services, standalone single computersimulation implementation services and distributedsimulation services, environmental models, unit models,entity models, etc. The modeling capabilities includemodeling of Units, Entities, Behaviors, PhysicalModels, and the Environment. The components withinthis product are briefly described below:

The OneSAF Simulation Core Services shall include,but are not limited to, time and event management,random number generation and stream services,probability distribution library services, RTI interfaceservices, standalone single computer simulationimplementation services and distributed simulationservices, etc.

The OneSAF Environment Models comprise thoseenvironmental models, both dynamic and static, that arebuilt in support of the OneSAF requirements set.

The OneSAF Unit Models comprise the militaryorganizational or unit models developed in support ofthe OneSAF requirements set. The unit is defined as acomponent of a military, paramilitary, quasi-military(guerilla or terrorist cell, etc.), governmental or otherorganizational hierarchy. Traditional military units areorganized by echelon (e.g., brigade, battalion, company,platoon, squad, team/crew, and individual) with well-established command and control structures.Paramilitary and quasi-military units may cooperatethrough more dynamic or ad-hoc relationship structures.The OneSAF Unit Models provide the runtimerepresentation of the Units identified within theSimulation Scenario Specification.

The OneSAF Entity Models are comprised ofCommand Entities or Basic Entities. A CommandEntity is the physical representation of the commandnode (squad/platoon/company command posts andbattalion Tactical Attack Center (TAC) and TacticalOperations Center (TOC), civilian leader, etc) withinthe simulation and the associated command decisionmaking capability. A Basic Entity is a system that canbe modeled and/or represented within the syntheticenvironment and that can express observable behavior.An entity may be a life form (e.g., human, militaryworking dog) or a platform (e.g., tank, helicopter). TheOneSAF Entity Models provide the runtimerepresentation of the Entities identified within theSimulation Scenario Specification.

The OneSAF Behavior Models provide the runtimemodeling of the cognitive aspect of Units and Entitiesand utilize the XML based behaviors that have beencomposed for each of the scenario’s Units and Entities.

The OneSAF Physical models provide themathematical representation of combat systems andtheir interactions with the environment and otherentities. Physical models may be represented atmultiple levels of fidelity as defined by the TRD.

3.1.6 Simulation Controller Product

The Simulation Controller Product provides allcontrolling mechanisms, displays, and devices forinteracting with OneSAF during runtime. Thesedisplays shall include map-based (PVD) representationof terrain database including unit and platformlocations, overlays, and supporting contextualinformation for simulation execution. SimulationControl will provide controls for interacting with anddirecting behavior of battlefield entities represented inOneSAF. In addition, the Simulation Control Productmonitors the simulation performance during executionand can dynamically shutdown and restart executablesas necessary. The components within this product arebriefly described below:

The OneSAF Management and Control Services arethose necessary to view and control the simulatedentities as a technical controller, battlemaster/seniorcontroller, puckster, analyst, or (Low Overhead Driver)LOD user.

The OneSAF Federation Management Tool shallprovide mechanisms to monitor and control OneSAFFederations.

The OneSAF Data Collector provides the services tocollect and store all of the data identified within theXML based Data Collection Specification created bythe Data Collection Specification Tool.

The OneSAF Annotator will provide anobserver/controller or other remote user the ability torecord electronic form based data entry regarding thesimulation event to support AAR and Analysisactivities. It is envisioned that this will be implementedin a Personal Digital Assistant (PDA)-based application.

3.1.7 OneSAF C4I Adapter Product

The OneSAF C4I Adapter provides bi-directionaltranslation, connection, and control and monitoring ofinformation flowing between real-world C4I systemsand OneSAF. The components within this product arebriefly described below:

The OneSAF Monitor and Control GUI Services willprovide mechanisms to monitor and control the C4Iadapter settings as well as manage, control, or modifythe data flowing between the C4I system and OneSAF.

The OneSAF Translation Services will provide twoway translation services that translate internal OneSAFformats to C4I formats and vice versa. Thesetranslations may include and are not limited to voice,binary, human readable, and database formats.

The OneSAF Connection Services will provide amechanism to connect the Adapter to specific C4Isystems using inherent C4I protocols and physicalconnection mechanisms. These may include but are notlimited to serial communication lines, Ethernet, wirelesscommunications, etc.

3.1.8 After Action Review (AAR) Product

The OneSAF After Action Review Product will supportgraphical review, analysis and presentation of all datacollected during the OneSAF execution. The toolsetshall support mining of collected data to constructMeasures of Effectiveness (MOEs)/Measures ofPerformance (MOPs) and analytical charts and graphsas well as allowing data export to Commercial Off TheShelf Software (COTS) Office Automation andanalytical review tools. The Analysis and Reviewcomponent is the sole component within this product.

3.1.9 Maintenance Environment Product

The OneSAF Maintenance Environment Productprovides an integrated environment to manage all dataand artifacts associated with the OneSAF Product Line.These tools shall span the software developmentlifecycle, from requirements engineering to softwaremaintenance. The Components within this Product arebriefly described below:

The OneSAF Configuration Management Utilitieswill support the configuration management andmaintenance of all data within the repository.

The OneSAF System Accounting Utilities will supportmanagement of user accounts and privileges.

The OneSAF System Asset Management Utilities willsupport the setup and management of network assetsthat include, but are not limited to, communicationslinks, processing nodes, peripheral devices, etc.

The OneSAF System Distribution Services willsupport the distribution of the OneSAF system andproduct lines to the user sites.

The OneSAF Information Security Utilities will assistthe user in management of classified information in theRepository.

The OneSAF Data Harvesting and Translationutilities will support the harvesting and automatedtranslation of data sources commonly used in legacysystems into common data standards and formats to beused within the OneSAF Product Line ArchitectureSpecification.

The OneSAF Software Engineering Environmentwill provide tools to support product line and softwareanalysis, software requirements traceability, softwaredesign, software coding, software debugging, softwaretesting, and software configuration management andrevision control.

The OneSAF Software Installation Tool will providea "wizard like" install tool to automate the softwareinstallation process. This component will verifyminimum system hardware and software requirementsare met. These requirements will include things likeCPU Version, available disk space, Operating SystemVersion, existence of necessary supporting software,etc.

The OneSAF Online Help and Tutorials utilities willsupport the definition and use of context sensitive helpand on-line tutorial capabilities.

The OneSAF Verification and Validation Tool willprovide user access to data confirming that the softwaredevelopment process is being followed. This dataincludes but is not limited to requirements traceability,coding standard adherence proof, internal softwaredocumentation standard adherence proof, ApplicationProgrammer’s Interface (API) standard adherence proof,etc. The OneSAF Verification and Validation Tool willalso provide data aiding in the validation of the modelsagainst real-world data. This data may be providedthrough software instrumentation techniques or otherdata creation and access methods.

The OneSAF Data Management Tool will providemechanisms to access, review, modify, archive, andanalyze data within the OneSAF Repository.

The OneSAF Repository will accommodate allOneSAF data and information. The repository mustaccommodate, at a minimum, the following types ofdata: system and software documentation, system andsoftware source code and executable code, system andsoftware product configuration data and change history,any metadata necessary to support simulationcomposition activities, scenario data, simulationexecution data, simulation execution performancemetrics, results of analysis performed on simulationdata, after action review data, etc.

3.2 Technical Requirements Document (TRD)

The TRD is the companion document to the PLAF. Itprovides the technical requirements for the PLAFproducts and components and is traceable back to theORD [12]. The TRD evolved throughout the durationof the A-IPTs existence. The first step in the TRD’sdevelopment was to transform the structure of ORDbased requirements into independent “shall”requirements. This included deriving requirements,based on information gained during conceptexploration, to add a level of richness to the ORDrequirements. Again the user domains were involvedthroughout this process. Next, the TRD paragraphs ormodules as they are called in DOORS were categorizedor grouped into the products within the Product LineArchitecture Framework (PLAF).

3.3 Operational Concept Document (OCD)

Work on the OCD also began in December of 1999 andran through December of 2000 [13]. The OCD is not asingle document; instead it is a collection of severalanalysis artifacts:

• End State Scenarios: seven from the ACR domain,two from the RDA domain, and six from theTEMO domain,

• Four representative Operational Architectures,

• A set of OneSAF use cases – a representative setfrom each domain,

• A OneSAF exercise lifecycle overview, and

• The set of OneSAF user categories.

The types of information contained in each one of theproducts reflects the culmination of various meetingsand workshops held by the A-IPT.

The End State Scenarios represent the types of militaryoperations that have to be represented in OneSAF tomeet the domains' OneSAF requirements. They includethe military plans, orders, units involved, and thevarious behaviors of the units.

The four representative operation architectures: 1) COADoctrine and Combat Development Tool, 2) Leader andStaff Training – Seminar Driver, 3) MaterialDevelopment Tool, and 4) Seamless Training ExerciseDriver contain the simulation configurationrequirements for each of the representative uses ofOneSAF. The four operational architectures attempt toshow the variations in computer, network, andpersonnel that must be supported by the OneSAFsystem.

The Operational Use Cases show how OneSAF will beused within each domain. The complete set of use casesset the boundaries for the OneSAF system. The usecases from each domain are roughly based on theOneSAF Lifecycle.

The OneSAF Lifecycle was created by looking atprocesses used by legacy systems, interviewing SubjectMatter Experts, and reviewing the ORD and the HLAFederation Development Process (FEDEP). TheOneSAF Lifecycle, as summarized from [13], isdescribed by the following 10 phases:

1 . Event Planning: Operational objectives areidentified and broken down into specific functionalrequirements. This phase normally lasts severalmonths in duration and requires a significantamount of collaboration between event planners.

2 . Database Development : The necessaryenvironmental, unit, behavior, and equipmentdatabases are determined. Datasets are investigatedto identify those that can be reused, those that canbe created through modification, and those thatneed to be created from scratch.

3 . Software Development: Software is developedbased on the results of the Database DevelopmentPhase investigation.

4. Model Composition: Models are generated usingthe model composition tools within OneSAF.

5 . Scenario Generation: All software basedrepresentations required to execute the event areselected and parameterized.

6 . Simulation Configuration: The software isallocated to computational hosts and the simulationnetwork is designed based upon event performancerequirements.

7. Systems Test and Verification: The simulation isrun in a trial mode to see if it executes as plannedand meets performance requirements.

8 . Simulation Execution: The simulation event isexecuted.

9 . Post-Execution Analysis/After Action Review:Data collected during exercise execution isanalyzed and fed to the participants in analyticalform or in a hotwash training forum. This canoccur during and after exercise execution.

10. Archival: All collected data is archived for easyretrieval and analysis.

The final piece of the OCD is the User Category List.This list is intended to identify the critical roles playedby users of OneSAF. This information will be used tocreate appropriate GUIs allowing access to the functionsnecessary for each user type. The list of UserCategories, extracted from [13], is provided below:

1. Software Developer - Responsible for the creationof a specific software artifact.

2. Model Composer - Responsible for the creation ofa composite entity/behavior/unit from a set ofexisting primitives or other composites. Thisprocess includes changing parametric data and theselection of appropriate fidelity within the physicalmodels.

3 . Database Developer - Responsible for thedevelopment of databases in support of a simulationevent

4. Scenario Developer - Responsible for operationalplanning and development of the forces andenvironment for the execution of a simulationevent.

5 . Configuration Manager - Responsible forperforming version control and management of allaspects of the baseline product.

6. Data Manager - Responsible for organization andclassification of data supporting an execution of thesimulation.

7 . System Administrator – Super-User, responsiblefor the successful operation of the OneSAF system.

8. Technical Controller - Responsible for the set up,configuration, monitoring, use, and maintenance ofthe assets supporting the simulation execution.

9. Observer/Controller - Responsible for evaluationof the training audience and recording ofappropriate events/observations.

10. Puckster/Training Audience - Responsible forcontrolling SAF entities during execution of ascenario.

11. Analyst - Responsible for planning, preparation,conduct, and analysis of the simulation event.

12. LOD User - Non-technical user with limited set oftools to tailor and run a predefined scenario.

13. Model Validator - Domain Subject Matter Expert(SME) responsible for validation of the models.

3.4 Reuse Direction and Guidance (RDG)

During the spring of 2000, the A-IPT performed a reuseassessment to identify opportunities to leveragedevelopmental artifacts from existing programs. Thereuse assessment resulted in the RDG document and asupporting reuse repository [14]. The RDG is directlytraceable into the appropriate products within the reuserepository that reference complete fielded anddevelopmental products from numerous programsincluding WARSIM, CCTT, COMBATXXI, and theOTB. As new reuse opportunities are identified and asexisting baselines mature documentation and othersupporting artifacts will be collected and added to therepository. The intent of the reuse repository is toprovide the OneSAF contractors with the government’sauthoritative expectations for product reuse. The reusedefinitions went through a number of iterations andinitially considered knowledge acquisition/requirements, design, and code reuse. With the specifictype of reuse being categorized by the product beingreused. Another level was associated with thecompleteness in which a reused product satisfied anexisting OneSAF requirement. From completesatisfaction at the product level, to partial satisfaction, tosimple algorithmic reuse. The following finaldefinitions are provided within the OneSAF RDGdocument [14]:

“Directed Reuse: The contractor is directed to reuse theidentified product as a starting point for OneSAFdevelopment. Substantial life cycle cost benefits mustbe demonstrated in order to propose a different startingpoint.”

“Recommended Reuse: The contractor is directed toconsider the reuse of the identified products as astarting point for OneSAF development. Life cyclebenefits of using products should be shown along withproposed starting point.”

The directed reuse analysis began with the team lookingat products nominated within each domain and the reusecriteria defined by the A-IPT. The members then wereassigned specific products to assess. The assessmentcentered on meeting the functional requirements asstated within the ORD and TRD. The four-stepassessment process is as follows:

1 . Identify a specific functional area like C4Iinterfaces,

2. Produce a basic statement of the requirements,

3 . Analyze specific products based on therequirements, and

4. Tag the product as directed, recommended, or notto be reused, and provide commentary as needed.

In all, there are approximately 30 items categorized asgovernment directed reuse and 6 as recommended reuse.The basic layout for each reuse assessment is shownbelow.

• Functional Area: Direct reference to TRD.

• Basic Statement of Requirements: Requirementsextracted from TRD.

• Products Considered: Listing of the products thatwere considered by the A-IPT members for reuse

• Directed Reuse: Specific products the governmenthas selected for directed reuse

• Recommended Reuse: Specific products thegovernment has selected for recommended reuse.

• Additional Commentary: Additional commentsgiving rationale or additional detail behind thedirection or recommendation.

4 International CommunityCollaboration Activities

4.1 Organizational Relationships

Since 1997, the OneSAF program has sought out andactively participated with international organizations inthe refinement of OneSAF requirements and concepts.OneSAF has worked specifically with UK DefenceEvaluation and Research Agency (DERA) under anestablished UK-US Information Exchange Agreement[15] to perform collaborative research and developmentinto next generation simulation concepts. The OneSAFprogram is currently supporting the establishment of amodeling and simulation working group as part of theAustralian, British, Canadian, and American (ABCA)Standardization Program [17] with the goal ofexpanding our opportunities for collaboration to includethe appropriate Canadian and Australian defenseorganizations. Initial steps have been taken with theseorganizations to identify common objectives andopportunities for collaboration but the specifics of thesearrangements are still in the early discussion phases.

4.2 Early Technical Transition

The OneSAF program has inserted concepts into theProduct Line approach that not only support theinteroperability and early use of the program by the U.S.Army community, but support the early use of OneSAFby the international community as well. These conceptssupport the transition of the international communityfrom their current ModSAF applications to theappropriate internationally releasable OneSAF versionby providing data/scenario harvesting tools that convertModSAF related data and scenarios into the OneSAFXML based Scenario Specification Language. Inaddition, OneSAF will also provide an early capabilityto define unique service/country scenarios (unitstructures, entities, etc.) and unique service/country unitand entity behaviors (both BLUFOR and OPFOR) byproviding early access to the toolset supporting theOneSAF XML based Scenario Specification Languageand Behavioral Specification Language.

5 Summary

In summary, the OneSAF program will provide the U.S.Army with substantial lifecycle savings by significantlyreducing redundant SAF software development andevolution efforts, increasing interoperability and reusingproducts across the SAF user community, and by usingleading edge product line architecture and designtechniques to provide a modular, composable systemthat will support Army requirements into the future. Tosupport this the Army leadership including STRICOM,the TPO, and the Army user domains: ACR, RDA,TEMO have collaborated to provide a series of productswhich convey the Government’s OneSAF requirementsand product line concepts to our industry partners andother external organizations.

6 References

[1] Bosch, Jan: “Design &Use of SoftwareArchitectures: Adopting and evolving a product-line approach”, Addison-Wesley, 2000.

[2] OneSAF Architecture-IPT: “Near Term Schedule”,Architecture-IPT Meeting Products, Dec. 6, 1999.

[3] OneSAF Architecture-IPT: “OneSAF Object ModelDevelopment Briefing”, Architecture-IPT MeetingProducts, December 6, 1999.

[4] OneSAF Architecture-IPT: “OneSAF ReuseAssessment”, Architecture-IPT Meeting Products,December 6, 1999.

[5] Harrison, Cindy: “OneSAF Architecture R&DPlan”, 13 April 1999.

[6] “One Semi-Automated Forces (OneSAF) MissionNeeds Statement (MNS)”, approved May 1997.

[7] “One Semi-Automated Forces (OneSAF)Operational Requirements Document (ORD)Version 1.1”, 14 January 2000, Final Draft.(http://www.onesaf.org/public1safdocs.html).

[8] OneSAF OIPT: “ONE SEMI-AUTOMATEDFORCES (OneSAF) Overarching integratedProduct Team (OIPT) Charter”.

[9] OneSAF Architecture-IPT: “One Semi-AutomatedForces (OneSAF) Architecture Integrated ProductTeam (IPT) Charter”, April 1999.

[10] Texel, Putnam P. and Williams, Charles B.: “UseCases Combined with Booch/OMT/UML: Processand Products”, Prentice Hall, 1997.

[11] STRICOM: One Semi-Automated Forces (One-SAF) Product Line Architecture Framework(PLAF), October 31, 2000.

[12] STRICOM: “One Semi-Automated Forces(OneSAF) Technical Requirements Document(TRD)”, DOORS Electronic InformationEnvironment, October 31, 2000.

[13] STRICOM: “One Semi-Automated Forces(OneSAF) Operational Concept Document (OCD)”,DOORS Electronic Information Environment,October 31, 2000.

[14] STRICOM: “One Semi-Automated Forces(OneSAF) Reuse Direction and Guidance (RDG)DOORS Module”, DOORS Electronic InformationEnvironment, October 31, 2000.

[15] IEA-UK-A-A-97-1543, “UK-US InformationExchange Memorandum of Understanding, AnnexConcerning Modeling and Simulat ionTechnologies”, 1997.

[ 1 6 ] D O O R S , A T e l e l o g i c P r o d u c t:http://www2.telelogic.com/doors.

[17] Australian, British, Canadian, and American( A B C A ) S t a n d a r d i z a t i o n P r o g r a m ,http://www.abca.hqda.pentagon.mil.

Author Biographies

ROBERT L. WITTMAN JR. currently works for theMITRE Corporation supporting the OneSAF program.He has been part of the U.S. DoD M&S communitysince 1990. During that time he has providedsimulation engineering support to the Joint Staff J-8,JWFC, JSIMS, and STRICOM. He holds a Bachelor ofScience in Computer Science from Washington StateUniversity, a Master of Science in Software Engineeringfrom the University of West Florida, and is currentlyenrolled in the Industrial Engineering Ph.D. program atthe University of Central Florida.

CYNTHIA T. HARRISON currently works for theU.S. Army STRICOM as the Chief Engineer for theOneSAF Program. Since 1985, she has had a wide

variety of experience in the Live, Constructive, andVirtual simulation domains for the Army and Navy.Ms. Harrison holds Bachelor and Master of Sciencedegrees in Computer Science from the University ofCentral Florida.