1、 DEPARTMENT OF DEFENSE HANDBOOK INTEROPERABLE SYSTEMS MANAGEMENT AND REQUIREMENTS TRANSFORMATION (iSMART) PROCESS THIS HANDBOOK IS FOR GUIDANCE ONLY. DO NOT CITE THIS DOCUMENT AS A REQUIREMENT. AMSC NA FSC 5895 Statement A: Approved for public release; distribution is unlimited. NOT MEASUREMENT SENS
2、TIVE MIL-HDBK-524 26 June 2012 Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-MIL-HDBK-524 ii Foreword 1. This handbook is approved for use by all Departments and Agencies of the Department of Defense (DOD). 2. This DOD Handbook is based on the Join
3、t interoperable Systems Management and Requirements Transformation (iSMART) Handbook of 1 September 2008, to which all Services are signatories. The iSMART Handbook is a collaborative effort between the Services and the Joint Staff to promote development of interoperable systems at the tactical edge
4、 of the Global Information Grid (GIG). The iSMART process is a systems engineering approach to achieving effective interoperability in a cost-effective manner. A common system engineering method initiated at the beginning of system development significantly increases the probability of fielding syst
5、ems that maximize contribution to joint capabilities. iSMART provides the focus needed for the efficient use of resources, including money, time, manpower, and facilities. The end state of the iSMART process is the rapid transfer of tactical digital information to and between sensors, shooters, and
6、Command and Control (C2) nodes to maximize war fighting capabilities. 3. The iSMART process complements existing DOD acquisition policy. iSMART bridges the gap between the high-level specification of platform capabilities and the technical-level documentation of computer program performance necessar
7、y to implement interoperable tactical data links. It translates high level requirements into the bit-level implementation that meets those requirements, while maintaining Allied, Joint and Service interoperability. Without iSMART, platform implementation of the tactical data link related information
8、 exchange systems which comprise the Tactical Data Enterprise Services (TDES) is often based on legacy/stovepipe requirements, and the results can be a non-interoperable system that does not support the joint war fighting efforts. Early application of the iSMART process in the development cycle ensu
9、res accurate specification of requirements, at a significant cost-savings to the program. 4. Implementation and refinement of the iSMART process is evolving, and platforms from all the Services are in various stages of executing the iSMART process. Platforms that have implemented iSMART early in the
10、 acquisition cycle are realizing the benefits of planned interoperability such as early problem correction, timely cost decisions, and full documentation of a platforms information exchange capabilities. 5. There are several objectives to be achieved before the value of the iSMART process will be re
11、alized. These include establishing DOD policy, resolving funding issues, developing joint Concepts of Network Employment (CONE) by mission area, and the development and management of joint tools to aid in the use of the iSMART process. 6. Currently, each Service bears the cost to implement iSMART, a
12、nd funding support of the iSMART execution process is inconsistent across the Services. To resolve these issues, the Joint Staff and the Defense Information Systems Agency (DISA) are in the process of Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-M
13、IL-HDBK-524 iii advocating iSMART implementation policy and funding mandates. These mandates will result in improved platform interoperability throughout DOD and improved mission effectiveness in joint mission areas. 7. Access to this document is available at the DSPOs Assist Standards Repository lo
14、cated at https:/assist.dla.mil/ 8. Comments, suggestions, or questions on this document should be addressed to SPAWAR Systems Center Pacific, Attn: Code 591, 53560 Hull St., San Diego, CA 92152-5001 or emailed to ismartnavy.mil. Provided by IHSNot for ResaleNo reproduction or networking permitted wi
15、thout license from IHS-,-,-MIL-HDBK-524 iv TABLE OF CONTENTS PARAGRAPH PAGE FOREWORD II 1. SCOPE 1 1.1. Application . 1 2. APPLICABLE DOCUMENTS 3 2.1. General. 3 2.2. Government Documents . 3 2.3. Non-Government Publications. 4 2.4. Order of Precedence. 4 3. DEFINITIONS 5 3.1. Acronyms. 5 4. INTRODU
16、CTION 11 4.1. iSmart Background . 11 4.2. Department of Defense (DOD) Decision Support Process and iSMART 12 4.3. Related iSMART Activities . 13 4.4. Definition and Benefits 14 4.5. Program Offices/Program Managers/Program Development Agencies (POs/PMs/PDAs) 14 4.6. Purpose . 15 4.7. iSMART Handbook
17、 Approach . 15 5. THE ISMART PROCESS 17 5.1. Background 17 5.2. Composition of the IPT 21 5.3. IPT Decision Making Process 22 5.4. Identifying Messages for Implementation 23 5.5. Incremental Development Plans . 23 5.6. PRS and PRDD Development 23 5.7. Special Cases 31 Provided by IHSNot for ResaleNo
18、 reproduction or networking permitted without license from IHS-,-,-MIL-HDBK-524 v PARAGRAPH PAGE 5.8. Developing the Actual Platform Implementation Specification/Platform Implementation Difference Document APIS/PIDD . 31 5.9. Preparing the Actual Implementation . 33 5.10. TDES Interoperability Autho
19、rity Review and Approval . 33 5.11. Life Cycle iSMART Support . 34 5.12. Software Development . 35 5.13. iSMART Terms and Products 36 6. JCIDS, INTEROPERABILITY, AND ISMART . 41 6.1. Introduction 41 6.2. Capabilities-Based Assessment (CBA) 44 6.3. Initial Capabilities Document (ICD) 45 6.4. Capabili
20、ty Development Document (CDD) . 45 6.5. Capability Production Document (CPD) 47 7. JOINT IMPLEMENTATION OF ISMART 49 7.1. Joint iSMART Databases . 49 7.2. Interoperability Enhancement Process (IEP) . 49 7.3. Joint Capabilities and Limitations (JC 1. US Air Force Command and Control Integration Cente
21、r (AFC2IC) Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-MIL-HDBK-524 18 2. U. S. Navy SPAWAR Systems Center, Pacific (SSC PAC), Code 591 3. US Army CIO G6 (SAIS AOJ) 4. US Marine Corps Tactical Systems Support Activity (MCTSSA) 5. Missile Defense
22、Agency (MDA-BC). Contact information is in the Service/Agency appendices. 5.1.3. The IPT should be responsible for: a. Developing the high-level message implementation requirements for the platform to include message, word and action value/message use implementation. b. Obtaining approval from highe
23、r authority to proceed with the planned implementation. c. From the high-level message implementation requirements, developing the precise protocol and bit-level implementation requirements for the platform. d. Obtaining final Service approval of the platform requirements from higher authority. e. P
24、opulating the Information Exchange Requirements (IER), and the Interoperability Matrix (IOM). f. Developing platform host software requirements in accordance with the Platform Requirements Specification (PRS). The program developer is tasked with developing the host computer program in which the dat
25、a link protocols are implemented in accordance with the Service approved PRS. The program developer draws on the experience of the IPT members to resolve problems that are encountered. g. Deviations from the baseline standard are documented and catalogued in the Platform Requirements Difference Docu
26、ment (PRDD). The PRDD defines the required deviations from the platforms baseline standard. A deviation is any difference from the requirements of the baseline standard. h. Obtaining the Service interoperability certification. i. After the platform host software is implemented and tested, the Actual
27、 Platform Implementation Specification (APIS) is created. The APIS documents the fielded or actual implementation data of that platform. Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-MIL-HDBK-524 19 j. All fielded or actual deviations from the base
28、line standard after the platform implementation has been tested are documented in the Platform Implementation Difference Document (PIDD). k. Obtaining joint interoperability certification. l. Obtaining feedback during life-cycle process. Provided by IHSNot for ResaleNo reproduction or networking per
29、mitted without license from IHS-,-,-MIL-HDBK-524 20 FIGURE 1. Testing and JCIDS Process Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-MIL-HDBK-524 21 5.2. Composition of the IPT 5.2.1. The IPT composed of the PO/PM/PDA determines which messages and
30、 protocols will be implemented to support the Information Exchange Requirements (IERs). The IPT is made up of representatives from the PO/PM/PDA, Program Developer, TDES Interoperability Authority and the user community. The participant roles are summarized in TABLE I. 5.2.2. The IPT will assist the
31、 PO/PM/PDA in developing: a. Message implementation that meets the platforms information exchange requirements. b. Functionality to the user (i.e., operational employment perspectives and Human Machine Interface (HMI) issues). c. Interoperability certification plans. 5.2.3. Any platform that attempt
32、s to enter a network has functionality that must be implemented, regardless of whether that functionality satisfies a platform data exchange requirement. For example, implementation of a capability on Link 16, such as a surveillance function, may require that other capabilities be implemented, such
33、as Identity (ID) Difference Resolution, in order to comply with the interoperability core requirements of the MIL-STD-6016 Link 16 Message Standard. TABLE I. IPT Participant Roles Participant Role Program Office/Program Manager/ Program Development Agency Develop ICD for platform. Task the program d
34、eveloper. Adjudicate implementation disagreements within the IPT. Program Developer Develop platform hardware/software that meets mission needs and is interoperable. Generate PRS/PRDD/PIDD/APIS/bit-level implementation (platform iSMART documents). TDES Interoperability Authority Identify message imp
35、lementation that meets mission requirements. Identify interoperability issues. Interpret message standard. User Community Provides operational perspective on implementation of requirements for platforms operating within the tactical edge networks. 5.2.4. The TDES Interoperability Authority will: Pro
36、vided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-MIL-HDBK-524 22 a. Identify that the platform implementation is in accordance with the message standard. b. Advise when failure to implement a requirement, or incorrect implementation, may adversely impact
37、 the probability of platform interoperability certification and/or interoperability within the GIG. c. Provide interpretation of the standard. d. Provide advice for mitigating any adverse impact when a compromise is agreed upon by all stakeholders . e. Assist Program Office/Program Managers by maint
38、aining components of the NR-KPP that are generic to the tactical networks that they have messaging oversight for. This includes application of the DOD Information Enterprise Architecture (IEA), Integrated Architecture Products. Key Interface Profiles (KIPs), and Information Assurance (IA) requiremen
39、ts that are the backbone of successful interoperability assessments. f. Provide iSMART training as needed to the Service PO/PM/PDA and Program Developers. 5.2.5. The TDES Interoperability Authority to the IPT provides Subject Matter Expert (SME) advice based on: a. Existing requirements for similar
40、platforms. b. Requirements of the message standard. c. Understanding of the platforms capabilities and limitations. 5.3. IPT Decision Making Process 5.3.1. The IPT assists the PO/PM/PDA in determining which Tactical Data Links should be implemented on a platforms particular tactical data link system
41、. The PO/PM/PDA, supported by the IPT, will provide the TDES Interoperability Authority recommended implementation plans for approval. Factors supporting implementation decisions made by the IPT include: a. Platform missions - The mission areas of the platform are the primary capabilities on what me
42、ssages and protocols the platform will implement. b. Platform manning - While much of the functionality of the data link is automated, some actions must be performed by the operator. If the platform is required to implement a capability, but is not manned to provide the required operator interaction
43、s, then the platform may have to implement the capability some other way, or not at all. Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-MIL-HDBK-524 23 c. Platform hardware capabilities - Platforms may be limited by the capabilities of their sensors
44、, radios, and other equipment. For example, a platforms Electronic Warfare (EW) sensor suite may not be able to provide bearing accuracy, or detect the presence of jitter. These limitations should be documented in the PRS/PRDD. d. Schedule - If the platform is using an incremental development proces
45、s, the IPT should ensure that the functionality implemented in each increment continues to be interoperable with other net-enabled platforms through Interoperability Evaluation (IOE) comparisons and documenting those results in an Interoperability Assessment (IOA). 5.4. Identifying Messages for Impl
46、ementation 5.4.1. The workflow that best supports the IPT process should be flexible due to the wide range of factors that may influence the decision-making process. 5.4.2. The IPT identifies messages that are required to be implemented to satisfy the platforms IERs, primary missions, and comply wit
47、h appropriate standards. The Services may establish unique methods for doing this, as described in the Service appendices (A-D). 5.4.3. Once the basic MIP for the platform is determined, it is submitted to the TDES Interoperability Authority for review and approval. This review will verify that the
48、platform is taking the correct approach for its implementation. The Service TDES Interoperability Authority will approve the implementation or recommend changes to satisfy interoperability requirements. 5.4.4. When a platforms message implementation is approved, the TDES Interoperability Authority will formally recommend that the platform continue with development. The recommendation should describe any perceived discrepancies and operational impacts. The TDES Interoperability Authority will post the platforms approved message implementation on the Joint iSMART web site. The Joint Staf
