Live, Virtual, Constructive, Architecture Roadmap Implementation … · 2011-05-15 · Live,...
Transcript of Live, Virtual, Constructive, Architecture Roadmap Implementation … · 2011-05-15 · Live,...
![Page 1: Live, Virtual, Constructive, Architecture Roadmap Implementation … · 2011-05-15 · Live, Virtual, Constructive, Architecture Roadmap Implementation and Net-Centric Environment](https://reader034.fdocuments.us/reader034/viewer/2022042304/5ecf2925d085a11e0a5db0cd/html5/thumbnails/1.jpg)
Live, Virtual, Constructive, Architecture RoadmapImplementation and Net-Centric Environment Implications
Gary W. Allen, Ph.D.
Joint Training Integration and Evaluation Center, Orlando, Florida
Robert Lutz
Johns Hopkins University/Applied Physics Laboratory, Laurel, Maryland
Robert Richbourg, Ph.D.
Institute for Defense Analysis, Alexandria, Virginia
In 2008 the DOD Modeling and Simulation Coordination Office (M&SCO) published the
Live, Virtual, Constructive, Architecture Roadmap (LVCAR) study. LVCAR focused on four
important dimensions of simulation interoperability: technical architecture, business models, the
standards evolution, and management processes. A key product from the LVCAR study was
nineteen recommendations for future efforts. The purpose of this article is to describe how those
recommendations are being implemented under the M&SCO High Level Task SC2. The
article includes a description of each task area, how the task is being addressed, and current
results. The article also describes efforts to look at potential advanced technologies like service
oriented architectures (SOA) and their application to the DOD modeling and simulation
(M&S) environment.
Key words: Modeling; simulation; live, virtual, constructive, architectures; gateways; bridges;
net-centric environment; roadmap; object models; IEEE; DSEEP; ANDEM; SOA.
Current simulation event engineers havea range of architectural capabilitiesopen to them. They can select a‘‘minimalist’’ intercommunication ar-chitecture, providing little more than a
communications service, or they can utilize a morecomplex architecture featuring multiple advancedservices such as time and data management. Theycan also choose to rely on multiple architectures, asoccasionally necessitated by the mix of simulationsystems that will be combined in the event. However,mixing architectures is not easily achieved: bridgesmust be installed, gateways developed, and dataexchange models (i.e., object models) rationalized andcomposed. The additional effort required to employmixed architectures is ‘‘over and above’’ that necessaryto join the simulations systems, which use a commonarchitecture, and is frequently viewed as a baselessrequirement that would be unnecessary except for themultiple architectures involved. As a result, the Officeof the Secretary of Defense (OSD) Modeling andSimulation (M&S) Steering Committee commissioneda study to examine various aspects of M&S develop-
ment and make recommendations that could improvearchitecture interoperability.
The Live, Virtual, Constructive, Architecture Road-map (LVCAR) study began in April 2007. The M&SSteering Committee recognized that M&S capabilityhad greatly advanced, routinely enabling the linkage ofcritical resources through distributed architectures. Inpart, the success was predicated on an iterative andevolutionary development of the intercommunicationarchitectures, including progressive capabilities en-hancements supporting more varied application of thetechnologies across expanding user domains. While thearchitectures displayed impressive capability to meetneeds as designed, they were not implemented with afocus on ensuring architectural compatibility. Thus,each requirement to connect systems using differentarchitectures within a single simulation event wasaccompanied by substantial design and engineeringeffort to achieve cross-architecture interoperability.Given this environment, the LVCAR study waschartered to ‘‘… methodically and objectively developa recommended roadmap (way forward) regardingLVC interoperability across three broad areas of
ITEA Journal 2010; 31: 355–364
31(3) N September 2010 355
![Page 2: Live, Virtual, Constructive, Architecture Roadmap Implementation … · 2011-05-15 · Live, Virtual, Constructive, Architecture Roadmap Implementation and Net-Centric Environment](https://reader034.fdocuments.us/reader034/viewer/2022042304/5ecf2925d085a11e0a5db0cd/html5/thumbnails/2.jpg)
Report Documentation Page Form ApprovedOMB No. 0704-0188
Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering andmaintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information,including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, ArlingtonVA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if itdoes not display a currently valid OMB control number.
1. REPORT DATE SEP 2010 2. REPORT TYPE
3. DATES COVERED 00-00-2010 to 00-00-2010
4. TITLE AND SUBTITLE Live, Virtual, Constructive, Architecture Roadmap Implementation andNet-Centric Environment Implications
5a. CONTRACT NUMBER
5b. GRANT NUMBER
5c. PROGRAM ELEMENT NUMBER
6. AUTHOR(S) 5d. PROJECT NUMBER
5e. TASK NUMBER
5f. WORK UNIT NUMBER
7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) Joint Training Integration and Evaluation Center,Orlando,FL,32820
8. PERFORMING ORGANIZATIONREPORT NUMBER
9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S)
11. SPONSOR/MONITOR’S REPORT NUMBER(S)
12. DISTRIBUTION/AVAILABILITY STATEMENT Approved for public release; distribution unlimited
13. SUPPLEMENTARY NOTES
14. ABSTRACT
15. SUBJECT TERMS
16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF ABSTRACT Same as
Report (SAR)
18. NUMBEROF PAGES
10
19a. NAME OFRESPONSIBLE PERSON
a. REPORT unclassified
b. ABSTRACT unclassified
c. THIS PAGE unclassified
Standard Form 298 (Rev. 8-98) Prescribed by ANSI Std Z39-18
![Page 3: Live, Virtual, Constructive, Architecture Roadmap Implementation … · 2011-05-15 · Live, Virtual, Constructive, Architecture Roadmap Implementation and Net-Centric Environment](https://reader034.fdocuments.us/reader034/viewer/2022042304/5ecf2925d085a11e0a5db0cd/html5/thumbnails/3.jpg)
concern: notional definition of the desired futurearchitecture standard, the desired business model(s),and the manner in which standards should be evolvedand compliance evaluated.’’ (Henninger et al. 2008)
Study emphasis was placed on analysis of thetechnical options that could achieve or make transpar-ent architecture interoperability. The analyses wereinfluenced by several characteristics of the operatingenvironment. A fundamental observation was that theuser communities expressed little, if any, complaintthat architectural capabilities were lacking; the multi-architecture state not only provided a high level ofsupport across a diverse user community but alsoallowed a degree of user choice in selecting thearchitecture that best balanced cost and capabilitywithin the context of a specific application. Moreover,connecting the different architectures together was atractable problem with which the community haddeveloped a base of expertise and resources, albeitnonoptimal. The study also concluded that the cost ofswitching applications to use of different architectureswas high, often prohibitive at the level where costswould be borne. Thus, any unfunded mandatedirecting users to change architectures would likelybe ignored. Further, no existing business or manage-ment tools could enforce such mandates. In thiscontext, the study concluded that fundamental changeeither to the number of available architectures or to thearchitectures themselves was not warranted or desir-able. Finally, the implementation of a new, ‘‘improvedreplacement’’ architecture would only introduce yetanother architecture requiring integration, effectivelydegrading interoperability.
Based on these characterizations of the problem, thestudy recommendations emphasized a two-front phi-losophy. First, near-term actions were necessary to easethe problem of architecture integration. Integrationshould be made transparent, so that users wouldinteract with a seamless ‘‘architecture of architectures.’’Second, a longer-term goal emphasized an evolution-ary process of Common Training InstrumentationArchitecture (CTIA), High-Level Architecture(HLA), and Test-Training Enabling Architecture(TENA) architectural convergence. Individual actionssupporting both strategies are now ongoing.
The current LVCAR Implementation (LVCAR-I)program is the follow-on effort, concentrating on fivetasks designed to address specific recommendationsidentified in the original LVCAR report. These fivetasks include LVC Common Capabilities, LVCArchitecture Convergence, Common Gateways andBridges, Joint Composable Object Model (JCOM)Development, and Managing the LVC Environment.
LVCAR-I project overviewThe project’s aim is to explore organizational and
structural (e.g., use of standards) options to better (a)manage LVC architecture interoperability; (b) createreference models to focus data and service reuse efforts;(c) reduce LVC architecture divergence and toolproliferation; and (d) explore emerging technologyissues related to future LVC architecture performanceand requirements. The planning, development, andexecution of LVC events are universally recognized tobe expensive by any measure. Also, the M&Scommunity lacks the agility to support unforeseenevents without great difficulty. Given this situation,the objective of LVCAR-I is to reduce overhead andthus improve the ability to construct and conducttimely LVC events. Described another way, the goalfor LVCAR-I is to get M&S support inside themilitary operations decision cycle.
The project leads have taken a holistic approach toorganization and definition of an acquisition strategy.Fundamentally, LVCAR-I is designed to work in anenvironment where there are many different factorsand incentives that influence decisions, includingwillingness to change and the adoption of technicalsolutions. Understanding these factors and their effectsare as important to the success of the project as thetechnology advances themselves. As a result, theLVCAR-I team distilled the 19 recommendationsfound in the LVCAR study to the grouping of core,affiliated, and supporting efforts as described inTable 1.
Core task organization and groupingBeginning in Fiscal Year 2009 (FY09), a team led by
the Johns Hopkins University/Applied Physics Labo-ratory ( JHU/APL) initiated efforts to implement theLVC Architecture Roadmap. The overall organizationof the effort is shown in Figure 1.
This particular organization was designed to reflectthe blended, two-front strategy defined in the Road-map. ‘‘LVC Common Capabilities’’ and ‘‘CommonGateways and Bridges’’ focus on improvements in theprocesses, tools, and supporting resources used todevelop LVC environments in the near-to-mid term.‘‘LVC Architecture Convergence’’ focuses on mid-to-long–term actions to prevent further divergence (andfacilitate convergence) among the major simulationarchitectures in wide use across the Department ofDefense (DoD) today. In addition, the ‘‘Managing theLVC Environment’’ task is designed to identifyexisting business models and management structuresfor each of the major simulation architectures, assessthe relative strengths and weaknesses of each, and
Allen, Lutz, & Richbourg
356 ITEA Journal
![Page 4: Live, Virtual, Constructive, Architecture Roadmap Implementation … · 2011-05-15 · Live, Virtual, Constructive, Architecture Roadmap Implementation and Net-Centric Environment](https://reader034.fdocuments.us/reader034/viewer/2022042304/5ecf2925d085a11e0a5db0cd/html5/thumbnails/4.jpg)
recommend some potential realignments to improveefficiency and reduce maintenance costs in the future.
The following sections describe the rationale andobjectives associated with these three main technicalareas of LVCAR-I tasking, and delineates the specificactivities being performed within each area.
Core task: LVC common capabilities. DuringLVCAR development, it was recognized that theabsence of supporting products was creating anunnecessarily heavy burden on developers of multi-architecture LVC simulation environments. Thisincreased the technical and cost risks inherent to theLVC development process and adversely affected LVCinteroperability. LVCAR workshops were held withusers and developers of multi-architecture environ-ments to assist in the identification of necessaryproducts and to estimate the return on investmentassociated with implementing these products. Based on
the assessment of workshop feedback, four categoriesof products were identified as having the highest valueto the LVC community, as summarized below.
Systems engineering process. When user communi-ties of different simulation architectures must develop aunified multi-architecture distributed simulation envi-ronment, the different development processes native toeach user community can create barriers to effectivecollaboration. For multi-architecture LVC develop-ment to be successful, the communities aligned withthe different simulation architectures need to worktogether toward common goals; differences in thepractices and procedures inherent to these communi-ties can lead to misunderstandings, misinterpretations,and general confusion among team members. The keyproduct identified to address this problem was acommon systems engineering process for the develop-ment and execution of multi-architecture simulationenvironments.
Rather than develop a whole new process, this taskleverages an emerging Institute of Electrical andElectronic Engineers (IEEE) process standard (IEEE1730) as a framework onto which multi-architectureissues and solutions can be overlaid. This framework, theDistributed Simulation Engineering and ExecutionProcess (DSEEP), tailors best practices in the systemsand software engineering communities to the domain ofdistributed simulation. The DSEEP defines the se-quence of activities to develop and execute distributedsimulation environments in an architecturally neutralmanner (Figure 2). Using this framework, the keytechnical issues associated with multi-architecture de-velopment are aligned with the activities within theprocess, and user guidance is provided on how to addresseach issue based on existing community practices.
Upon completion of the Systems EngineeringProcess task, IEEE standardization is expected tocommence. Given the close ties to the DSEEP, the
Figure 1. Organization for live, virtual, constructive,
architecture roadmap implementation.
Table 1. Overview of live, virtual, constructive, architecture roadmap—implementation efforts.
Core task Affiliated task Supporting task
Standards
development
Systems engineering process
Federation agreement templates
Reusable development tools
Asset reuse mechanisms
Software
development
Common gateways and bridges Joint composable object model
Architecture convergence
Studies Management—product transition
strategy
Management organizations and
processes
SOA concepts
LVC futures
Outreach Core task workshops Management workshops M&S forums/presentations
Working group presentations
Web-based information
SOA, service-oriented architecture; LVC, live, virtual, constructive; M&S, modeling and simulation.
The Roadmap
31(3) N September 2010 357
![Page 5: Live, Virtual, Constructive, Architecture Roadmap Implementation … · 2011-05-15 · Live, Virtual, Constructive, Architecture Roadmap Implementation and Net-Centric Environment](https://reader034.fdocuments.us/reader034/viewer/2022042304/5ecf2925d085a11e0a5db0cd/html5/thumbnails/5.jpg)
Systems Engineering Process is expected to become thefirst officially recognized DSEEP overlay (i.e., IEEE1730.1). Other supporting overlays are expected in thenear future (e.g., verification, validation and accredi-tation, test and evaluation) to provide additional LVCcommunity support.
Federation agreement templates. Many agreementsmust be established for an LVC simulation environ-ment to function properly. Examples include referenceframes, shared databases, entity enumerations, andsupporting tools such as loggers and viewers. In multi-architecture LVC environments, there is an evenbroader list of agreements that must be negotiated,including execution management mechanisms, gate-ways, and supporting middleware. Unfortunately, thereis no cross-architecture standard for the content orformat of federation agreements; these agreements areusually local conventions or are completely ad hoc.This implies that multi-architecture LVC initiativesmust continuously recreate the types of information orproducts requiring cross-architecture agreements, in-creasing development time, and introducing thepossibility of missed agreements. The lack of astandard template for federation agreements alsoadversely affects the reusability of the agreementsbetween programs.
The purpose of the Federation Agreements Tem-plate task is to develop an architecture-independenttemplate for establishing federation agreements, alongwith potential architecture-specific extensions. Thecontent and format of the emerging template is basedon examples of federation agreements documentsdeveloped to support programs across the DoD andrepresents a reconciliation of the varying interests ofthe different architecture communities. The template isexpressed in an Extensible Markup Language (XML)schema, enabling machine-readable interchange offederation agreement data. In the future, a tool willbe developed that implements the schema and providessome degree of automation for all users of this product.
Reusable development tools. Every step in theprocess of distributed simulation development includes
many opportunities for automation. These includeutilities such as requirements development tools,scenario development tools, conceptual and objectmodeling tools, testing tools, and after action reviewtools. While these tools satisfy most functional needs, awide range of business models are used across the toolspectrum, including government off the shelf, com-mercial off the shelf, and proprietary solutions(Figure 3). This is a significant impediment to sharingof tools, especially for multi-architecture development.The varying formats used by these tools to store andexchange data are yet another impediment to reuse oftools across architectural boundaries.
The purpose of this task is to examine the variousbusiness model options associated with efficientsharing of tool resources for LVC simulation applica-tions, identify the most beneficial approach, andimplement that approach in a phased, controlledfashion driven by the areas of greatest need. The mainproduct of this activity is an identified set of LVCdevelopment tools that are reusable across differentarchitectures along with supporting business modelsfor tool distribution and maintenance. The otherproduct of this activity is a set of architecture-independent formats for data storage and exchangeacross architectures.
Asset reuse mechanisms. There are currently severalrepositories and registries in use across the DoD. Themain clearinghouse for M&S information is theModeling and Simulation Information Analysis Center(MSIAC). The Services’ Modeling and SimulationResource Repository is accessible through the MSIAC,thus allowing a wide range of search capabilities relevantto developing or employing M&S applications. How-ever, estimates of utilization indicate that there arerelatively few users, and the level of M&S asset reuseappears to be much lower than desired.
The purpose of this task is to examine existing DoDrepository and registry capabilities for M&S reuse.This includes sponsored reuse initiatives such as M&Scatalogs and metadata discovery specifications. Theproduct of this task is a plan of actions and activities to
Figure 2. Distributed simulation engineering and execution process top-level process flow.
Allen, Lutz, & Richbourg
358 ITEA Journal
![Page 6: Live, Virtual, Constructive, Architecture Roadmap Implementation … · 2011-05-15 · Live, Virtual, Constructive, Architecture Roadmap Implementation and Net-Centric Environment](https://reader034.fdocuments.us/reader034/viewer/2022042304/5ecf2925d085a11e0a5db0cd/html5/thumbnails/6.jpg)
better support the reuse of LVC assets across theDepartment. This plan not only identifies basicinfrastructure improvements but also provides recom-mendations on supporting processes and businessincentives based on an analysis of the causes behindprograms ‘‘building new’’ rather than reusing existingcapabilities.
Core task: common gateways and bridges. Thesecond major category of LVCAR-I core tasksexamines common gateways and bridges. These areessential elements that link disparate LVC assets andtranslate across multiple protocols in multi-architectureenvironments. However, there are several persistentproblems that result in barriers to cross-architectureinteroperability. Many of these issues stem from thelack of standard mechanisms supporting gatewaycapability discovery, configuration, and employment.Thus, many project managers find it much easier tosimply build their own gateways, specifically tailored totheir specific application, rather than attempt to reuseexisting gateway assets. This has resulted in a largenumber of program-specific gateways that are notreusable outside of their design context. This is grosslyinefficient from a corporate perspective, as not onlydoes the government pay over and over again to buildthe same basic gateway capabilities, but it also pays forthe maintenance of a large number of redundantgateways.
The purpose of this task is to develop supportingproducts that improve efficiency and effectiveness relatedto gateway use. The task involved an early outreachactivity to characterize existing gateways according to adefined set of features. This provided an early glimpse ofthe requirements that could be met through existinggateways. While this identified a small number ofcapability gaps, it also brought out the high degree ofredundancy among current gateways. Next, a strategy wasdeveloped to discourage new gateway development whilemaking existing gateways more accessible and easier touse. The fundamental, enabling tasks that collectivelydefine this strategy can be summarized as follows:
N A common Gateways Description Language,which allows for the description of gatewaycapabilities in a machine-readable form. Thisallows gateway users to discover needed capabil-ities via automated means rather than manualsearches of gateway documentation.
N A set of Gateway Performance Benchmarks, whichprovides a common way of assessing the relativeability of competing gateways to provide neededcapabilities.
N A common Gateway Configuration Model, whichprovides a standard means of initializing, tailor-ing, and configuring gateways.
Efforts to begin all three of these products have beeninitiated. Tools to implement these specifications areexpected to be developed in the FY12 timeframe.
Core task: LVC architecture convergence. There is ageneral consensus within the LVC community thatsome degree of convergence among the major simu-lation architectures would be beneficial. Adjudicationof architectural differences, even if it can only beachieved for some service categories and only betweencertain architectures, would reduce efforts to imple-ment potentially ad hoc cross-architecture solutionsduring LVC developments and generally improveLVC interoperability. However, there are manybarriers to achieving architecture convergence. Whilethere are certainly technical challenges, the businessmodel and management challenges are even moreformidable. The full range of these challenges must beaddressed for any viable architecture convergencestrategy to succeed.
The purpose of this task is to examine the issues andrisks related to architecture convergence and to developan evolutionary strategy to achieve convergence. Thetask required an analysis of existing simulationarchitectures to identify candidates for convergence,followed by an assessment of the implementations ofthe various architecture services to determine exactlyhow and where to target convergence activities. Finally,convergence options were identified and evaluated
Figure 3. Live, virtual, constructive development tool business models.
The Roadmap
31(3) N September 2010 359
![Page 7: Live, Virtual, Constructive, Architecture Roadmap Implementation … · 2011-05-15 · Live, Virtual, Constructive, Architecture Roadmap Implementation and Net-Centric Environment](https://reader034.fdocuments.us/reader034/viewer/2022042304/5ecf2925d085a11e0a5db0cd/html5/thumbnails/7.jpg)
from the technical, business, and management per-spectives. Recommendations on subsequent conver-gence activities are made as part of this assessment.
A key aspect of the convergence task is to categorizesimulation architecture services into those that arearchitecture specific (i.e., do not need to be interop-erable between architectures for multi-architectureevents to operate properly) and those that are‘‘functionally similar’’ across the architectures. Thefunctionally similar services are candidates for becom-ing ‘‘converged’’ services, which must be aligned for thearchitectures to work together without loss of func-tionality. Three alternatives for implementing theconverged services have been considered:
N Establish a wire standard defining how allsimulation architectures communicate data;
N Establish a static application programmer’s inter-face and implementation of the convergedservices; and
N Build a shared implementation of the convergedservices, referred to as the Common SimulationInfrastructure (CSI).
Figure 4 illustrates how the CSI concept wouldwork. All architecture-specific communication wouldtake place via the same middleware services that thesimulations currently use. However, the middlewarewould communicate through the CSI for all ‘‘con-verged functionality’’ communication with other sim-ulations. The CSI would automate the alignmentacross the converged services so that effective anddirect interaction among simulations employing inter-faces from different architectures is possible. Note thatgateways are still required to integrate DistributedInteractive Simulation (DIS) simulations into multi-architecture LVC environments, due to the difficultyof achieving meaningful convergence between DIS andother architectures.
Follow-on efforts in the architecture convergencearea are expected to focus initially on socialization ofconvergence options with affected communities, andpotentially some early experimentation with a CSIprototype. Discussion of business model and manage-ment concerns will be part of this socialization processto ensure community support before progressing downany particular convergence path.
Affiliated task: the Joint Composable ObjectModel (JCOM) program
The JCOM effort is being jointly sponsored by theJoint Forces Command and the Modeling andSimulation Coordination Office. The effort will resultin a repository of commonly used components of objectmodels, an Architecture Neutral Data ExchangeModel (ANDEM) format to represent those compo-nents, and a set of tools to facilitate the assembly ofthose components. The JCOM effort relies on aninformation-based approach in that much of thedisparate information necessary to create an objectmodel is both represented in the system and linked torelated information. That is, run-time data exchangebetween simulation systems occurs to support a specificpurpose (e.g., training for chemical, biological, radio-logical, nuclear, and high-yield explosives operations;acquisition related to Joint close air support; planningfor time sensitive targets missions). Several missionareas have been decomposed and represented in theJCOM repository, including links to related compo-nents of object models. Users can exploit these linkagesby identifying components that support specificmission areas or by finding the degree of missionsupport offered by a specific object model. JCOM isthe only utility that exploits these types of relationshipsbetween mission areas and object model componentsand thus offers a unique capability supporting widelyranging users including acquisition executives, trainers,
Figure 4. Common simulation infrastructure concept.
Allen, Lutz, & Richbourg
360 ITEA Journal
![Page 8: Live, Virtual, Constructive, Architecture Roadmap Implementation … · 2011-05-15 · Live, Virtual, Constructive, Architecture Roadmap Implementation and Net-Centric Environment](https://reader034.fdocuments.us/reader034/viewer/2022042304/5ecf2925d085a11e0a5db0cd/html5/thumbnails/8.jpg)
experimenters, and event designers. JCOM alsoprovides unique capabilities for event engineers whomake the related simulation event a reality.
Typically, event engineers start their work byadapting solutions to similar problems. In the JCOMcontext, event engineers start with the object modelsfrom a set of previously completed simulation eventsthat collectively solve the problem at hand. Theproblem then becomes one of composing a new objectmodel from the existing set of object models. This is afamiliar problem usually solved at a ‘‘FOMorama,’’ ameeting of engineers well versed in the contents ofeach object model. Collectively, they are able tocompose the different models into a single objectmodel that meets the needs of all systems. This task is alaborious manual analysis completed by a group of veryexperienced engineers. JCOM addresses this part ofthe problem by automatically comparing data exchangemodels (including cross-architecture comparisons ofmodels from HLA, TENA, CTIA, or DIS) to identifyboth similarities and differences. This permits theengineers to focus their attention on only those parts ofthe object models that JCOM could not automaticallyequate, greatly reducing the time and effort to preparea composition that supports the needs of all systems.
Supporting task: M&S service-orientedarchitecture concept pilot—educate, inform,and present.Educate and inform. Service-Oriented Architecture(SOA) technology holds great promise for addressingmany of the technical challenges documented in theLive Virtual Constructive Architecture Roadmap Study.Where existing architectures use different protocols andinterfaces, SOA offers services that enable composa-bility of systems via a layer of abstraction. Where cur-rent M&S data repositories, such as terrain databases,are duplicative, SOA offers the possibility of services thatpromote reusability. The philosophy of SOA is con-structed on the guiding principles of ‘‘reuse, granularity,modularity, composability, componentization, and in-teroperability’’ (IBM 2004).
However, SOA is not a panacea. In particular, usingan SOA to provide the interfaces to an LVCdistributed simulation, in and of itself, will not causeall fundamental problems to disappear. SOA use canprovide the scaffolding to address these issues at thetime of design and initial implementation, easingfuture burdens of functional and communicationcompatibility.
There have been studies and demonstrations that theSOA framework can support LVC multi-architecturaldistributed simulations. However, SOA has not beenembraced by the M&S community or by LVC multi-
architecture developers. There are both real andperceived up-front costs of employing a new technol-ogy to address compatibility issues that have tradition-ally been addressed with ad hoc gateways and bridges,one-of-a-kind database connectors, and other single-point design solutions. Therefore, the objective of thiseffort is to educate and inform the DoD M&Scommunity of the benefits and barriers related toemploying SOA technology.
SOA concept prototype. The DoD led the way inSOA-like architectures such as HLA, TENA, andCTIA—all of which built on the then-emergingCommon Object Request Broker Architecture definedby the Object Management Group. These architec-tures were designed to integrate enclaves of individualsystems and are not optimized to bridge enclaves acrossan enterprise. In contrast, industry has developedrobust SOA-based software technologies and standardsthat clearly have the potential to provide for architec-ture interoperability to interconnect between stand-alone enclaves at the enterprise level and to serve as theprimary infrastructure for common services, such asinterfaces to battle command systems or models of thesynthetic natural environment.
The concept of using the SOA-based software andstandards in this mode, as shown in Figure 5, is notnew and is being eyed with keen interest by many inthe simulation industry. However, no extant programof record can afford to put their program at risk(especially in the current high ops tempo environment)on an unproven approach, no matter how promising.As an early step towards realizing the concept shown inFigure 5 the ‘‘Present’’ portion of the M&S SOAConcept Pilot implements an integrated set ofsupporting simulation services and creates a prototypelinking two disparate enclaves using real federationsand real simulations along with a surrogate service(Figure 6).
This effort will bridge the Joint Conflict andTactical Simulation (JCATS) federate in the Army’sEntity Resolution Federation (ERF) with the WAR-SIM Intelligence Model (WIM) federate in theWARSIM federation and a surrogate service toemulate the Order of Battle System (OBS) to initializeboth federations.
The prototype will provide information to assess theability of SOA to address the following LVCrequirements:
N a common data interchange;N enclave policy translation;N use of a common service to replace equivalent
application (federate) functionality; andN run-time performance and scalability.
The Roadmap
31(3) N September 2010 361
![Page 9: Live, Virtual, Constructive, Architecture Roadmap Implementation … · 2011-05-15 · Live, Virtual, Constructive, Architecture Roadmap Implementation and Net-Centric Environment](https://reader034.fdocuments.us/reader034/viewer/2022042304/5ecf2925d085a11e0a5db0cd/html5/thumbnails/9.jpg)
Supporting task: beyond SOA—a look to the futurefor U.S. DoD M&S. The purpose of this task is to lookat emerging technologies and processes that the DoDM&S community should consider in future develop-ment projects. This is not intended to be an exhaustive
study but rather an overview with rationale thatexplains why each technology/process is significant.
Since the DoD is a consumer, not a driver of theInformation Technology (IT) market place, it mustmake best use of the commercial IT standards,
Figure 6. Proposed prototype for an interoperable architecture implementation between two disparate architectures.
Figure 5. A hypothetical interoperable architecture linking legacy enclaves and common services.
Allen, Lutz, & Richbourg
362 ITEA Journal
![Page 10: Live, Virtual, Constructive, Architecture Roadmap Implementation … · 2011-05-15 · Live, Virtual, Constructive, Architecture Roadmap Implementation and Net-Centric Environment](https://reader034.fdocuments.us/reader034/viewer/2022042304/5ecf2925d085a11e0a5db0cd/html5/thumbnails/10.jpg)
practices, and technologies available to meet theirneeds. Given the long lead times that are typical forDoD project initiation (3–10 years), the Departmentmust have a long view, informed by knowledge ofcoming capability, as a precondition to relying on bestpractices. A set of military operational scenarioscovering the spectrum from high tempo kineticoperations to natural disaster relief are used to guidethe identification and application of these futuretechnologies. The technology areas under consider-ation are divided into two areas: (a) DevelopmentComponents (technical areas including Mobile Com-puting and Augmented Reality, Ubiquitous Surveil-lance and Automated Reasoning, Event Model DrivenArchitectures, and Self-Healing and Self-ManagingSystems), and (b) Use Components (considerationsthat affect adoption of technology including M&SSocial Graphs, The Paradox of ‘‘Choice and Budge,’’Mashup Software, and fast, inexpensive, simple, andtiny (FIST), Cloud Encapsulation, and ‘‘Everything isa Game’’).
Supporting task: public outreach. Implied missions ofthe LVCAR-I project are to inform the M&Scommunity of project activities and where possibleget the community involved, and at the earliestopportunity provide access to the project’s products.The project team examined the realm of possibilities tomeet the various aspects of this mission and decidedthat it was best to take a three-pronged approach andengage the M&S community through (a) M&Sforums, (b) working groups, and (c) electronic andprint media.
The M&S forums include presentations at theNational Defense Industrial Association (NDIA) Sys-tems Engineering Conference, NDIA M&S Congress,Simulations Interoperability Standards Organizationevents, and National Training and Simulation Associ-ation’s Interservice/Industry Training, Simulation andEducation Conference (I/ITSEC). These opportunitieshave provided access to a variety of special use groupswithin the M&S community, and there are plans tocontinue using these opportunities as they arise.
Because of the growing emphasis on LVC simula-tion constructs within the DoD, there are numerousprograms and projects addressing training, analysis,testing, and acquisition requirements. Having relatedactivities opens the possibility for these parallelprograms to provide mutual support but also assumesthe M&S community is cognizant of emergingdevelopments. To improve community situationalawareness, the program manager for LVCAR-Iinitiated an LVC Interservice Working Group(LVC-IWG) to provide a forum where the leaders of
these various programs could share information aboutwhat is being undertaken and look for opportunities toleverage each other’s work. In addition, the LVCAR-Iproject has sponsored numerous special interestworkshops to solicit input to the various projectsubtasks.
Finally, this project is providing informationthrough articles and a Web site. This article is anexample of print media use, and through thesponsorship of Joint Forces Command HarmonieWebthere is a repository for publically released materialfrom the LVCAR-I project (harmonieweb.org) underthe work group ‘‘MSCO HLT SC2 LVCAR-I.’’
Next stepsThe initial commitment of funds for the LVCAR-I
project covered a 24-month period of performance.Since inception, a great deal of information has beengathered and analyzed. As with many efforts, werapidly discovered the more we learned led to logicalsteps for future work that needs attention. Withoutlosing sight that the goal is to improve LVCinteroperability by providing practical tools andpragmatic approaches to the problem, the project willhave follow-on efforts. Planning for FY11 and FY12includes the use of test beds, design of software,initiation of standards, and continued sharing oflessons learned.
ConclusionFrom the previous material, it is easy to see that the
LVCAR-I is an ambitious project from both atechnical and managerial standpoint. While havinginteroperability as the focus of the project provides aunifying goal and eases some management aspects,there are a number of ways to approach that problemset that add numerous levels of complexity. Thefunctional area approach that underlies the projectmanagement is recognition that decisions and adoptionof technical solutions are not based solely on logic orcost analysis. Understanding the other factors thatrelate to the adoption of technology will improve theuse of the tools developed through LVCAR-I. In theend, interoperability and ultimately support to thewarfighter will improve. C
DR. GARY W. ALLEN has worked in various aspects ofmodeling and simulation for the past 30 years. During hiscareer as a U.S. Army Officer, Dr. Allen was a member ofthe team that founded the Training Simulation Center forI Corps at Fort Lewis, Washington, in 1980. In 1989, hewas selected to commence a doctoral program at the
The Roadmap
31(3) N September 2010 363
![Page 11: Live, Virtual, Constructive, Architecture Roadmap Implementation … · 2011-05-15 · Live, Virtual, Constructive, Architecture Roadmap Implementation and Net-Centric Environment](https://reader034.fdocuments.us/reader034/viewer/2022042304/5ecf2925d085a11e0a5db0cd/html5/thumbnails/11.jpg)
University of Kansas in instructional technology, and afterreceiving his doctor of philosophy degree in 1989 he wenton to be the director of the Simulation Training Branch atthe U.S. Army Intelligence Center and School, FortHuachuca, Arizona. In 1992, Dr. Allen was inducted intothe Army Acquisition Corps and assigned as the projectdirector for the TACSIM Intelligence Simulation and waspart of the confederation that initiated the Aggregate LevelSimulation Protocol (ALSP). After retirement from theArmy, Dr. Allen joined federal service in 2002 as the U.S.Army liaison officer to the German Ministry of Defense forcooperative research and development. In 2009, hereturned to the United States to fill the position as theJoint Training Integration and Evaluation Center’s(JTIEC) project manager for the DoD Modeling andSimulation Coordination Office (M&SCO) High LevelTask S-C-2 ‘‘Live, Virtual, Constructive, ArchitectureRoadmap Implementation’’ program. Dr. Allen isa member of the Phi Kappa Phi National Honor Society,a 1999 graduate of the Army War College, and anAcquisition Corps Level III Certified Project Manager.E-mail: [email protected]
ROBERT LUTZ is a principal staff scientist at The JohnsHopkins University Applied Physics Laboratory in Laurel,Maryland. He has over 29 years of experience in thedesign, implementation, and evaluation of M&S systemsfor military customers. Mr. Lutz served as both a studyteam and expert team member during development of theLive, Virtual, Constructive Architecture Roadmap(LVCAR) and is leading several technical tasks in thecurrent LVCAR implementation phase. Mr. Lutz alsoserves as the U.S. Navy’s Broad Area MaritimeSurveillance (BAMS) Program M&S lead in the AirspaceIntegration (AI) area and leads several M&S standardsactivities within the Simulation Interoperability Stan-
dards Organization (SISO). He also serves as anExecutive Committee (EXCOM) member within SISOand is a regular guest lecturer in The Johns HopkinsUniversity Whiting School of Engineering. E-mail:[email protected]
DR. ROBERT RICHBOURG has been a member of theresearch staff at the Institute for Defense Analyses sincejoining the Institute of Defense Analysis SimulationCenter in 1996. Prior to that, he was an active dutyU.S. Army officer, serving the last 10 years of his career asthe director of the Office of Artificial Intelligence Analysisand Evaluation and professor of computer science at theUnited States Military Academy, West Point. Hissimulation experience centers primarily on the area ofenvironment representation. He has worked in thesimulation areas of autonomous behaviors and architec-tures, and he led the recently completed architecture studyfor the LVCAR effort. E-mail: [email protected]
ReferencesHenninger, A., et al. September 2008. Live, Virtual,
Constructive Architecture Roadmap (LVCAR) FinalReport. Unpublished report available from the Mod-eling & Simulation Coordination Office.
IBM. 2004. http://www.ibm.com/developerworks/webservices/library/ws-improvesoa (accessed July 16,2004).
AcknowledgmentsThe authors thank David Drake, Anita Zabek-
Jones, Jon W. Labin, Katherine L. Morse, RandySaunders, and John Schloman for their direct andindirect contributions to this article.
Allen, Lutz, & Richbourg
364 ITEA Journal