1、IEEE Std 1516.4-2007IEEE Recommended Practice forVerification, Validation, andAccreditation of a FederationAnOverlay to the High Level ArchitectureFederation Development andExecution Process IEEE3 Park Avenue New York, NY 10016-5997, USA20 December 2007IEEE Computer SocietySponsored by theSimulation
2、 Interoperability Standards Committee 1516.4TMIEEE Std 1516.4-2007 IEEE Recommended Practice for Verification, Validation, and Accreditation of a FederationAn Overlay to the High Level Architecture Federation Development and Execution Process Sponsor Simulation Interoperability Standards Committee o
3、f the IEEE Computer Society Approved 27 September 2007 IEEE-SA Standards Board Abstract: This recommended practice defines the processes and procedures that should be followed to implement Verification, Validation, and Accreditation (VV +1 978 750 8400. Permission to photocopy portions of any indivi
4、dual standard for educational classroom use can also be obtained through the Copyright Clearance Center. iv Copyright 2007 IEEE. All rights reserved. Introduction This introduction is not part of IEEE Std 1516.4-2007, IEEE Recommended Practice for Verification, Validation, and Accreditation of a Fed
5、erationAn Overlay to the High Level Architecture Federation Development and Execution Process. The High Level Architecture (HLA) facilitates interoperability among simulations and promotes reuse of simulations and their components. The HLA is composed of three major components and has an accompanyin
6、g Federation Development and Execution Process (FEDEP) model: HLA Framework and Rules: A set of rules that describe the general principles defining the HLA. (IEEE Std 1516-2000) HLA Federate Interface Specification: A description of the interface between simulations (federates) and the HLA runtime i
7、nfrastructure. (IEEE Std 1516.1-2000) HLA Object Model Template Specification: A specification for documenting HLA object models. (IEEE Std 1516.2-2000) HLA Federation Development and Execution Process: A description of the process for constructing and executing HLA federations. (IEEE Std 1516.3-200
8、3) The HLA FEDEP (IEEE Std 1516.3-2003) is a recommended practice that describes a generalized process for building and executing HLA federations. It does not replace the existing management and development methodologies of HLA user organizations, but rather provides a high-level framework into whic
9、h other systems engineering practices can be easily integrated. The FEDEP defines a methodology that can and should be tailored to meet the needs of user applications. This recommended practice provides guidelines for verifying, validating, and accrediting a federation. Its purpose is to provide a m
10、ore detailed view of the VV however, it does not describe the individual techniques that might be employed to execute the VV in this document the term acceptance is the decision to use a model, simulation, or federation of models and simulations for a specific purpose and the term accreditation is t
11、he official certification that a model, simulation, or federation of models and simulations is acceptable for use for a specific purpose. For the purposes of this document the terms are equivalent. IEEE Std 1516.4-2007 IEEE Recommended Practice for Verification, Validation, and Accreditation of a Fe
12、derationAn Overlay to the High Level Architecture Federation Development and Execution Process This overlay identifies and describes the recommended VV however, the VV for enumerated values, the probability that the actual enumerated value corresponds with the simulated or referent value under the s
13、ame conditions; for metric values, the error characteristics associated with the simulated or referent value. 3.2.8 validation: The process of evaluating a model, simulation, or federation of models and simulations throughout the development and execution process to determine how well it satisfies t
14、he acceptability criteria within the context of the referent. 3.2.9 verification: The process of evaluating a model, simulation, or federation of models and simulations and its intermediate products to determine whether the products from a given development phase satisfy the conditions imposed at th
15、e start of that phase and, ultimately, determining that an implementation of a model, simulation, or federation of models and simulations correctly and completely represents the developers conceptual description and specifications. 3.34. Acronyms and abbreviations FEDEP Federation Development and Ex
16、ecution Process FOM Federation Object Model HLA High Level Architecture IEEE Institute of Electrical and Electronics Engineers M verify and validate VV or led and performed by the V even though the product may not be identified as an input in the activity description. 13 Copyright 2007 IEEE. All rig
17、hts reserved. IEEE Std 1516.4-2007 IEEE Recommended Practice for Verification, Validation, and Accreditation of a FederationAn Overlay to the High Level Architecture Federation Development and Execution Process Figure 37.1Activities associated with each VV&A Overlay phase Although many of the activi
18、ties represented in this overlay diagram appear highly sequential, the intention is not to suggest a strict waterfall approach to VV&A. Rather, this process illustration is simply intended to highlight the major VV&A activities that occur during federation development and execution and approximately
19、 when such activities are first initiated relative to other VV&A or FEDEP activities. The activities described in this recommended practice are intended to be tailored to meet the needs of each individual application. The guidance provided in this recommended practice should be used as a starting po
20、int for developing the specific approach to VV&A associated with federation development and execution for the intended use. Phase 1Verify federation objectives The purpose of Phase 1 of the VV&A Overlay is to define the scope of the VV&A effort and establish a stable foundation for establishing a fe
21、derations validity. This requires the VV&A Team to understand the Federation Objectives, the risk that the User/Sponsor can tolerate in their intended use of the federations output, the nature of the Federation Referent, the information needed to define realistic and observable Federation Acceptabil
22、ity Criteria, and the resources required to support the subsequent VV&A activities. This phase should result in a set of verified Federation Objectives and a Federation Referent and Federation Acceptability Criteria that adequately represent those objectives. 14 Copyright 2007 IEEE. All rights reser
23、ved. IEEE Std 1516.4-2007 IEEE Recommended Practice for Verification, Validation, and Accreditation of a FederationAn Overlay to the High Level Architecture Federation Development and Execution Process Figure 4 illustrates the key activities in this phase of the overlay. These activities support the
24、 Federation Development Team in identifying, clearly describing, and documenting the problem that the federation addresses. Understanding what the User/Sponsor really needs the federation to accomplish is essential to the development and VV&A of the federation. A clear, consistent, and complete yet
25、concise User/Sponsor Needs statement will aid the VV&A Team in understanding and assessing the federation objectives, requirements, development plans, and other products resulting from exercising the FEDEP. For example, the User/Sponsor Needs statement should include such information as high-level d
26、escriptions of the critical systems of interest, initial estimates of fidelity requirements, key scenario events, and output data requirements. These insights are important for early VV&A planning. Figure 47.1.1Verify federation objectives (Phase 1) activity diagram Activity 1.1Support identifying U
27、ser/Sponsor Needs This activity assists the Federation Development Team in identifying, clearly describing, and documenting the problem that the federation addresses. Understanding what the User/Sponsor really wants the federation to accomplish is essential to the development and VV&A of the federat
28、ion. The Federation Development Team should ensure that the users representational needs (i.e., what the federation needs to represent and how correct those representations need to be) are captured and understood in the course of this activity. In addition, the impact of federation use should be ass
29、essed and the User/Sponsor tolerances to risk should be estimated. As part of this assessment, the VV&A Team should identify, quantify using consistent units, and rank the User/Sponsor perceptions of the impact of the federation producing incorrect results The VV&A Team should assemble the informati
30、on on the impacts and risks of using a federation into the Federation Use Impact Assessment. 15 Copyright 2007 IEEE. All rights reserved. IEEE Std 1516.4-2007 IEEE Recommended Practice for Verification, Validation, and Accreditation of a FederationAn Overlay to the High Level Architecture Federation
31、 Development and Execution Process The process of identifying User/Sponsor Needs will provide insight into how correct the federation needs to be and how much detail the referent needs to provide. This information will help to identify the Federation Referent. The VV&A Team should also assess the cr
32、edibility of any existing domain descriptions recommended by the User/Sponsor. Finally, as part of the corresponding FEDEP activity the Federation Development Team begins to identify the resources that will be available to support the federation (e.g., personnel, tools, and facilities) as well as an
33、y known constraints that may affect how the federation is developed (e.g., required federation participants, due dates, site and federation management requirements, and security requirements). The VV&A Team can supply information to support this task. For example, they might have input to the select
34、ion of particular tools or facilities that would benefit both development and V&V activities. 7.1.1.17.1.1.27.1.1.3Information required The information recommended for this activity includes the following: Overall plans (from the User/Sponsors perspective) Existing domain descriptions Information on
35、 available resources User/Sponsor Needs input including program objectives Functions (tasks) The functions recommended for this activity include the following: Support analysis of the program objectives to identify the specific purpose and objective(s) that motivate development and execution of a fe
36、deration Support identifying the available resources and known development and execution constraints, as appropriate Assess the User/Sponsors belief in the correctness and completeness of the existing domain descriptions Identify, quantify using consistent units, where possible, and rank the User/Sp
37、onsor perceptions of the impact of using the federation Determine the User/Sponsor tolerances for risk of incurring the impacts of the federation producing incorrect results for their intended uses Assemble the information on the impacts and risks of using a federation into the Federation Use Impact
38、 Assessment Support documentation of the User/Sponsor Needs Information produced The recommended information produced from this activity includes the following: Input to the detailed User/Sponsor Needs (e.g., analysis results and revision suggestions) Input to the available resources and known devel
39、opment and execution constraints Assessment of the correctness and completeness of the existing domain descriptions Federation Use Impact Assessment 16 Copyright 2007 IEEE. All rights reserved. IEEE Std 1516.4-2007 IEEE Recommended Practice for Verification, Validation, and Accreditation of a Federa
40、tionAn Overlay to the High Level Architecture Federation Development and Execution Process 7.1.27.1.2.17.1.2.2Activity 1.2Plan accreditation activities This activity focuses on planning the federation accreditation activities. The resulting plan identifies the information required to support an acce
41、ptance decision and the tasks needed to develop that information. The Federation Accreditation Plan is necessary for planning the V&V activities, guiding the accreditation process, and building the Federation Development and Execution Plan. An acceptance decision (i.e., a decision to use a federatio
42、ns results to serve an intended use) precedes federation use. A formal accreditation decision follows when required. The accreditation activities, and the planning for them, support either formal accreditation or informal acceptance. This activity analyzes the User/Sponsor Needs and the Federation U
43、se Impact Assessment, as well as other information, to determine the needed accreditation tasks then organizes those tasks into an executable sequence. For example, the accreditation tasks might include formulating the acceptability criteria, constructing the referent, performing a risk assessment,
44、and developing the federation acceptance/accreditation recommendations. The Federation Accreditation Plan also identifies the information that the V&V activities should produce. Finally, the accreditation tasks are arranged into a schedule and estimates of the resources needed to perform the accredi
45、tation are made. This activity assumes that the User/Sponsor understands and has expressed their perspective on what they need for the federation to do, how correct it needs to be, and the process they intend to use to identify and assign resources to the accreditation and V&V processes. It also ass
46、umes that the User/Sponsor understands the impact and risk of applying the federation to their intended use. Information required The information recommended for this activity includes the following: User/Sponsor Needs Overall plans (from the User/Sponsors perspective) Federation Use Impact Assessme
47、nt Available resources and known development and execution constraints User/Sponsor input on the credibility expected of the federation Functions (tasks) The functions recommended for this activity include the following: Derive and prioritize the acceptance/accreditation objectives considering the U
48、ser/Sponsor expectations, overall User/Sponsors plans, User/Sponsor Needs, known resource constraints, and Federation Use Impact Assessment Identify the specific tasks needed to achieve each acceptance/accreditation objective Determine the information dependencies between each acceptance/accreditati
49、on tasks and organize the execution of these tasks based upon those dependencies Identify the specific V&V information needed to support the federations acceptance/accreditation Determine the dependencies between the accreditation information needs and organize those needs accordingly Devise a preliminary schedule within which to execute the acceptance/accreditation tasks in the proper order 17 Copyright 2007 IEEE. All rights reserved. IEEE Std 1516.4-2007 IEEE Recommended Practice for Verifica
