AIR FORCE MIL-STD-3014 CHANGE 3-2011 DEPARTMENT OF DEFENSE INTERFACE STANDARD FOR MISSION DATA EXCHANGE FORMAT《任务数据交换格式的国防部接口标准》.pdf

《AIR FORCE MIL-STD-3014 CHANGE 3-2011 DEPARTMENT OF DEFENSE INTERFACE STANDARD FOR MISSION DATA EXCHANGE FORMAT《任务数据交换格式的国防部接口标准》.pdf》由会员分享，可在线阅读，更多相关《AIR FORCE MIL-STD-3014 CHANGE 3-2011 DEPARTMENT OF DEFENSE INTERFACE STANDARD FOR MISSION DATA EXCHANGE FORMAT《任务数据交换格式的国防部接口标准》.pdf（29页珍藏版）》请在麦多课文档分享上搜索。

1、 NOT MEASUREMENT SENSITIVE MIL-STD-3014 w/CHANGE 3 8 July 2011 SUPERSEDING MIL-STD-3014 w/CHANGE 2 26 January 2007 DEPARTMENT OF DEFENSE INTERFACE STANDARD FOR MISSION DATA EXCHANGE FORMAT AMSC N/A AREA MCCR DISTRIBUTION STATEMENT A. Approved for public release; distribution is unlimited. Provided b

2、y IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-MIL-STD-3014 w/CHANGE 3 ii FOREWORD 1. This standard is approved for use by all Departments and Agencies of the Department of Defense (DoD). 2. Prior to the introduction of this standard, mission data exchange fi

3、les transferred between mission planning software and weapon system computers were typically developed independently for each system, and each mission file format was individually integrated on transport media. Transfer of these independent mission plan formats via multiple data transmission media a

4、nd protocols was not typically performed, because sponsoring and funding integration with multiple media and protocols was too big a challenge for each individual weapon system to accept. This was especially true considering the length of time required for integration of weapon-unique data into inte

5、rnational protocols such as TADIL-J, used by Link-16, compared to the product development cycle for weapon systems. As a result, these systems have typically developed only a single path by which to transfer their mission plans. In the past, this was accomplished using a hardware memory unit that is

6、 hand-carried by the pilot from the mission planning station to a launch platform. Historically, mission planning for weapon systems and their launch platforms has focused on deliberate, planned operations that include hours or days of planning time before weapon launch, and a dedicated platform mis

7、sion in support of that launch. 3. An increased DoD focus on prosecution of time-sensitive targets (TSTs) and a DoD transition to network-centric operations (NCO) have demanded shorter and shorter times from discovery of a target by a sensor asset, through the targeting, command authorization, and w

8、eaponeering processes, to the assignment of an attack mission and mission details to a specific shooter and weapon. The timeline of the TST mission, combined with the NCO concept of operations (CONOPS) demands increasing flexibility, both in the selection of weapons to prosecute specific targets (ba

9、sed largely on minimizing time to weapon impact) and in delivering the mission details to the most available weapon system, even though it may already be in captive or free flight on another mission. 4. The functional goal of this standard is to establish a common mission data transfer format for we

10、apon systems. Within this format, every mission data source node or workstation, weapon platform, digital communication link, and weapon system can build, modify, read, interpret, pass, or carry out a mission plan, using a common lexicon and a common interface. The mission-level goal is to improve t

11、he speed and flexibility of creating and delivering mission plans for weapon systems, in order to enhance their value of those weapon systems to commanders and warfighters. The economic goal of this standard is to reduce the cost, complexity, and risk of weapon integration into platforms and communi

12、cations paths, by permitting a single file format for digital mission data to be used, regardless of source, content, or transmission path, by all weapon systems compliant with this standard. 5. This document is reviewed and maintained on a regular basis. The registry appendices are updated quarterl

13、y. The current registry, calendar for updates, and forms and address for submittal of requests for additions can be found online at http:/www.navair.navy.mil/milstd3014 6. Comments, suggestions, or questions on this document should be addressed to (ASC/ENRS, 2145 Monahan Way, Wright-Patterson AFB, O

14、H 45433-7017) or emailed to (Engineering.Standardswpafb.af.mil). Since contact information can change, you may want to verify the currency of this address information using the ASSIST Online database at https:/assist.daps.dla.mil/. Provided by IHSNot for ResaleNo reproduction or networking permitted

15、 without license from IHS-,-,-MIL-STD-3014 w/CHANGE 3 iii CONTENTS Paragraph Page FOREWORD . ii 1. SCOPE 1 1.1 Scope. 1 1.2 Purpose. . 1 1.3 Application 1 2. APPLICABLE DOCUMENTS 2 2.1 General. . 2 2.2 Non-Government publications. 2 2.3 Order of precedence. . 2 3. DEFINITIONS 2 3.1 Definitions. . 2

16、3.1.1 Assert/negate. 2 3.1.2 Byte 2 3.1.3 Class code. 3 3.1.4 Data element. . 3 3.1.4.1 Primitive data element. 3 3.1.4.2 Concatenated data element. . 3 3.1.4.3 Modular data element. . 3 3.1.5 MiDEF. . 3 3.1.6 Module editor. 3 3.1.7 Module header. 3 3.1.8 Organizational entity. . 3 3.1.9 Registry. .

17、 3 3.1.10 Subordinate/superior module. 3 3.1.11 Word. . 4 3.1.12 Syntax diagrams. . 4 3.2 Acronyms and abbreviations. . 4 4. GENERAL REQUIREMENTS . 5 4.1 Data files. . 5 Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-MIL-STD-3014 w/CHANGE 3 iv CONTE

18、NTS Paragraph Page 5. DETAILED REQUIREMENTS . 5 5.1 Organization of data in files. . 5 5.2 Order of module data elements. . 6 5.2.1 Use of nonregistered values in header fields and data elements. . 7 5.2.2 Use of elements in program-unique modules. 7 5.2.3 Use and interpretation of generic element t

19、ypes for specific purposes. 7 5.2.4 Order of module headers. 7 5.3 Definition of mandatory header fields. 8 5.3.1 Module CLASS CODE field. . 9 5.3.2 MODULE SIZE field. 9 5.3.3 HEADER CONTENT field. . 10 5.3.4 USER field. 10 5.3.5 ELEMENT COUNT field. 10 5.3.6 ELEMENT LIST field. . 11 5.4 Definition

20、of optional header fields. . 12 5.4.1 Creator fields. . 15 5.4.1.1 CREATE TIMESTAMP field. . 15 5.4.1.2 CREATE ORG field. 15 5.4.1.3 CREATE INDIV field. 15 5.4.1.4 CREATE SERNO field. . 16 5.4.2 CODE-related fields. 16 5.4.2.1 CODE TYPE field. . 16 5.4.2.2 CODE KEY SIZE field. 16 5.4.2.3 CODE KEY fi

21、eld. . 17 5.4.3 Authorizer-related fields. 17 5.4.3.1 AUTHORIZER TYPE field. 17 5.4.3.2 AUTHORIZER SIZE field. . 17 5.4.3.3 AUTHORIZER STAMP field. . 18 5.4.4 Source fields. . 18 5.4.4.1 SOURCE SIZE field. . 18 5.4.4.2 SOURCE field. 18 5.4.5 NOTE-related fields. . 18 5.4.5.1 NOTE SIZE field. . 18 5.

22、4.5.2 NOTE field. . 19 5.5 Order of primitive data elements. 19 5.6 Order of concatenated data elements. 20 Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-MIL-STD-3014 w/CHANGE 3 v CONTENTS Paragraph Page 6. NOTES 21 6.1 Intended use. . 21 6.1.1 Imp

23、lementation. . 21 6.1.1.1 Registry additions. . 21 6.1.1.2 Registry changes. . 22 6.1.2 Use of optional fields. . 22 6.1.2.1 Creator fields. 22 6.1.2.2 Code fields. . 22 6.1.2.3 Authorizer fields. . 22 6.1.2.4 Source fields. 22 6.1.2.5 Note fields. 23 6.2 Acquisition requirements. . 23 6.3 Tailoring

24、 guidance. . 23 6.4 Subject term (key word) listing. . 23 6.5 Change notations. 23 TABLES TABLE I. Mandatory header field sequence. 7 TABLE II. HEADER CONTENT field format. 10 TABLE III. Optional header field sequence. . 12 FIGURES FIGURE 1. Interpreting syntax diagrams. 4 FIGURE 2. Data file organi

25、zation. 5 FIGURE 3. Order of bits in class codes. 6 FIGURE 4. Order of a modules header and data. . 6 FIGURE 5. Order of mandatory and optional header fields. . 7 FIGURE 6. Order of mandatory header fields in syntax diagram format. . 8 FIGURE 7. Order of mandatory header fields in field size format.

26、 9 FIGURE 8. Structure of element list. 11 FIGURE 9. Order of entries in element list. 11 FIGURE 10. Order of optional header fields in syntax diagram format. 14 FIGURE 11. Order of optional header fields (when fully populated) in field size format. 14 FIGURE 12. Order of CREATE fields. . 15 FIGURE

27、13. Order of CODE fields. . 16 FIGURE 14. Order of AUTH fields. 17 FIGURE 15. Order of SOURCE fields. 18 FIGURE 16. Order of NOTE fields. 18 FIGURE 17. Order of primitive data elements 19 FIGURE 18. Order of concatenated data elements. 20 Provided by IHSNot for ResaleNo reproduction or networking pe

28、rmitted without license from IHS-,-,-MIL-STD-3014 w/CHANGE 3 1 1. SCOPE 1.1 Scope. This standard defines a format for digital data files used for mission-level programming of weapon systems. The term format applies to the organization of data information in the file and the definition of approved da

29、ta types. a. This standard defines, first, a hierarchical or “nested” file architecture, which allows a broad and open-ended variety of data types to be combined and used for a variety of purposes. b. Second, this standard is supported by online registries that catalogue and define standard formats

30、to be used for some common-use data elements, for which a common data format is of benefit. c. Third, this standard is supported by online registries that catalogue and identify unique data types required by specific acquisition programs. As a unique data type registry, this standard supports the us

31、e of data types whose definitions are proprietary, classified, or have very limited application. The registry serves to identify such data types without the need to define them, and prevents indeterminacy and confusion caused when different applications choose the same identifier for different types

32、 of data. d. Finally, this standard is supported by online registries that identify organizations and acquisition systems that produce, transfer, or act upon mission data files. This standard does not establish requirements for content of mission data files, accuracy of data, or its applicability fo

33、r any specific weapon system. Those characteristics are the responsibility of the organizational entity that generates the data and formats it for use in a weapon system. 1.2 Purpose. The purpose of this standard is to provide a common lexicon with which all combat systems can exchange digital missi

34、on data for weapon systems, in order to deliver the desired effects to the enemy as rapidly, economically, effectively, and flexibly as possible. 1.3 Application. This standard defines the file format for the communication of mission data for weapon systems. For this standard, weapon systems are def

35、ined as weapons that function autonomously for at least part of their mission, based on computers operating on received digital mission data. Such systems include those whose plan can be altered or updated in midflight, and those whose function includes operator interventions, such as those with man

36、-in-the-loop terminal guidance. This standard does not apply to direct weapon guidance commands supplied by an operator in a form other than digital data, such as reflected laser or radar energy, and infrared or radar frequency command-to-line-of-sight beam-steering signals. Provided by IHSNot for R

37、esaleNo reproduction or networking permitted without license from IHS-,-,-MIL-STD-3014 w/CHANGE 3 2 2. APPLICABLE DOCUMENTS 2.1 General. The documents listed in this section are specified in sections 3, 4, or 5 of this standard. This section does not include documents cited in other sections of this

38、 standard or recommended for additional information or as examples. While every effort has been made to ensure the completeness of this list, document users are cautioned that they must meet all specified requirements of documents cited in sections 3, 4, or 5 of this standard, whether or not they ar

39、e listed. 2.2 Non-Government publications. The following document forms a part of this document to the extent specified herein. Unless otherwise specified, the issues of these documents are those cited in the solicitation or contract. AMERICAN NATIONAL STANDARDS INSTITUTE ASCII American Standard Cod

40、e for Information Interchange (ASCII Codes are available online at http:/ INCITS 4 Information Systems Coded Character Sets 7- Bit American National Standard Code for Information Interchange (7-Bit ASCII) ISO/IEC 8859-1 Information Technology 8-Bit Single-Byte Coded Graphic Character Sets - Part 1 L

41、atin Alphabet No. 1 (Copies of these documents are available for purchase online at http:/webstore.ansi.org.) 2.3 Order of precedence. In the event of a conflict between the text of this document and the references cited herein, the text of this document takes precedence. Nothing in this document, h

42、owever, supersedes applicable laws and regulations unless a specific exemption has been obtained. 3. DEFINITIONS 3.1 Definitions. Definitions applicable to this standard are as follows. 3.1.1 Assert/negate. When describing digital states, the term “assert” is used to indicate the setting of a bit, f

43、lag, or other digital element to a bit state of logic “1”. The term “negate” is used to indicate the setting of a bit, flag, or other digital element to a bit state of logic “0”. 3.1.2 Byte. An ordered sequence of eight bits, when used to describe binary information in this standard. Provided by IHS

44、Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-MIL-STD-3014 w/CHANGE 3 3 3.1.3 Class code. The unique, two-byte identifier, assigned by the managing office that uniquely identifies a registered data element. 3.1.4 Data element. A digital instruction or piece of da

45、ta, or set of instructions or data, provided to an autonomous system to preprogram subsequent autonomous behavior. A data element can be one of three types: primitive, concatenated, or module. 3.1.4.1 Primitive data element. A primitive data element conveys a single piece of information (e.g., a lat

46、itude). It has a fixed size and format, and a defined class code. 3.1.4.2 Concatenated data element. A concatenated data element is a specific, ordered sequence of primitive data elements (e.g., an ordered sequence of latitude followed by longitude) as defined in its registry entry. It has a fixed s

47、ize and format and a defined class code. 3.1.4.3 Modular data element. A modular data element contains one or more subordinate data elements, which can be primitive, concatenated, or other modules. Modules may optionally have a registered class code. Modules do not have a fixed size. They contain a

48、module header that defines the length and content of the module. This standard places no limit to the length or the number of subordinate data elements in a module. 3.1.5 MiDEF. This standard, and files compliant with it, are commonly known in the user community as “MiDEF“ (pronounced “MY-deaf“) fil

49、es, as a contraction of the title of this standard. 3.1.6 Module editor. Software functionality that creates or edits modules of mission data files that comply with this standard. 3.1.7 Module header. That portion of the information in a module that describes the content, nature, and intended use of that module distinct from the actual mission data