A Framework-based Approach to HLA Federate Development

Kevin Cox
John Hopkins University / Applied Physics Laboratory
Johns Hopkins Road
Laurel, Maryland 20723
kevin.cox@jhuapl.edu
(240) 228-3556
Keywords:
High Level Architecture, Tools, Simulation Framework, Code Generation, C++
ABSTRACT: As development of new models or reuse of existing models entails a significant commitment of
resources to achieve HLA compliance, there is a great need for tools and techniques that simplify the process of
creating HLA federates. This paper describes an approach that enhances the productivity of HLA federate
development through framework-based automation and improves software quality through reuse.
The approach utilizes a layered architecture for target federates. Successive layers include the RTI, an object-model-
independent layer providing a simulation framework for federates, an object-model-specific layer providing natural
representation of object model elements, and an application or simulation layer in which simulation behavior is
implemented.
A cross-platform, dynamically linked, C++ class library called the HLA Foundation Class (HFC) library provides
the simulation framework in much the way the well-known Microsoft Foundation Class (MFC) library provides a
framework for Windows applications. A simple development tool automates the generation of source code at the
object-model-specific layer by mapping object model content to C++ classes, similar to the way a CORBA IDL
compiler maps IDL to language-specific constructs. Source code at this layer may be archived in an Object Model
Source Library (OMSL) and shared among many or all of the federates participating in a federation. The classes in
such a library may be extended at the simulation layer to implement the simulation behavior unique to a specific
federate; these extensions may then be plugged into the simulation framework provided at the framework layer.
1. Introduction
The Federation Development and Execution Process
(FEDEP) [1] spells out a tailorable, generalized process
for the development of HLA federations. Supporting
papers emphasize the important role tools [2,3,4] and
tool architectures [5] have to play within this process,
particularly with respect to the development of HLA
Federation Object Models (FOMs). However, much of
the literature discusses the design and implementation of
federate software in only general terms; that is, few
guidelines or tools are specified for those designing and
implementing simulation source code in accordance with
the system (i.e., federation) specification documented in
upstream workproducts.
Although the development of a Federation Object Model
(FOM) represents much of the work involved in
establishing a federation, experience has shown [6] that a
significant amount of work remains in developing and
integrating federate software once a FOM has been
developed. For this reason, federate software designers
and implementers require additional tools and techniques
to reduce development costs, minimize time-to-delivery,
and enhance software quality.
This paper describes a project conducted at the Applied
Physics Laboratory (APL) that applies a technique
involving software frameworks supported by automated
tools to HLA federate development. The importance of
object-model independence in such frameworks is
emphasized, as well as the need for dynamic
representation of object model elements at run-time. The
paper proposes a method of structuring HLA federate
software using a layered architecture, such that software
reuse among the federates participating in a federation
can be maximized.
2. Motivation
In 1997, APL conducted a Naval Surface Fire Support
(NSFS) HLA distributed simulation that included sixteen
federates developed by five separate software teams [6].
A federation comprised of new and legacy models was
developed and executed on a distributed combination of
Sun Solaris, SGI IRIX, and Windows NT platforms.
During the course of the project, the interface
requirements imposed on federates by the Run-time
Infrastructure (RTI) accounted for a far larger proportion
of overall development effort than originally anticipated.
Software developers involved in the project faced a
relatively steep learning curve in utilizing the RTI
library, and found RTI programming to be tedious and
error-prone. RTI requirements therefore diverted the
attention of federate developers from the federation
problem domain to RTI-specific technical issues, greatly
slowing overall development progress.
While the RTI provides a coherent Application
Programmers Interface (API) that directly reflects the
HLA Interface Specification [7], it leaves management of
federation state to developers. For example, the RTI
notifies a federate when a new object has been registered
by a remote federate, and when the attributes of that
object are updated, but provides no assistance in tracking
that object or maintaining its state beyond providing an
object ID by which the object is referenced. This is just
one of many examples of the kinds of federation state
information that virtually all federates are required to
maintain. The large degree of common functionality
required of federates that is not provided by the RTI sets
up a situation in which developers tend to independently
implement source code performing essentially the same
purpose.
There are considerable disadvantages to duplicating
source code in this way. Certainly, the most glaring
drawback is the time wasted when individual developers
or distinct teams reinvent the wheel. But the loss of
precious development time goes beyond that incurred by
writing duplicate source code. When different solutions
are found for common problems, there exists greater
potential for federate incompatibilities during
integration. For example, without a shared base of
source code, different approaches to federation-critical
functions, such as marshalling of data sent among
different platforms, jeopardizes successful
interoperability. The discovery of such incompatibilities
late in the development cycle results in unnecessary, and
sometimes significant, overruns of schedule and budget.
Furthermore, failure to use a shared implementation of
common federate functionality among federation
participants means missing an opportunity to avoid
revisiting common problems. During APLs 1997 NSFS
project, we found on many occasions that nearly identical
software bugs recurred in several different federates
throughout the course of federation integration.
Although some code was shared, a great deal of time
could have been saved if a more extensive common
framework of software was shared among all federates.
Many software defects could then be fixed once in the
framework rather than in each federate independently.
Based on the experiences described above, an APL IR&D
project entitled Rapid Federate/Federation
Development was proposed for FY98 with the goal of
reducing the time and effort required, given an HLA
object model, to construct functional HLA federates. The
project objectives include:
Minimize the level of HLA understanding required
of federate software developers and thereby free them
from the implementation of common HLA
functionality to concentrate on the simulation
behavior of their particular federates;
Encapsulate the programming complexities of the
RTI and minimize the requirements imposed on
federate software by simplifying interoperability
mechanisms and, where appropriate, providing
default functionality;
Provide a set of general simulation services
implementing functionality that is required by
typical federates; and
Automate the process of representing HLA object
models in source code and of generating skeletal
federate code.
The approach prescribed by the project involves:
Development of a software framework designed to
provide a layer of abstraction between the simulation
modeler and the intricacies of the RTI; and
Development of a supporting tool designed to assist
the developer in customizing framework components
by mapping object model elements to source code
and by generating federate shells.
This paper details this approach as implemented by the
projects end products. First, however, a more in-depth
discussion of software frameworks, the problems they
solve, and their suitability for automation is in order.
3. Software Frameworks and Automation
3.1 What are Software Frameworks?
Software frameworks are tailor made to solve the kinds of
problems experienced during APLs 1997 NSFS project
as described in the previous section. Whenever a
situation exists in which an entire class of software
shares a need for common functionality or a common set
of services, that commonality may be implemented in a
sharable software framework. To be more precise, a
software framework can be defined as follows
(underscores are the authors emphasis) [8]:
A set of cooperating classes that makes up a
reusable design for a specific class of
software. A framework provides architectural
guidance by partitioning the design into
abstract classes and defining their
responsibilities and collaborations. A
developer customizes the framework to a
particular application by subclassing and
composing instances of framework classes.
In other words, a framework is an object-oriented code
base, typically distributed as a sharable software library,
that provides an architectural starting point for
developers of software falling within a particular
application domain. The application domain of interest
in our case is HLA federate software. Regardless of the
software domain, new framework-based applications are
developed by:
Exploiting the common services provided by the
framework; and
Extending the framework to provide the
functionality unique to the application.
If designed to be configurable, flexible, and non-
intrusive, software frameworks can also be used to
enhance or provide a new dimension of functionality to
existing legacy software.
The Microsoft Foundation Class (MFC) library provides
a well-known example of an effective software
framework. The MFC is a C++ class library that
provides a high-level interface to Windows programming
while encapsulating the lower-level Win32 API. It
provides a great deal of functionality typically found in
Windows applications, such as document management
and management of distinct views on document data,
and provides an object-oriented interface to complex
tasks involving database access, communication across
networks, and compound document management. Using
the MFC, Windows applications are built by specializing
components found in the MFC framework, such as the
CDocument and CView classes, to meet application
requirements. Once these framework components are
specialized to provide application-specific functionality,
they are plugged into the MFC framework much like
computer cards are plugged into a computer motherboard
to specialize the behavior of a computer by adding sound
or video capability.
3.2 Benefits of Software Frameworks
The benefits offered by software frameworks can be
summarized in one word: reuse. Through the reuse of
proven software providing higher-level services while
encapsulating lower-level details, we achieve substantial
gains in productivity across the development of multiple
applications in the software domain supported by the
framework. We avoid duplicating code from application
to application, and all applications benefit from the
correction of framework bugs discovered within and the
enhancements inspired by any one of the applications
using the framework. Indeed, software reuse is capable
of reducing time to market by two to five times, reducing
defect density by five to ten times, reducing maintenance
costs by five to ten times, and reducing overall
development costs by fifteen to seventy-five percent [9].
Distributing framework functionality in dynamically
linked libraries (DLLs) or shared libraries (sometimes
called dynamically shared objects or DSOs) provides
additional benefits to developers and end-users. Such
libraries allow client applications to postpone the process
of linking to library functionality until each time the
application is actually run. Therefore, dynamic libraries,
which can be thought of as sharable application
components, can be upgraded independently of all
applications that use them. Thus, for example, Microsoft
can provide an update to the MFC library, and in one fell
swoop, countless applications can benefit from bug fixes
and enhancements without having to be recompiled,
relinked, or even reinstalled. This illustrates the power
frameworks have in simplifying application maintenance
and deployment.
3.3 Supporting Software Frameworks with
Automated Tools
The very nature of the process of developing framework-
based software cries out for automation. Because
application components designed to plug into a
framework are required to abide by framework interfaces
and typically have a pre-determined structure, their
construction can often be considerably aided with the
help of an automated development tool.
Once again, Microsofts MFC framework provides an
excellent example. Rather than requiring developers to
hand-code framework extensions, the Visual C++
integrated development environment (IDE) provides a
wizard that produces a customized, MFC-based
application shell complete with features such as print
preview, a toolbar, and a multiple document interface
(MDI). The user then adds application-specific
functionality to the code generated by the wizard. Note,
however, that a great deal of high-level functionality,
such as print preview, is provided for free by the
framework, and does not have to be programmed anew
into each individual application.
4. Application to HLA Federate
Development
Now that weve described the benefits software
frameworks offer application domains in general, its
time to focus on the potential frameworks have in
supporting HLA federates in particular. Following this
discussion, we characterize the HLA Foundation Class
(HFC) framework created during APLs FY98 IR&D
project as an example of a software framework capable of
supporting a variety of HLA federates. We conclude this
section with a description of the automated development
tool built to support HFC-based development.
4.1 Benefits for HLA Federate Development
The workproducts produced during upstream FEDEP
development phases, such as the Federation Conceptual
Model (FCM) and the Federation Object Model (FOM),
provide invaluable input to those developing HLA
federate software. Yet the materialization of the
federates envisioned during the FEDEPs Federation
Design phase often involves an arduous software
development process in which existing legacy
simulations are coerced into supporting the FOM or
federates are created more or less from scratch. In either
case, developers find that productivity is slowed by the
necessity of interfacing with low-level RTI mechanisms.
The extensive requirements imposed on all federates by
the RTI provide excellent opportunity for constructing a
software framework that maximizes reuse among and
simplifies development of HLA federates.
The RTI library provides the federate a basic interface to
RTI services and specifies an abstract interface that the
federate must implement. The classes provided by the
RTI library are a straightforward mapping of the services
defined in the HLA Interface Specification [7], but they
provide no higher-level functionality that might make the
job of building a federate easier. For example, operations
are available to register an HLA object, update its
attributes, discover a remote object, reflect a remote
object's attributes, etc., but no functionality is provided to
assist in representing an HLA object (local or remote),
tracking whether or not other federates have subscribed
to a local object's attributes, determining whether an
HLA object attribute value needs to be updated due to a
change since the last update, etc. This is not a
shortcoming of the RTI library; rather, it is a necessity
since providing additional support for meeting the
responsibilities of an HLA federate involves making
assumptions about the mechanisms used to meet those
responsibilities.
A higher-level software framework may be built on top of
the RTI, however, to offer additional capability. Such a
framework provides the following benefits:
Reduces time-to-delivery;
Reduces development cost;
Hides much of the complexity of interfacing with the
RTI;
Allows the federate developer to focus on the
simulation domain rather than on meeting HLA
requirements;
Offers higher-level functionality not found in the
RTI library;
A reusable library/framework has a broader user test
base (which tends to result in more reliable code);
and
Federates built using a reusable library/framework
can take advantage of bug fixes and enhancements
discovered or inspired by other federates.
The use of a software framework therefore involves a
tradeoff (as is the case in using any software framework)
of flexibility versus functionality and reduced complexity.
In other words, a degree of freedom in design is
sacrificed for existing functionality, the encapsulation of
complexity, and the associated productivity gains. An
objective of a software framework then is to maximize
functionality while minimizing the constraints imposed
upon software built with the framework as a foundation.
Such considerations played a large part in the design of
the HLA Foundation Class (HFC) framework.
4.2 The HLA Foundation Class (HFC) Framework
The design and implementation of a generic software
framework supporting federate development constitutes
the first phase of the aforementioned APL FY98 IR&D
project. The efforts expended during this phase of the
project resulted in a flexible framework implemented in a
dynamically linked C++ class library called the HLA
Foundation Class (HFC) Library. The library is so
named to underscore the fact that it supports HLA
federate development in a way analogous to Microsofts
MFC support of Windows application development.
Based on design patterns [8], the HFC Library targets the
Windows NT, Solaris, and IRIX operating systems and is
designed to work with version 1.0.3 of DMSOs RTI.
Note that similar software frameworks have been
described in the literature [10,11].
4.2.1 HFC Framework Components and Services
During APLs 1997 NSFS project, it was found that
many federate developers implemented similar
functionality in slightly different ways. From this it was
determined that several areas of functionality were
common to many federates and could be implemented
once in a common software framework, thereby
leveraging the experience gained during that initial
effort. Some examples of the areas of functionality
provided by the HFC framework are:
A configurable simulation driver
Any federate must have some mechanism in place
that allows the simulation to advance in time in a
way that is compatible with all simulation
components and algorithms and all systems with
which the simulation collaborates. The HFC library
provides a way to plug in a simulation driver
responsible for coordinating time advance in
whatever way makes sense for the federate under
development. As simulation drivers are modeled
after the Strategy design pattern [8], they must
conform to interfaces expected by the framework
(this is standard for specialized framework
components). For example, if a federate needs to
wait for an input signal from a hardware-in-the-loop
(HWIL) component before advancing in time, a
simulation driver designed to accommodate this can
be used in place of default drivers provided by the
framework. If no specialized time advance
mechanism is needed, default simulation drivers
suitable for simple time-stepped and discrete-event
simulations may be used. Simulation drivers may
synchronize federates with wall-clock time and may
utilize the RTI Time Management services, which
are designed to synchronize time advancement
among the federates in a federation.
Support for representation of object model elements
The RTI library provides little support for
representing the objects, interactions, and complex
data types defined in a FOM. Integer handles are
used to refer to object and interaction classes, and
data values are represented in raw character buffers.
These low-level programming constructs are far
removed from the vocabulary of the problem domain
and tend to hinder federate development through
tedium. As described in the section entitled Object
Model Representation, The HFC library defines
classes that may be specialized to intuitively
represent object model elements in a type-safe way.
The resulting classes offer a higher level of
programming abstraction much closer to the
federates problem domain.
Local proxies for remote federation objects
When the RTI notifies a federate that a new object
has been registered by a remote federate, it provides
a handle indicating the objects class and an object
ID uniquely identifying the object. The federate
must somehow internally represent the existence of
the object so that a) subsequent references to it by the
RTI will be understood, and b) the effect of the
object on the federates own simulation objects may
be computed. Here again is an example of a
common requirement imposed on federates by the
RTI, for which a single framework-level solution
may be provided. The HFC framework allows
remote objects to be represented by local proxy
objects, which store attribute values and other object
state information using the same intuitive
representations described in the previous bullet. In
this way, the attributes of remote objects can be
queried locally using an interface closely matching
the objects FOM class definition. This Proxy
design pattern [8] is commonly used in other
distributed object technologies as well [12,13].
Automatic updates and reflections of object attributes
Using natural representations of simulation objects,
the process of updating the attributes of local objects
and reflecting the attributes of remote objects
becomes much less of a burden to the federate
developer. HFC framework internals allow a
developer to update a simulation objects attributes
by simply invoking an appropriately named method
with a new value of the correct type as an argument.
Behind the scenes, the framework then passes the
attribute update to the RTI, and remote federates
subscribing to the attribute are notified. The federate
developer is no longer required to execute a three-
step process in which the attribute is first updated
locally, then stored in a raw character buffer, and
finally passed on to the RTI in an update request.
When an attribute of a remote object is updated, a
federate subscribing to that attribute is told by the
RTI to reflect the update. Reflecting attribute
values is another task nearly all federates must
perform and represents functionality suitable for a
software framework. The HFC framework obliges by
automatically storing updated attribute values in the
object proxies used to represent remote objects. In
this way, the federate developer is not bothered with
manually writing code to track the state of remote
objects, but can instead rely on the object proxies to
at any time hold current attribute values.
In addition to providing these and other services, the
HFC framework helps the federate developer avoid
common programming pitfalls associated with RTI
programming by providing proven solutions and
architectural guidance. Such pitfalls include:
RTI concurrency errors
Because the DMSO RTI is not reentrant, any
attempt to invoke RTI services while servicing RTI
events (e.g., while processing a received interaction)
causes a concurrency error that results in an
exception being thrown. This problem was
encountered multiple times during APLs 1997
NSFS project. The HFC frameworks encapsulation
of the RTI helps protect the federate developer from
making this mistake. All attributes updated and all
interactions sent while servicing RTI events are
queued until the earliest opportunity for successful
RTI invocation.
Time management through the RTI
RTI time management mechanisms can be tricky.
The HFC framework provides default algorithms for
initializing and advancing simulation time in
conjunction with the RTI; these algorithms are
completely customizable. Wall-clock time
synchronization is also facilitated in an RTI-
friendly way, and automatic handling of lookahead
for time regulating federates is provided.
Data marshalling
Data marshalling refers to the process of
manipulating exchanged data values as necessary to
ensure that different machine architectures interpret
those values in the same way. Without data
marshalling, the value of an attribute updated by a
federate running on a PC will be interpreted
incorrectly by a subscribing federate running on a
Sun workstation, for example. Since the DMSO RTI
expects to handle data values as raw character data,
regardless of the datas type, the responsibility of
marshalling data is left to the federate. Rather than
duplicating this functionality in all federates, the
HFC framework automatically and transparently
marshals data in a consistent way, enabling
interoperability among federates running in a
heterogeneous environment.
Additionally, the HFC offers services that are not directly
related to the HLA, but are generally useful to most
federates, including:
An event model
The HFC provides a useful event model, based on an
extension of the Typed Message design pattern
[14], in which federate developers may register
multiple event handlers for individual event types.
All event handlers are notified in a type-safe way
each time an event of the appropriate type (or sub-
type) occurs. The event register/notify paradigm
offers a convenient programming model for custom
simulation events as well as for RTI events like
object discovery and interaction receipt.
Data logging support
During execution most federates have a need to store
data to output files to log simulation events, errors,
and results. The HFC framework includes a data
logging utility that allows information to be logged
at different log levels. By specifying at run-time
the level of detail required in output files, an
execution of the federate can be configured to output
more or less data as required for debugging,
optimization, etc. The HFC framework itself uses
this tool to log information and errors related to
interacting with the RTI.
Initialization and data inputs
Typically, a federate requires initialization data to be
read from input files in order to correctly play out
the scenario desired for the execution. The HFC
provides a configurable parser that reads in
initialization files containing run-time federate
parameters such as the federate name, the name of a
federation to which the federate should join, time
management parameters, and so on. The parser can
be specialized to read in parameters and scenario
data as appropriate for the federates unique
requirements.
All of the services described above are merely
representative of the kinds of functionality suitable for
implementation within a federate software framework.
Certainly, many additional services can be conceived of,
and when deciding which services should be
implemented in a framework, the following litmus test
should be applied: if functionality is likely to be required
by the majority of HLA federates, implement it once in a
framework rather than in N individual federates. The
chief advantage in doing so lies in software reuse and
development productivity.
4.2.2 Object Model Representation
The manner in which a federate software framework
represents an HLA object model constitutes one of the
best measures of its utility. We now turn to a discussion
of object model representation in the HFC framework and
the notion of building federates using a layered
architecture.
The Federation Object Model (FOM) lies at the heart of a
federations plan for interoperability. The correctness
and intuitiveness with which a federate software
framework represents object model elements is therefore
paramount. Furthermore, because the effectiveness of
any framework is measured in part by the range of
applications to which it is applicable, a federate software
framework must be prepared to work with and represent
any FOM. In other words, a framework designed to
support federate development must be independent of any
particular object model.
A federate software framework may provide two
fundamental methods of representing object models:
static representation and dynamic representation. The
HFC framework supports both methods, and the choice
between them depends largely on the needs of individual
federates. Static object model representation may be used
when the object model is known at federate compile-
time, while dynamic object model representation is
useful for federates that are expected to work with object
models not known until run-time.
4.2.2.1 Static Object Model Representation
In this approach, the object classes, interaction classes,
complex data types, and enumerations of an object model
are all mapped naturally to C++ language constructs
conforming to framework interface expectations. Static
object model representation therefore requires full
knowledge of object model components at the time a
federate is built, i.e., at compile-time. Representing
object model elements in this way brings the federate
developer closer to the problem domain by providing
C++ classes modeled directly after object model
definitions. So, for example, a developer can work with
C++ classes like Tank and Ship, and attributes can be
set and queried with simple C++ member functions such
as setXVelocity() and getXVelocity(),
without worry of the low-level mechanisms by which the
RTI updates and reflects those attributes. By enabling
the developer to focus on simulation problems, rather
than burdening the developer with the distractions of
tedious RTI-related programming, productivity is
significantly enhanced.
Once a FOM has been mapped to HFC-compatible C++
representations, the resulting source code can be archived
in an Object Model Source Library (OMSL) that can be
shared by all federates participating in the federation. In
this way, duplication of effort is again avoided, and
compatibility among federate representations of object
model data is ensured. By serving all federates within
the federation, the OMSL acts as the upper layer in a
layered architectural programming model as depicted in
Figure 1. In this figure, federates A and B belong to a
federation supported by OMSL 1, and federates C and D
belong to a federation supported by OMSL 2. Each layer
provides functionality at its own level of generality, with
greater generality in the lower architectural layers and
greater specificity in higher architectural layers. Each
layer utilizes data required at its level of generality,
including Federation Execution Data (FED) and Run-
time Initialization Data (RID) at the RTI layer, object
model data and initialization parameters in the middle
layers, and federate-specific data at the federate layer.
The use of a layered architecture to partition application
responsibility in this way is an application of what has
been called the Horizontal-Vertical-Metadata design
pattern [15].
Run-time Infrastructure (RTI)
HLA Foundation Classes (HFC)
Object Model Source
Library (OMSL) 1
Federate A Federate B
Object Model Source
Library (OMSL) 2
Federate C Federate D
Metadata
Figure 1The HFC Layered Architecture
The adherence of OMSL classes to standard framework
interfaces means their implementations often take on
similar structures. As described in the section entitled
The HFC Automation Tool (HAT), this situation
provides an opportunity to automate the generation of
entire OMSLs from object model data.
4.2.2.2 Dynamic Object Model Representation
While effective and convenient for most federates, static
object model representation fails to support federates
required to work with object models unknown at
compile-time. This is often the case for federation
management federates and utility federates. A developer
should not be required, for example, to compile in
support for the object models of all federations in which a
data logger is to be run. Rather, a general utility such as
a data logger should be executable across many
federationseven federations based on FOMs developed
after the construction and installation of the utility.
Because certain classes of HLA federates require this
kind of dynamic representation of object models,
federate frameworks must support mechanisms allowing
the content of object models to be determined and
manipulated at run-time in ways that allow effective
participation in federations based on those object models.
The HFC framework provides a set of components
devoted to reading object model data from standard Data
Interchange Format (DIF) files at run-time and making
object model content available through intuitive, object-
oriented interfaces. This dynamic access allows federates
to perform operations based on object model data read in
at run-timepublishing and subscribing object attributes
and interactions named in the object model, for example.
Note that the requirement for both static and dynamic
object model representations stems from needs that have
analogues in other distributed object technologies. The
Common Object Request Broker Architecture (CORBA),
for example, defines a Static Invocation Interface (SII) to
object interfaces defined in CORBA Interface Definition
Language (IDL). Clients that have knowledge of a
CORBA objects interface at compile-time most often use
the SII to invoke methods on the object. Clients that do
not have knowledge of an objects interface at compile-
time, such as generic tools used to browse and activate
available object services, must rely on the Dynamic
Invocation Interface (DII), which enables the
determination and invocation of an objects methods at
run-time.
4.3 The HFC Automation Tool (HAT)
The second phase of the APL FY98 IR&D project under
discussion calls for the provision of a tool designed to
assist the federate developer during the process of
specializing HFC framework components. This effort
resulted in a Java application, called the HFC
Automation Tool (HAT) that operates on object model
data and user input to generate source code that can be
plugged into the HFC framework to provide the specific
behavior required by individual federates and federations
of federates. The tool is capable of generating code that
supports the developer in two ways:
Object Model Source Libraries (OMSLs) can be
generated automatically from object model elements
selected by the user. Any federate in a federation
supported by an OMSL can use OMSL classes to a)
provide object proxies for remote HLA objects, and
b) provide a base for derived classes that add the
simulation behavior exhibited by local HLA objects.

Federate shells, or skeletal federate code based on
the HFC framework, can be generated and
customized to rapidly bring a federate on-line in the
federation it supports.
4.3.1 Object Model Source Library (OMSL)
Generation
During APLs 1997 NSFS project, C++ classes used to
represent the objects, interactions, and complex types in
the FOM followed structural patterns that led us to the
idea of automatically generating such classes from HLA
object models [6]. This approach has been proposed by
others as well [10].
The generation of an OMSL begins with the importation
of object model data stored in the standard Data
Interchange Format (DIF). Because the tool is capable of
operating on DIF files, it fits into the prescribed HLA
tools architecture [5]. Once object model data has been
imported into the tool, the content of the object model is
displayed to the user in a simple hierarchical way. The
user may then use an intuitive wizard to select elements
of the object model for inclusion in an OMSL. Once an
OMSL has been so specified, a back-end source code
generator creates C++ source code representations of the
selected object model components. This source code is
then compiled into a library that can be shared across the
federation, as depicted in Figure 2.
FOM Tool
DIF
Data
HFC Auto
Tool
Fed 1
Fed 2
Fed 3
Fed 4
Object
Model
Source
Library
Figure 2Automatic Generation of Object Model
Source Libraries and Federate Shells
The content of an OMSL generated in this way is a direct
mapping of object model definitions and interfaces. Each
object class, interaction class, and complex data type
defined in the object model is mapped to a C++ class of
the same name. Object attributes, interaction parameters,
and complex type components are represented with
member objects that are accessed using straightforward
interfaces. Enumerated types defined in the object model
map naturally to C++ enumerations.
The process of automatically mapping an HLA object
model to C++ source code can again be compared to
strategies used in CORBA development. In CORBA,
object interfaces are clearly specified using a
programming language-neutral Interface Definition
Language (IDL), similar to the way federate interfaces
are specified using HLA object models. A developer
wishing to access a CORBA object from a particular
programming language compiles the objects IDL,
producing source code in the targeted language that
directly reflects the objects IDL interface. The HFC
Automation Tool (HAT) applies a similar strategy in
which federate interfaces, specified in object models, are
compiled into source code representations, though the
only language currently supported is C++.
4.3.2 Federate Shell Generation
In addition to generating the content of OMSLs, the HFC
Automation Tool (HAT) outputs source code for HLA
federate shells. These shells consist of classes, derived
from HFC framework classes, that together provide the
architectural bread board into which simulation objects
exhibiting the desired simulation behavior will be
plugged. The federate developer must then a) create the
simulation object classes, typically by adding simulation
logic to classes derived from OMSL classes, b) plug in
instances of these classes, and c) establish event handlers
to process simulation events. The result is a fully object-
oriented federate built on a layered architecture that
provides the infrastructural functionality common to
virtually all federates. By leveraging a reusable
framework that provides higher-level services and
embodies implementation techniques proven in prior
development efforts, we lighten the burden of low-level
RTI synchronization and significantly speed
development.
The manner in which the HAT generates a federate shell
based on the HFC framework is similar to the way
Microsofts Visual C++ IDE generates Windows
application shells based on the MFC framework. Like
Visual C++, the HAT provides wizards that allow the
developer to specify parameters that appropriately
customize the generated application shell. Similarly,
additional functionality is planned for the HAT that will
automate the process of creating and registering
simulation event handlers, much like Visual C++
automates the preparation of event handlers for
components such as ActiveX controls.
The automation capabilities of the HAT provide all
federate source code necessary for effective
interoperability with the federation through the RTI. The
tools automation and the HFC frameworks architectural
guidance therefore enable software design considerations
to begin with solving the simulation problem, rather than
the RTI problem.
4.3.3 Technique for Source Code Generation
The HAT employs a simple technique for source code
generation that warrants further consideration. The
component responsible for code generation is actually a
back-end utility capable of being controlled from either
the command-line or the HAT user interface. This
utility, implemented using Perls object-oriented
programming constructs, generates code based on DIF
files or on HAT files that contain DIF data supplemented
with additional directives stored in DIF-like syntax. For
each type of source file produced, the generator reads in a
template file and outputs a copy of the template files
contents, while replacing embedded Perl script with the
results of evaluating that script. During evaluation,
embedded script is provided access to Perl objects that
hold information about the object model element for
which code is being generated, thereby allowing
complete control over the manner in which object model
data is mapped to source code.
This technique of processing template files that embed
script within text that otherwise passes through
unchanged resembles Microsofts Active Server Pages
(ASP) technology, in which a web servers HTML pages
are sprinkled with embedded script to customize page
content according to the clients browser, database
content, etc. These template files are simply text files
that a user can modify to customize generated output as
necessary. This flexibility means generated code can be
made to conform more closely to the existing
architectures of legacy simulation software.
5. Summary
APLs experience with HLA federate software
development [6] has demonstrated that the process of
interfacing with the RTI a) is tedious and error-prone,
and b) often results in duplication of source code across
multiple federates. Software frameworks provide an
opportunity to capture the commonality that exists across
application domains. APL therefore developed a cross-
platform, C++ software framework, called the HLA
Foundation Class (HFC) framework, designed to:
Speed the development of federates;
Reduce duplicate implementations of common
functionality among federates; and
Improve the reliability of federate interaction with
the RTI.
The HFC facilitates federate development by providing
simulation services and enabling both static and dynamic
representations of HLA object model components.
Further, since framework-based development is generally
subject to automation, the HFC Automation Tool (HAT)
was created to support HFC-based federate development.
The HAT assists the federate developer by automatically
generating:
Object Model Source Libraries (OMSLs) containing
C++ representations of HLA object model
definitions; and
Federate shells that provide architectural bread
boards into which specialized simulation objects are
plugged.
References
[1] Defense Modeling and Simulation Office, "HLA
Federation Development and Execution Process (FEDEP)
Model, Version 1.2 Draft," 26 May 1998.
[2] Bouwens, C.; Scrudder, R.; Miller, R.; and Lutz R.,
"Object Model Development: Tools and Techniques,"
Simulation Interoperability Workshop, 9-13 March 1998.
[3] Scrudder, R. and Lutz R., "High Level Architecture
(HLA) Object Model Tool Development," Simulation
Interoperability Workshop, 8-12 September 1997.
[4] Lutz, R.; Hooks, M.; and Hunt, K., "Automation in
the HLA FOM Development Process," 15th DIS
Workshop, 16-20 September 1996.
[5] Hunt, K.; Dahmann, J.; Lutz, R.; and Sheehan, J.,
Planning for the Evolution of Automated Tools in
HLA, Simulation Interoperability Workshop, 3-7 March
1997.
[6] Baker, J.; Bowen, W.; and Harris, M., Lessons
Learned From Human-In-The-Loop HLA
Implementation, Interservice / Industry Training,
Simulation and Education Conference (I/ITSEC), 1-4
December 1997
[7] Defense Modeling and Simulation Office, HLA
Interface Specification, Version 1.2, 13 August 1997.
[8] Gamma, E.; Helm, R.; Johnson, R.; and Vlissides, J.,
Design Patterns, Elements of Reusable Object-Oriented
Software, Addison Wesley Publishing Company, 1995.
[9] Jacobson, I.; Griss, M.; and Jonsson, P., Software
Reuse, Architecture, Process and Organization for
Business Success, ACM Press, 1997.
[10] Graham, J.; Foscue, J.; and Cutts, D., HLA Object
Models as Software Object Models: An Approach to
Automatic Software Generation from HLA Object
Models, Simulation Interoperability Workshop, 9-13
March 1998.
[11] Blanger, J.; Fortier, P.; and Lam, L., Lessons
Learned from a Framework Approach to HLA-Compliant
Federation Development, Simulation Interoperability
Workshop, 9-13 March 1998.
[12] Microsoft Corp., The Component Object Model
Specification,
http://www.microsoft.com/oledev/olecom/title.htm,
October 1995.
[13] Object Management Group, OMG Formal
Documentation, http://www.omg.org/corba/.
[14] Vlissides, J., Multicast Observer = Typed
Message, C++ Report, SIGS Publications, Inc.,
November-December 1997.
[15] Mowbray, T. and Malveau, R., CORBA Design
Patterns, John Wiley & Sons, 1997.
[16] Sinex, C.; Kerchner, D.; Cox, K.; Basile, S.; Sellers,
W.; and Hindman, E., WLTAE: An HLA Federation for
Logistics and Warfighting Models, Simulation
Interoperability Workshop, 14-18 September 1998
Authors Biography
KEVIN COX is a software engineer at the Johns
Hopkins University Applied Physics Laboratory. He
holds a B.S. in Physics and Mathematics from Towson
State University and completes an M.S. degree in
Computer Science from the Johns Hopkins University in
Fall of 1998. Mr. Coxs interests lie in distributed
computing technologies and the application of these
technologies to distributed simulation. He has been
involved in numerous distributed simulation projects
conducted at APL.