Internal HLA Compliance

Gerald Vasend
Logicon RDA
950 Orlando Ave.
Winter Park, FL 32789
gvasend@logicon.com

Abstract

The DoD High Level Architecture Management Plan states that the primary purpose of the HLA is to address interoperability and reuse across simulations. While the existence of an HLA will greatly improve interoperability between simulations , obstacles will remain due to varying degrees of differences between simulation architectures and between a simulation's Simulation Object Model (SOM) and a given Federation Object Model (FOM). All simulation infrastructures provide a set of common services that are required to perform simulation. These services include capabilities such as time and data management. While the types of simulation services provided are common, many implementations exist with varying degrees of incompatibility that will be difficult to solve exclusively through the use of HLA. Additional complexities exist related to the management of the FOM and each SOM. The HLA states that a simulation must provide access to its SOM. This will require the use of translation software to convert between the Federation Object Model and the simulation SOM. Support for this capability in the most generic interpretation of this rule is expensive and must be maintained over time as the Federation and simulations evolve.

This paper proposes an approach to improved Federation interoperability by using an architecture that supports internal HLA compliance by using the HLA RTI as a distributed simulation kernel. Thus, while HLA does not place requirements on a simulation's internal architecture, in cases where the HLA RTI provides adequate functionality and performance for a proposed model development, the HLA RTI can serve as the model's simulation kernel. Additional capabilities required for a simulation kernel but not provided by the RTI are described. The paper also describes a capability that allows both the SOM and FOM to be represented electronically within the simulation framework and provides translation services between the SOM and FOM through the use of a FOM/SOM Manager. Finally, the appropriateness of the HLA as a simulation kernel and the value of internal HLA compliance are addressed. Additional HLA capabilities that improve HLA applicability as a simulation kernel are recommended.

Benefits to the proposed approach include cost savings and improved interoperability. Given that a future model developer wishes to build a new model and the HLA RTI's performance characteristics are adequate to meet the model's requirements, the developer will not have to build a simulation kernel. The simulation kernel would be provided in the form of the HLA RTI as a GOTS product. The HLA RTI will provide critical capabilities such as time and data management and communications. Since the kernel is based on the RTI, interoperability with HLA will be automatic and minimal translation services will have to be developed

1. Background

The DoD High Level Architecture Management Plan states that the primary purpose of the HLA is to address interoperability and reuse across simulations. While the existence of an HLA will greatly improve interoperability between simulations , obstacles will remain due to varying degrees of differences between simulation architectures and between a simulation's Simulation Object Model (SOM) and a given Federation Object Model (FOM). Even when starting from an identical set of requirements, many implementation paths are possible leading to different solutions with varying degrees of interoperability. In general, increased compatibility between internal simulation architectures should lead to improved interoperability at a lower cost. It is also probable that identical simulation architectures would lead to maximum interoperability at the lowest cost. This assumes that the architecture is able to satisfy each simulation system's requirements. The objective of this paper is to explore issues associated with this common architecture.

In developing a common architecture that can operate in an HLA federation, one must trade-off several competing issues. The most basic trade-off is meeting the requirements of a simulation's user versus Federation requirements. A simulation developer must have the freedom to evolve the simulation to meet the simulation user's requirements. At the same time, the simulation has to be able to interoperate seamlessly with the larger Federation to meet its requirements. A common architecture that can satisfy both internal and external interoperability must be able to provide flexibility to meet both sets of requirements.

These trade-offs are currently being investigated in both WARSIM 2000 and the JSIMS Domain Engineering task. In JSIMS/Service Simulations, the desire is to develop an architecture that can meet the needs for a diverse set of users that include joint and service specific training audiences. This results in numerous technical and programmatic complexities. The solution to this issue in the past has been to interoperate stovepiped simulation systems via the Aggregate Level Simulation Protocol (ALSP). This approach tended to be optimized towards the individual simulation user and not the Confederation user. The individual simulation systems were afforded maximum independence but entailed high cost and poor interoperability/reuse. With JSIMS, the intent is to provide a simulation capability that provides improved flexibility to meet a diverse set of users. For example, WARSIM 2000 must be able to train a battalion level commander and staff. This requires fairly high resolution models. On the other hand, JSIMS must be able to train at the CINC level requiring much lower resolution. The JSIMS/Service Simulation architectures must be able to deal with these types of wide ranging requirements that have impacts on many areas including performance and operational requirements.

In order to investigate the feasibility of implementing internal HLA compliance it is first necessary to assess the possible motivations for interoperability and its ultimate objectives. Once we understand the objectives of interoperability we can then investigate what capabilities should be provided by this common architecture. The primary stated purpose of HLA is to support interoperability. Interoperability can take several forms. In its most common form, interoperability is the ability to exchange and process information between systems. Reuse libraries could be considered one form of interoperability. In this case, compiled procedures can be interoperable from one system to the next. In the M&S community when we speak of interoperability it is assumed that it is a distributed interoperability between simulation systems in the spirit of DIS, ALSP and HLA. At least in practice, these protocols have always assumed a distributed system. Therefore, when considering interoperability objectives one should also consider the distributed nature of the problem.

Reasons to interoperate/distribute:

  1. Model interoperability/reuse. For many, if not all, domains, this is a compelling reason for interoperability. It is also an interoperability objective that does not require distributed processing.
  2. Performance. Enhanced performance through the use of distributed processing may be a primary or secondary goal. This is the most difficult goal to realize. In order to achieve this goal it is important to have a "cooperative" federation. A cooperative federation is one where the federation problem space can be distributed among the federation resources with the allocation based on maximum performance. Analytical simulations are a good example of this. The primary reason an analytical simulation would use distributed simulation would be to increase performance. Reuse through HLA would only be viable if HLA either did not hurt performance or improved performance.
  3. Distributed components. The virtual community has an obvious need to distribute, since each simulator is running on distributed pieces hardware.
  4. Inter-domain interoperability. This interoperability objective would include such areas as C4I interoperability. The assumption here is that, in general, we don't want to reengineer simulations so that they are an extension of a C4I system, or vice versa. This implies that we will have two separate systems and that need to interoperate.
In assessing a common internal simulation architecture in an HLA Federation, the line between external interoperability and internal interoperability becomes fuzzy. In order to have a common architecture, it must support not only external interoperability objectives but must also support the simulation system's internal interoperability objectives. For the purposes of this paper, the objectives of the common simulation internal architecture are:
  1. Internal and external interoperability. The objective here is to lower the cost of interoperability. Interoperability includes interoperation with distributed components internal to the system and interoperation with external systems.
  2. Performance. The common architecture must meet system performance requirements. The architecture should support cooperative federation features such as load balancing.
2. Approach/Issues

The proposed approach to improved interoperability at a reduced cost is to evolve to a common internal simulation architecture for a limited set of simulation applications, based on the High Level Architecture. In order for HLA to support this, one cannot assume HLA as a constant. HLA must evolve to provide sufficient capabilities to allow it to be used internally.

The stated purpose of HLA is to allow interoperability between dissimilar systems. As a policy, HLA compliance is levied as an external interoperability requirement. Internal HLA compliance is not levied as a requirement. However, for some applications, it is advantageous to "exploit" HLA compliance by using the HLA as the starting point for the system architecture. The proposed approach to applying HLA compliance to the internal system architecture is based on the following items:

  1. Simulation Execution Design. A specific SOM design process should be developed to maximize interoperability with the FOM design process. This includes processes and products.
  2. Infrastructure. A common infrastructure based on the RTI. Ideally HLA provides all of the infrastructure capabilities. Additional infrastructure capabilities not provided by HLA are required. These include support for private federations, cooperative federation services, translation services and additional RTI capabilities.
2.1. Simulation Execution Design

Applying HLA to the internal structure of a simulation not only includes the use of the RTI software but also some aspects of the Federation development process. As the simulation development process matures it should be possible to reduce simulation development cost and risk by applying a process that captures the unique aspects of simulation software development. However, it is also true that a given simulation development process may not be appropriate for all types of simulations but could be applied to a given simulation domain. The main purpose of integrating the Simulation Execution Process with the Federation Execution Process is to ensure maximum interoperability between processes, data products as well as the simulations.

Figure 1. FOM/SOM Database

In order to reduce the overall cost of the SED/FED process, a common set of products should be interchangeable between simulation and Federation development. In addition, these products should be recorded in an electronic format that can be reasoned upon. For example, the current table OMT format is fine for documentation but is not well suited for algorithms that can process FOM/SOM information. One approach would be to store the information in a Relational Database, as depicted in Figure 1. This not only lends itself to automation but also eases data sharing between FOMs and SOMs.

2.2. Private Federations

Figure 2. Private/Public Federation

Private Federations will provide a simulation developer increased flexibility in meeting the customer's requirements while at the same time supporting interoperability with the Federation at a reduced cost.

An important aspect of the proposed application of HLA is the concept of Private Federations, depicted in Figure 2. The concept of an Private Federation is analogous to scoping rules in many higher order languages. An important construct used in Software Engineering is the concept of "data hiding". Using this approach we can create something called Private and Public Federations. The primary benefits of this construct is that we can control the visibility of SOM to the Federation. In C++ verbiage we can have Public and Private parts of the SOM. The Private portions of the SOM can be modified without affecting the Federation. This is very important because it allows a given simulation system to have the freedom to use HLA internally without forcing it to conform to a given FOM. This capability will allow the developer increased flexibility in meeting the customer's requirements while at the same time supporting interoperability with the Federation at a reduced cost.

The private part of a Federation consists of that portion of a SOM that is not visible to the Federation. This includes classes, attributes and interactions. Objects that are private appear in only the PF. Objects that are public are visible to both the private and public Federation. The same is true for attributes and interactions. Public objects may have private attributes. In addition, private interactions may occur between two public objects projected from a common PF. Using this approach, if it is decided that a private object, attribute or interaction is needed by the Federation, it's declaration is changed from private to public. This is preferably a dynamic capability but could be an exercise declaration or worst case, a compile-time declaration.

2.3. Cooperative Federations

A Cooperative Federation allows a simulation developer to compose a Federation where Federates operate synergistically to maximize performance.

The performance of the HLA RTI is a critical factor in its application as a simulation executive. This includes not only an efficient RTI implementation, but also features that support the overall efficient operation of the Private Federation as a whole. In the past, federations have used a stovepiped architecture. In this type of federation, simulation models are run at a particular node because the federate at that node was responsible for that particular model. For example, all aircraft will be run in the Air Force simulation. This experience is reflected in the current HLA and ALSP services in that it is assumed that Federates are "sovereign." That is, the Federate generally has control over its own actions and generally does not take direction externally except for cases such as time management and requests to update attribute values. A distributed simulation, on the other hand, must be able to allocate simulation objects to available hardware resources with performance being the primary objective. This requires services that give explicit directions to Private Federate on what objects it should be simulating. This allows one to compose a Cooperative Federation where Federates operate synergistically to maximize performance.

2.4. FOM/SOM Manager

While the existence of an HLA will greatly improve interoperability between simulations, obstacles will remain due to varying degrees of differences between simulation architectures and between a simulation's Simulation Object Model (SOM) and a given Federation Object Model (FOM). The HLA states that a simulation must provide access to its own object model. This will require the use of translation software to convert between the Federation Object Model and the simulation SOM. Support for this capability in the most generic interpretation of this rule is expensive and must be maintained over time as the Federation and simulations evolve.

The FOM/SOM Manager is a capability that allows both the SOM and FOM to be represented electronically within the simulation framework and provides translation services between the SOM and FOM through the use of a FOM/SOM Manager.

An example of the FOM/SOM manger providing automatic translation between a FOM and a SOM is depicted in Figure 3. In this example, the FOM and SOM are represented in a Relational Database. Using additional table(s) that describe the mapping from one to the other, the FOM/SOM Manager can provide automatic translation between the two. In this case, the Federation uses radians to describe heading whereas the Federate uses degrees. The FOM/SOM will automatically be able to convert between the two. This concept could be expanded to support additional types of differences that may occur between object models.

Figure 3. FOM/SOM Translation

2.5. RTI Implementation Issues

Developing performance standards for RTI services will allow a simulation developer to design the simulation with sufficient information to develop overall performance requirements.

The performance of the RTI has a direct effect on the ability to use HLA internal to a simulation system. In domains such as training, real-time performance is a must. In the analytical domain, many runs of a given scenario is often required to provide confidence in the results. In this case, the performance of the simulation infrastructure has a multiplying effect on the end-to-end execution time for the experiment. In the case of WARSIM 2000 Domain Specific Software Architecture (DSSA), performance requirements are placed on component services. In order to use the RTI internal to a system such as this, it must be able to meet stipulated performance requirements. A possible approach to this issue is to develop performance standards for RTI services. This will allow a simulation developer to design the simulation with sufficient information to develop overall performance requirements.

Given the desire to exploit HLA internal to a simulation system, multiple time synchronization methods are required to allow HLA to be applied a wide range of simulation domains. Work is ongoing to support this capability in HLA. However, when one considers the application of HLA internal to a simulation system other issues arise. A given simulation system may have two time synchronization problems to solve: Local time management and distributed time management. HLA, in its present form, should be able to address distributed time management. One could make the argument that HLA is applicable only in a distributed sense. However, since the primary purpose of applying internal HLA compliance is to achieve model composability, it is still advantageous to use an implementation of HLA that is optimized for operation on a single host. This could be especially useful for the analytical community since they would typically distribute the simulation only if it resulted in significantly improved performance. Without this capability, the simulation developer is forced to provide a separate local time management mechanism.

3. Conclusions

3.1. Applicability of Internal HLA Compliance

The ability to use a common internal architecture across multiple simulation systems is desirable. It can improve interoperability and lower the cost of interoperability. In addition, reusability across simulation systems would become easier. The use of the HLA as that internal architecture is possible. However, the current state of HLA is probably not sufficient to support internal simulation capabilities for many applications. Additional custom capabilities are required to supplement HLA. Further evolution of the HLA is required to more completely address internal simulation requirements. Additional research into highly composable Federations is required to fully understand how to create a common architecture that can flexibly support a wide range of simulation applications.

3.2. Benefits

The benefits of using an Internally HLA Compliant architecture can be described in terms of the "HLA rules". Each Federate must conform to these rules. By using an internally compliant architecture, conformance to the "HLA rules" will be simplified as follows:

Rule 1: Federations must have an HLA Federation Object Model (FOM).

Benefit: Using this approach, the OMT becomes the basis for designing the simulation's object model. By integrating SED and FED processes and products, no additional work is required. Data can be imported directly from the SOM into the FOM.

Rule 2: All Federates must have an HLA Simulation Object Model (SOM).

Benefit: Same as rule 1. However, additional capabilities must be provided to maintain both a FOM and a SOM. In effect, the SOM becomes the simulation's internal FOM. This capability is provided by the proposed FOM/SOM Manager.

Rule 3: All object representation occurs in the Federates, not in the Runtime Infrastructure (RTI).

Benefit: This rule is neither helped or hindered by the approach.

Rule 4: Data exchange among objects represented in federates occurs via the Runtime Infrastructure (RTI).

Benefit: Since the RTI is the simulation engine, this is automatic. It occurs for both public and private objects subject to scoping rules.

Rule 5: Federates must interact with the RTI in accordance with the HLA Interface Specification.

Benefit: Same as 4 with the addition that the simulation must be tested against the HLA Interface Specification and its SOM. Reusable FOM and SOM test procedures and tools can be applied.

Rule 6: An attribute of an object can be owned by only one federate at any given time.

Benefit: Same as 4.

Rule 7: Federates must be able to export any attributes of internal objects and exercise any internal object interaction externally.

Benefit: This capability can be provided by the proposed FOM/SOM Manager or HLA support for Private Federations.

Rule 8: A federate must be able to either own or reflect any object or attribute it represents internally and to transfer/accept ownership of any of these objects/attributes dynamically during a federation execution.

Benefit: Same as 7.

Rule 9: Federates must be able to vary the conditions under which they provide updates of public attributes of objects.

Benefit: Same as 7.

Rule 10: Federates must be able to manage local time in accordance with federation requirements.

Benefit: Same as 4.

3.3. Recommendations

In order to improve the ability of the HLA to support its use internal to a simulation, research and expansion of HLA in the following areas are needed:

Topic Recommendation Rationale
Private Expand HLA to support Private Lack of support for Private
Federation Federations. Federations force developer to go public with HLA or to use custom protocols and software.
Cooperative Federation Expand HLA to support Cooperative Federation Services Distributed simulations must be able to meet performance requirements.
HLA Performance Establish performance standards for RTI services Published performance standards will reduce risk for Federate simulations and the Federation as a whole.
FOM/SOM Formats Create FOM/SOM OMT data in formats that lends itself to automated processing. Improved interoperability at a lower cost.
RTI Implementation Develop more sophisticated RTI implementations that can meet a wider range of simulation requirements. An RTI that cannot meet internal simulation requirements forces custom solutions. The RTI may not be able to meet all requirements of any conceivable simulation but by being usable for a greater number of simulations will improve interoperability and reduce cost.

3.4. Summary

The High Level Architecture is an evolving concept. The next step in the maturation of HLA should address evolution to increased compatibility among internal simulation architectures. This process must recognize unique simulation capabilities that have been developed by different simulation domains. As this process occurs, interoperability will improve and its associated cost will decline. In order to achieve this, additional research is required. Applying HLA internally to production systems is still risky at this time. However, the long term goal of Internal HLA Compliance is desirable and will ultimately provide significant benefits.

References

Defense Modeling and Simulation Office, High Level Architecture Object Model Template, version 0.1, 17 July 1995.

Defense Modeling and Simulation Office, High Level Architecture, Interface Specification, version 0.3, 15 January 1996.

About the Author

Gerald Vasend is the Exercise Support System Concurrent Engineering Team Lead for WARSIM 2000 and a member of the JSIMS Domain Engineering Team. He is also the Logicon RDA Office Manager for the Logicon RDA Orlando office. Gerald has more than 14 years of experience in developing analytic, training and hardware-in-the-loop (HITL) simulations. His research interests includes simulation technology and application of simulations to real world problems.


Postscript Version