Cart
0
Product
Products
(empty)
No products
To be determined
Shipping
$0.00
Total
Product successfully added to your shopping cart
Quantity
Total
There are 0 items in your cart.
There is 1 item in your cart.
Total products
Total shipping
To be determined
Total
Reduced price!
View larger
View larger
IEEE 1516.3
New product
IEEE 1516.3 2003 Edition, March 20, 2003 Recommended Practice for High Level Architecture (HLA) Federation Development and Execution Process (FEDEP)
More info
Description / Abstract:
Foreword
The High Level Architecture (HLA) has been designed to facilitate interoperability among simulations and to promote reuse of simulations and their components. The HLA is composed of three major components:
— HLA rules: A set of ten basic rules that together describe the general principles defining the HLA.
— HLA interface specification: A description of the functional interface between simulations (federates) and the HLA runtime infrastructure (RTI).
— HLA Object Model Template (OMT): A specification of the common format and structure for documenting HLA object models.
In an HLA application, any number of physically distributed simulation systems can be brought together into a unified simulation environment to address the needs of new applications. These types of environments are known as HLA federations. The HLA specifications together define an overarching framework for the construction and execution of federations.
Within the various government and commercial organizations that comprise the HLA community, many different approaches to project management and systems engineering are being used. Such practices, procedures, and methodologies have evolved over time based on how well they serve the different functional areas and user communities for which they are intended. Many of these approaches currently use modeling and simulation (MS) as a key enabler of certain functions, such as concept evaluation, testing, and training. However, a significant number of organizations adopting the HLA have not yet determined how to tailor their native management and engineering processes to take advantage of the HLA. For instance, while many in the analysis community have established procedures for non-runtime exchange of data from one simulation to another, the opportunities provided by the HLA for more dynamic exchange of data at runtime require that existing engineering processes be modified or augmented in order to take advantage of such opportunities. Even in communities in which distributed simulation is more commonplace (e.g., training), migration to the HLA generally requires some modification to existing management and engineering processes to capture the benefits offered by the HLA. As simulation users perform this migration, it is critical that guidance be available to orient new users to the specific set of tasks and activities necessary to develop and execute HLA federations.
This recommended practice describes the HLA FEDEP. The purpose of this recommended practice is to describe a generalized process for building and executing HLA federations. It is not intended to replace the existing management and systems design/development methodologies of HLA user organizations, but rather to provide a high-level framework for HLA federation construction and execution into which other systems engineering practices native to each individual application area can be easily integrated. In addition, the HLA FEDEP is not intended to be prescriptive, in that it does not specify a “one size fits all” process for all HLA users. Rather, the FEDEP defines a generic, common sense systems engineering methodology for HLA federations that can and should be tailored to meet the needs of user applications.
Although every HLA application requires a basic agreement among all federates as to the systems engineering approach that will be used to develop and execute the federation, there can be significant variability in the degree of formality defined in the chosen process. The primary driver for how much formality is required is typically the size and complexity of the application. For example, in large complex federations, requirements and associated schedules for delivery of federation products are generally very explicit, as is the content and format for documentation of these products. In smaller or less complex applications, a less structured process with fewer constraints on the types, formats, and content of federation products may be perfectly reasonable and may have certain efficiency advantages as compared to a more formalized process.
Other secondary factors may also influence how the FEDEP is tailored (or adapted) for a specific application. For instance, some communities may have documentation requirements that are unique to their application area. In this case, the activities required to produce these products must be accounted for in the overall process. The reuse potential of these and other required federation products may also influence the nature and formality of the activities that produce them. Another factor is the availability of reusable federation products and persistent federation development teams as opportunities for shortcuts, whereby it may be possible to identify and take advantage of a more streamlined, efficient development process. Finally, practical resource constraints (i.e., cost, schedule) may dictate how certain activities are performed and how the associated federation products are produced and documented.
In summary, it is recognized that the needs and requirements of the distributed simulation community are quite diverse. The HLA provides a generalized architecture for simulation interoperability; however, strict adherence to the HLA specifications is not, by itself, sufficient to ensure a fully consistent, interoperable distributed simulation environment. For instance, issues such as the need for consistent environmental databases and for consistent behavior representations of objects modeled by more than one federate are critical to achieving interoperability; however, these types of issues cannot be fully addressed solely through adherence to the HLA specifications. Although some technical or managerial issues may be unique to a given application, many other issues associated with building and executing a fully interoperable HLA federation are more general in nature. The HLA FEDEP is offered to the HLA community as a starting framework for identifying and addressing these more general issues, as discussed within the context of a full end-to-end process model for the development and execution of distributed simulation environments (federations) that fully conform with the HLA specifications. This framework can and should be tailored as appropriate to address the unique issues, requirements, and practical constraints of each individual application. It is expected that this framework will provide a viable foundation for all HLA applications and will assist the users in defining the specific tasks and activities necessary to support their particular needs.
Scope
This recommended practice defines the processes and procedures that should be followed by users of the High Level Architecture (HLA) to develop and execute federations. It is not intended to replace low-level management and systems engineering practices native to HLA user organizations, but is rather intended as a higher-level framework into which such practices can be integrated and tailored for specific uses.
The High Level Architecture (HLA) has been designed to facilitate interoperability among simulations and to promote reuse of simulations and their components. The HLA is composed of three major components:
— HLA rules: A set of ten basic rules that together describe the general principles defining the HLA.
— HLA interface specification: A description of the functional interface between simulations (federates) and the HLA runtime infrastructure (RTI).
— HLA Object Model Template (OMT): A specification of the common format and structure for documenting HLA object models.
In an HLA application, any number of physically distributed simulation systems can be brought together into a unified simulation environment to address the needs of new applications. These types of environments are known as HLA federations. The HLA specifications together define an overarching framework for the construction and execution of federations.
Within the various government and commercial organizations that comprise the HLA community, many different approaches to project management and systems engineering are being used. Such practices, procedures, and methodologies have evolved over time based on how well they serve the different functional areas and user communities for which they are intended. Many of these approaches currently use modeling and simulation (MS) as a key enabler of certain functions, such as concept evaluation, testing, and training. However, a significant number of organizations adopting the HLA have not yet determined how to tailor their native management and engineering processes to take advantage of the HLA. For instance, while many in the analysis community have established procedures for non-runtime exchange of data from one simulation to another, the opportunities provided by the HLA for more dynamic exchange of data at runtime require that existing engineering processes be modified or augmented in order to take advantage of such opportunities. Even in communities in which distributed simulation is more commonplace (e.g., training), migration to the HLA generally requires some modification to existing management and engineering processes to capture the benefits offered by the HLA. As simulation users perform this migration, it is critical that guidance be available to orient new users to the specific set of tasks and activities necessary to develop and execute HLA federations.
This recommended practice describes the HLA FEDEP. The purpose of this recommended practice is to describe a generalized process for building and executing HLA federations. It is not intended to replace the existing management and systems design/development methodologies of HLA user organizations, but rather to provide a high-level framework for HLA federation construction and execution into which other systems engineering practices native to each individual application area can be easily integrated. In addition, the HLA FEDEP is not intended to be prescriptive, in that it does not specify a “one size fits all” process for all HLA users. Rather, the FEDEP defines a generic, common sense systems engineering methodology for HLA federations that can and should be tailored to meet the needs of user applications.
Although every HLA application requires a basic agreement among all federates as to the systems engineering approach that will be used to develop and execute the federation, there can be significant variability in the degree of formality defined in the chosen process. The primary driver for how much formality is required is typically the size and complexity of the application. For example, in large complex federations, requirements and associated schedules for delivery of federation products are generally very explicit, as is the content and format for documentation of these products. In smaller or less complex applications, a less structured process with fewer constraints on the types, formats, and content of federation products may be perfectly reasonable and may have certain efficiency advantages as compared to a more formalized process.
Other secondary factors may also influence how the FEDEP is tailored (or adapted) for a specific application. For instance, some communities may have documentation requirements that are unique to their application area. In this case, the activities required to produce these products must be accounted for in the overall process. The reuse potential of these and other required federation products may also influence the nature and formality of the activities that produce them. Another factor is the availability of reusable federation products and persistent federation development teams as opportunities for shortcuts, whereby it may be possible to identify and take advantage of a more streamlined, efficient development process. Finally, practical resource constraints (i.e., cost, schedule) may dictate how certain activities are performed and how the associated federation products are produced and documented.
In summary, it is recognized that the needs and requirements of the distributed simulation community are quite diverse. The HLA provides a generalized architecture for simulation interoperability; however, strict adherence to the HLA specifications is not, by itself, sufficient to ensure a fully consistent, interoperable distributed simulation environment. For instance, issues such as the need for consistent environmental databases and for consistent behavior representations of objects modeled by more than one federate are critical to achieving interoperability; however, these types of issues cannot be fully addressed solely through adherence to the HLA specifications. Although some technical or managerial issues may be unique to a given application, many other issues associated with building and executing a fully interoperable HLA federation are more general in nature. The HLA FEDEP is offered to the HLA community as a starting framework for identifying and addressing these more general issues, as discussed within the context of a full end-to-end process model for the development and execution of distributed simulation environments (federations) that fully conform with the HLA specifications. This framework can and should be tailored as appropriate to address the unique issues, requirements, and practical constraints of each individual application. It is expected that this framework will provide a viable foundation for all HLA applications and will assist the users in defining the specific tasks and activities necessary to support their particular needs.
Scope
This recommended practice defines the processes and procedures that should be followed by users of the High Level Architecture (HLA) to develop and execute federations. It is not intended to replace low-level management and systems engineering practices native to HLA user organizations, but is rather intended as a higher-level framework into which such practices can be integrated and tailored for specific uses.