Attach 3 WOSA_Reference_Architecture_R3.4.pdf

WOSA R.A.

Release 3.4

September 2023

Weapon Open System Architecture (WOSA)

WOSA Reference Architecture

Release 3.4

28 September 2023

Prepared for:

AFRL/RWID

Eglin Air Force Base, Florida

Prepared by:

MOATEL (AFRL/RWID)

Air Force Research Lab (RW)

Eglin Air Force Base, Florida 32542

WARNING - This document contains technical data whose export is restricted by the Arms Export Control Act (Title 22, U.S.C., sec 2751 et seq.) or the Export

Administration Act of 1979, as amended, Title 50, U.S.C. App. 2501 et seq. Violations of these export laws are subject to severe criminal penalties. Disseminate in accordance with provisions of DoD Directive 5230.25.

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other requests for this document to AFRL/RWID.

September 2023

Revision History

Rev Summary Of Changes Date

- First draft for review. 1-31-2016

0.1 Updated for ICWG #1. 3-28-2016

0.2

Document reformatted and document navigation added.

Message tables moved to section 5.

Meta Data tables moved to section 6.

Background material moved to Appendix A.

5-16-2016

0.3

Document reformatted using established ICD outlines and approaches as guidelines. Volume 2 represents the logical aspects of the WOSA

ICD. Presented at ICWG #2.

Domain messages reformatted to present data along with associated metadata that described the data.

6-30-2016

0.3b Incorporates findings from ICWG #2; Appendix A separated from main document.

9-30-2016

0.4 Volume 2 ICD [main doc] issue prior to ICWG #3. 11-30-2016

0.5 Volume 2 ICD [main doc; Appendix A] issue prior to ICWG #4. 3-23-2017

0.5b Volume 2 ICD [main doc; Appendix A] revised/updated per ICWG #4. 4-28-2017

0.6 Volume 2 ICD [main doc; Appendix A] issue prior to ICWG #5. 6-30-2017

0.6b Volume 2 ICD [main doc; Appendix A] revised/updated per ICWG #5. 7-31-2017

0.1 WOSA Common Interface Control Plan (CICP). 7-31-2017

0.7 Volume 2 ICD [main doc; Appendix B (revised to A)] revised/updated with findings from Technical Interchange Meetings and ICWG #6.

11-06-2017

0.8 Volume 2 ICD [main doc; Appendix A] revised/updated with findings from TIMs #1-7 and ICWG #6. (not published).

12-15-2017

0.9 Volume 2 ICD [main doc; Appendix A] revised/updated with revised message approaches, and reformatted approach for Appendix A.

1-15-2018

1.0 Volume 2 ICD [main doc; Appendix A] revised/updated prior to ICWG

#7; milestone for formal documents control under CICP.

1-30-2018

1.1 Volume 2 ICD [main doc; Appendix A] revision, sans Section 4. 3-22-2018

1.2 Volume 2 ICD [main doc, Appendix A] revised/updated per ICWG #8;

Volume 2 ICD [main doc] formatted in LaTeX.

8-31-2018

1.3

Volume 2 ICD [main doc] revised/updated per ICWG #9;

Appendix A relabeled as Appendix C;

New Appendix A and New Appendix B.

7-17-2019

1.9

Volume 2 ICD [main doc] revised to update

MSN, MDB, NAV, CLK and COM with more accurate writeups;

Offending graphics removed;

Graphics replaced for most domains

05-07-2020 i

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other

September 2023

2.0

Volume 2 ICD [main doc] revised to update all other domains with more accurate summaries and writeups.

Language across the ICD has been updated to move away from UAI attachment and prescription of consumption. A few graphics which were missing are now added.

05-19-2020

2.5

WOSA Reference Architecture Document revised to incorporate updates determined from ICWG 11 and the Technical Interchange Meeting from

05/2021. Changes include a rename of Volume 2 toWOSA Reference Architecture

(language changes will occur across future updates), the addition of WOSA SubStructures, Generic (Reusable) Message

Structures, and further definition of variably-sized messages.

Additionally, a Change Log and Change Requests file have been added.

06-11-2021

3.0

For a more descriptive changelog, see the changelog.md included on APAN or in the build files. WOSA Reference Architecture has been updated to include changes and updates required to bring the text of the document up-to-date. The new additions from revision 2.5 now have sections explaining design decisions and usage of features such as message sub-structures, generic messages, and the existence of a SysML model designed in CAMEO. Language within this

Reference Architecture now uses the correct names for the three

WOSA Documents.

07-13-2021

3.1 Rectified changes between the WOSA GRA Model and this document.

Also cleaned up data such as Enums to not use enum as the unit value.

08-27-2021

3.2 Added updates to Metamodule message, substructures, and other smaller improvement changes.

05-03-2022

3.3a Generating the message tables straight fromWOSA GRA SysML Model. 08-09-2023

3.4

Added updates from GRA-E effort, modified a few requirements.

Additionally, more DMN common messages were added as well as some RAWmessage definitions. To see a more detailed change log, please refer to the changelog pdf that is within the

SysML WOSA GRA model.

09-28-2023 ii

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other

September 2023

Contents

1 INTRODUCTION 1

1.1 General

1.2 Reference Architecture Document Process

1.3 Scope

1.4 Document Versioning Scheme

1.5 Term Definition

1.5.1 ”Shall”

1.5.2 ”Should”

1.5.3 ”Must”

1.5.4 ”Will”

1.5.5 ”May”

1.6 WOSA Verification and Compliance

1.7 WOSA Modularity Assessment

1.8 General Comments

2 APPLICABLE DOCUMENTS AND ABBREVIATIONS 6

2.1 Applicable Department of Defense Documents

2.2 Applicable Industry Documents

2.3 Acronyms and Abbreviations

3 LOGICAL INTERFACE 12

3.1 WOSA Domains & Interface Definitions

3.1.1 Color Convention

3.1.2 Generic Domain Messages

3.2 WOSA Domains

3.2.1 Addressing Modularity

3.2.2 Metamodule Message

iii

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other

September 2023

3.2.3 Data Representation

3.2.4 Munitions Data Bus Domain Messages

3.2.5 Mission Execution Domain Messages

3.2.5.1 MSN Produced Messages (Pre-Release & Free-Flight)

3.2.6 Platform External Communications Domain Messages

3.2.6.1 Platform External Communications

3.2.7 Weapon Data Link External Communications Domain Messages

3.2.7.1 Weapon Data Link External Communications

3.2.8 Test Communications Domain Messages

3.2.9 Ground Support Equipment Domain Messages

3.2.10 Clock Domain Messages

3.2.10.1 CLK Processing Narrative

3.2.10.2 CLK Produced Messages (Pre-Release)

3.2.10.3 CLK Produced Messages (Free-Flight)

3.2.11 Navigation Domain Messages

3.2.11.1 NAV Processing Narrative

3.2.11.2 NAV Produced

3.2.12 Target State Estimator Messages

3.2.12.1 TSE Processing Narrative

3.2.12.2 TSE Produced Messages (Pre-Release)

3.2.12.3 TSE Produced Messages (Free-Flight)

3.2.13 Guidance Domain Messages

3.2.13.1 GDC Processing Narrative

3.2.13.2 GDC Produced

3.2.14 Autopilot Domain Messages

3.2.14.1 APT Produced

3.2.15 Seeker Domain Messages

3.2.15.1 SKR Processing Narrative

iv

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other

September 2023

3.2.15.2 SKR Produced Messages (Pre-Release)

3.2.15.3 SKR Produced Messages (Free-Flight)

3.2.16 Inertial Measurement Unit Messages

3.2.16.1 IMU Processing Narrative

3.2.16.2 IMU Produced Messages (Pre-Release)

3.2.16.3 IMU Produced Messages (Free-Flight)

3.2.17 Air Data System Domain Messages

3.2.17.1 ADS Processing Narrative

3.2.17.2 ADS Produced Messages (Pre-Release)

3.2.17.3 ADS Produced Messages (Free-Flight)

3.2.18 Fuze/Effects Domain Messages

3.2.18.1 FZE Produced Messages (Pre-Release)

3.2.18.2 FZE Produced Messages (Free-Flight)

3.2.19 Propulsion Domain Messages

3.2.19.1 PRP Processing Narrative

3.2.19.2 PRP Produced Messages (Pre-Release)

3.2.19.3 PRP Produced Messages (Free-Flight)

3.2.20 Air Frame Control Domain Messages

3.2.20.1 AFC Processing Narrative

3.2.20.2 AFC Produced Messages (Pre-Release)

3.2.20.3 AFC Produced Messages (Free-Flight)

3.2.21 Power Management Domain Messages

3.2.21.1 PWR Processing Narrative

3.2.21.2 PWR Produced Messages (Pre-Release)

3.2.21.3 PWR Produced Messages (Free-Flight)

3.2.22 Global Positioning System Aiding Nav Messages

3.2.22.1 GAN Processing Narrative

3.2.22.2 GAN Messages

v

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other

September 2023

3.2.23 Altimeter Aiding Nav Domain Messages

3.2.23.1 AAN Processing Narrative

3.2.23.2 AAN Produced Messages (Pre-Release)

3.2.23.3 AAN Produced Messages (Free-Flight)

3.2.24 Doppler Aiding Nav Domain Messages

3.2.24.1 DAN Processing Narrative

3.2.24.2 DAN Produced Messages (Pre-Release)

3.2.24.3 DAN Produced Messages (Free-Flight)

3.2.25 Vision Aiding Nav Domain Messages

3.2.25.1 VAN Processing Narrative

3.2.25.2 VAN Produced Messages (Pre-Release)

3.2.25.3 VAN Produced Messages (Free-Flight)

3.2.26 Terrain Aiding Nav Domain Messages

3.2.26.1 TAN Processing Narrative

3.2.26.2 TAN Produced Messages (Pre-Release)

3.2.26.3 TAN Produced Messages (Free-Flight)

3.2.27 eLoran Aiding Nav Domain Messages

3.2.27.1 LAN Processing Narrative

3.2.27.2 LAN Produced Messages (Pre-Release)

3.2.27.3 LAN Produced Messages (Free-Flight)

3.2.28 Relative Navigation (RelNav) Aiding Nav Domain Message

3.2.28.1 RAN Processing Narrative

3.2.28.2 RAN Produced Messages (Pre-Release)

3.2.28.3 RAN Produced Messages (Free-Flight)

3.2.29 Celestial Aiding Nav Domain Messages

3.2.29.1 CAN Processing Narrative

3.2.29.2 CAN Produced Messages (Pre-Release)

3.2.29.3 CAN Produced Messages (Free-Flight)

vi

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other

September 2023

3.2.30 Magnetometer Aiding Nav Domain Messages

3.2.30.1 MAN Processing Narrative

3.2.30.2 MAN Produced Messages (Pre-Release)

3.2.30.3 MAN Produced Messages (Free-Flight)

4 WIRELESS COMMUNICATIONS INTERFACE 103

5 INFORMATION SHEETS 104

5.1 WOSA Message Identification Summary

5.1.1 WOSA Domain Identifiers

5.1.2 Directory of WOSA Messages

5.1.3 WOSA Generalized Message Format

5.1.3.1 WOSA Example Data Packet

5.2 General Requirements

5.2.1 Domain Message Set Produce Mandate

5.2.2 Endianness

5.2.3 Error Detection

5.2.4 MaximumMessage Size

5.2.5 RAW Data Messages

5.3 Message Tables

5.3.1 DMN_Aimpoint_Command

5.3.2 DMN_Fuze_Control

5.3.3 DMN_Geozones

5.3.4 DMN_Geozone_Control

5.3.5 DMN_Metamodule_Payload

5.3.6 DMN_Priority_Payload

5.3.7 DMN_Routes

5.3.8 DMN_Seeker_Control

5.3.9 DMN_Status_Monitor_Payload

vii

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other

September 2023

5.3.10 DMN_Target_State_ECEF_Payload

5.3.11 DMN_Target_State_LOS_Payload

5.3.12 MSN_to_DMN_Payload

5.3.13 MSN_Vehicle_State

5.3.14 MSN_Coordinate_Translation

5.3.15 NAV_State_ECEF

5.3.16 NAV_State_Body

5.3.17 GDC_Acceleration_Commands

5.3.18 GDC_Attitude_Commands

5.3.19 GDC_Mach_Number_Commands

5.3.20 GDC_Attitude_Rate_Commands

5.3.21 GDC_Route_Status

5.3.22 APT_Commands

5.3.23 APT_Throttle_Commands

5.3.24 SKR_Data

5.3.25 SKR_PDW

5.3.26 IMU_High_Rate_Measurements

5.3.27 IMU_Incremental_Measurements

5.3.28 ADS_State

5.3.29 PRP_State

5.3.30 AFC_State

5.3.31 PWR_Measurement_Status

5.3.32 TSE_Burst_Timing

5.3.33 TSE_Candidate_ECEF

5.3.34 TSE_Candidate_LOS

5.3.35 TSE_Primary_ECEF

5.3.36 TSE_Primary_LOS

5.3.37 GAN_GPS_Receiver_Measurements

viii

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other

September 2023

5.3.38 GAN_GPS_Receiver_Solutions

5.3.39 GAN_GPS_Satellite_Solutions

5.3.40 GAN_SV_Navigation_Message_LNAV

5.3.41 GAN_SV_Navigation_Message_MNAV

5.3.42 GAN_Time_Sync

5.3.43 AAN_State

5.3.44 DAN_Measurements

5.3.45 DAN_Solution

5.3.46 VAN_Measurements

5.3.47 VAN_Solution

5.3.48 TAN_Measurements

5.3.49 TAN_Solution

5.3.50 LAN_Almanac_Tactical

5.3.51 LAN_TOA_Measurements_Legacy

5.3.52 LAN_Pseudorange_Measurements_Tactical

5.3.53 LAN_Pseudorange_Measurements_Legacy

5.3.54 LAN_Solution

5.3.55 RAN_State

5.3.56 CAN_Measurements

5.3.57 MAN_State

5.3.58 PLT_Differential_GPS_Data

5.3.59 PLT_Environmental_Data

5.3.60 PLT_GPS_Nav_Data

5.3.61 PLT_Initialization_Control

5.3.62 PLT_Launch_Acceptability

5.3.63 PLT_Mission_Control

5.3.64 PLT_Moment_Arm

5.3.65 PLT_Platform_Description

ix

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other

September 2023

5.3.66 PLT_Reset_Transfer_Alignment

5.3.67 PLT_Seeker_Sensor_Control

5.3.68 PLT_Store_Control

5.3.69 PLT_Synchronize_With_Data_Word

5.3.70 PLT_Test_Control

5.3.71 PLT_Time_Synchronize

5.3.72 PLT_Transfer_Alignment

5.3.73 PLT_WDL_Control_Monitor

5.3.74 PLT_WDL_Link_Monitor

5.3.75 PLT_Action_Point_Controls

5.3.76 PLT_Action_Point_Location

5.3.77 PLT_Action_Point_Attack_Params

5.3.78 PLT_Initialization

5.3.79 WDL_Ownship_ECEF

5.3.80 WDL_Platform_ECEF

5.3.81 WDL_Control

5.3.82 TST_TM_FTS_Monitor

5.3.83 CLK_Time_Sync

5.4 Message Sub-Structures

5.5 Domain Parameters

A WOSA REQUIREMENTS 288

A.1 WOSA Requirements List

A.1.1 General Open System Architecture Requirements

A.1.2 MDB Domain Requirements

A.1.3 Domain Parameter Requirements *Notional*

A.2 Requirements Verification

A.3 Removed Requirements x

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other

September 2023

B CRC EXAMPLE 291

B.1 File: crc.h

B.2 File: crc.c

C WOSA Model 299

C.1 WOSA Goverenment Reference Architecture Model

D ADDITIONAL EXAMPLES 300

D.1 Variable Message Sizes xi

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other

September 2023

List of Figures

1 Domain Interaction Diagrams Key

2 Simplified Diagram of CLK Domain Messages During the Pre-Release Phase

3 Simplified Diagram of CLK Domain Messages During the Free-Flight Phase

4 Simplified Diagram of NAV Domain Messages During the Pre-Release Phase

5 Simplified Diagram of NAV Domain Messages During the Free-Flight Phase

6 Simplified Diagram of TSE Domain Messages During the Pre-Release Phase

7 Simplified Diagram of TSE Domain Messages During the Free-Flight Phase

8 Simplified Diagram of SKR Domain Messages During the Pre-Release Phase

9 Simplified Diagram of SKR Domain Messages During the Free-Flight Phase

10 Simplified Diagram of IMU Domain Messages During the Pre-Release Phase

11 Simplified Diagram of IMU Domain Messages During the Free-Flight Phase

12 Simplified Diagram of ADS Domain Messages During the Pre-Release Phase

13 Simplified Diagram of ADS Domain Messages During the Free-Flight Phase

14 Simplified Diagram of FZE Domain Messages During the Pre-Release Phase

15 Simplified Diagram of FZE Domain Messages During the Free-Flight Phase

16 Simplified Diagram of PRP Domain Messages During the Pre-Release Phase

17 Simplified Diagram of PRP Domain Messages During the Free-Flight Phase

18 Simplified Diagram of AFC Domain Messages During the Pre-Release Phase

19 Simplified Diagram of AFC Domain Messages During the Free-Flight Phase

20 Simplified Diagram of PWR Domain Messages During the Pre-Release Phase

21 Simplified Diagram of PWR Domain Messages During the Free-Flight Phase

22 Simplified Diagram of AAN Domain Messages During the Pre-Release Phase

23 Simplified Diagram of AAN Domain Messages During the Free-Flight Phase

24 Simplified Diagram of DAN Domain Messages During the Pre-Release Phase

25 Simplified Diagram of DAN Domain Messages During the Free-Flight Phase

26 Simplified Diagram of VAN Domain Messages During the Pre-Release Phase

27 Simplified Diagram of VAN Domain Messages During the Free-Flight Phase xii

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other

September 2023

28 Simplified Diagram of TAN Domain Messages During the Pre-Release Phase

29 Simplified Diagram of TAN Domain Messages During the Free-Flight Phase

30 Simplified Diagram of LAN Domain Messages During the Free-Flight Phase

31 Simplified Diagram of LAN Domain Messages During the Free-Flight Phase

32 Simplified Diagram of RAN Domain Messages During the Pre-Release Phase

33 Simplified Diagram of RAN Domain Messages During the Free-Flight Phase

34 Simplified Diagram of CAN Domain Messages During the Pre-Release Phase

35 Simplified Diagram of CAN Domain Messages During the Free-Flight Phase

36 Simplified Diagram of MAN Domain Messages During the Pre-Release Phase

37 Simplified Diagram of MAN Domain Messages During the Free-Flight Phase

38 Static Domain Parameters Values are Made Available by Domain Vendor

39 Model Relationships and Domain Parameters

40 TDPs Support Future Upgrades xiii

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other

September 2023

List of Tables

1 Applicable Department of Defense Documents

2 Applicable Industry Documents

3 Acronyms and Abbreviations

4 Generic Message Set

5 Internal Data Representations

6 Munitions Data Bus Messages Produced

7 Mission Execution Messages Produced (Execution to Domains)

8 PLT Messages Produced

9 WDL Messages Produced

10 Test Messages Produced

11 Ground Support Equipment Messages Produced

12 Message ID - Domain Identifier

13 Directory of WOSA Messages

14 Generalized WOSA Message Format Template

15 Example WOSA Data Packet

16 Example of Memory Addressing for Big and Little Endian

17 Table for ’MSN Execution Control - ddd’ enumeration values

18 DMN_Aimpoint_Command

19 DMN_Fuze_Control

20 DMN_Geozones

21 DMN_Geozone_Control

22 DMN_Metamodule_Payload

23 DMN_Priority_Payload

24 DMN_Routes

25 DMN_Seeker_Control

26 DMN_Status_Monitor_Payload

27 DMN_Target_State_ECEF_Payload xiv

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other

September 2023

28 DMN_Target_State_LOS_Payload

29 MSN_to_DMN_Payload

30 MSN_Vehicle_State

31 MSN_Coordinate_Translation

32 NAV_State_ECEF

33 NAV_State_Body

34 GDC_Acceleration_Commands

35 GDC_Attitude_Commands

36 GDC_Mach_Number_Commands

37 GDC_Attitude_Rate_Commands

38 GDC_Route_Status

39 APT_Commands

40 APT_Throttle_Commands

41 SKR_Data

42 SKR_PDW

43 IMU_High_Rate_Measurements

44 IMU_Incremental_Measurements

45 ADS_State

46 PRP_State

47 AFC_State

48 PWR_Measurement_Status

49 TSE_Burst_Timing

50 TSE_Candidate_ECEF

51 TSE_Candidate_LOS

52 TSE_Primary_ECEF

53 TSE_Primary_LOS

54 GAN_GPS_Receiver_Measurements

55 GAN_GPS_Receiver_Solutions xv

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other

September 2023

56 GAN_GPS_Satellite_Solutions

57 GAN_SV_Navigation_Message_LNAV

58 GAN_SV_Navigation_Message_MNAV

59 GAN_Time_Sync

60 AAN_State

61 DAN_Measurements

62 DAN_Solution

63 VAN_Measurements

64 VAN_Solution

65 TAN_Measurements

66 TAN_Solution

67 LAN_Almanac_Tactical

68 LAN_TOA_Measurements_Legacy

69 LAN_Pseudorange_Measurements_Tactical

70 LAN_Pseudorange_Measurements_Legacy

71 LAN_Solution

72 RAN_State

73 CAN_Measurements

74 MAN_State

75 PLT_Differential_GPS_Data

76 PLT_Environmental_Data

77 PLT_GPS_Nav_Data

78 PLT_Initialization_Control

79 PLT_Launch_Acceptability

80 PLT_Mission_Control

81 PLT_Moment_Arm

82 PLT_Platform_Description

83 PLT_Reset_Transfer_Alignment xvi

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other

September 2023

84 PLT_Seeker_Sensor_Control

85 PLT_Store_Control

86 PLT_Synchronize_With_Data_Word

87 PLT_Test_Control

88 PLT_Time_Synchronize

89 PLT_Transfer_Alignment

90 PLT_WDL_Control_Monitor

91 PLT_WDL_Link_Monitor

92 PLT_Action_Point_Controls

93 PLT_Action_Point_Location

94 PLT_Action_Point_Attack_Params

95 PLT_Initialization

96 WDL_Ownship_ECEF

97 WDL_Platform_ECEF

98 WDL_Control

99 TST_TM_FTS_Monitor

100 CLK_Time_Sync

101 Message SubStructures

102 SubStructure:DMN_Fuze_Control_Stages

103 SubStructure:DMN_Geozone_Geographic_Points

104 SubStructure:DMN_Geozone_Control_Zones

105 SubStructure:DMN_Report_Vendor_Version

106 SubStructure:DMN_RPT_Message_Rate

107 SubStructure:DMN_RPT_Target_Priority

108 SubStructure:DMN_Routes_Routes

109 SubStructure:DMN_Routes_Waypoints

110 SubStructure:DMN_RPT_BIT_Status

111 SubStructure:DMN_RPT_Domain_Status xvii

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other

September 2023

112 SubStructure:DMN_RPT_Target_State_ECEF

113 SubStructure:DMN_RPT_Target_State_LOS

114 SubStructure:AFC_RPT_Effector_State

115 SubStructure:APT_RPT_Effector_State

116 SubStructure:APT_RPT_Throttle_Command

117 SubStructure:CAN_RPT_Measurements

118 SubStructure:GAN_RPT_Pseudorange_Measurements

119 SubStructure:GAN_RPT_GPS_Satellite

120 SubStructure:GAN_RPT_LNAV_Measurements

121 SubStructure:PLT_RPT_Launch_Acceptability_Geopoint

122 SubStructure:PWR_RPT_Measurement_Status

123 SubStructure:SKR_RPT_Track_Obs

124 SubStructure:SKR_RPT_PDW_Tracks

125 SubStructure:SKR_RPT_Emitter

126 SubStructure:SKR_RPT_Pulse_Descriptor_Words

127 SubStructure:TAN_RPT_Measurements

128 SubStructure:VAN_RPT_Measurements

129 WOSA Message Header

130 Variably Sized WOSA Packet without substructure values

131 Fully Parsed Variably Sized WOSA Packet xviii

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other

September 2023

1 INTRODUCTION

1.1 General

This document presents the Weapon Open System Architecture (WOSA) Reference Architecture, Version

3.4, addressing the logical aspects of WOSA-compliant weapon systems design and operation.

The primary objective of this document is to establish a Weapon Open System Architecture framework that enables development of a partitioning strategy required to identify common domain boundaries and interfaces. The architectural framework must be based on fundamental knowledge of the way a general-ized weapon system operates in a real-world environment. To this end, technical background material will be included in WOSAWhite Paper series for use as references. The purpose of this document is to specify

WOSA common interfaces—and associated data requirements for these interfaces.

The document describes constituent domains that support a generalized air-launched weapon system ar-chitecture. The term ‘domain’ is used in an abstract context to coalesce a set of related functions and services that may be realized in unique vendor designs. Domains have common attributes in their func-tionality regardless of the various technology implementations employed.

For each domain identified in the architecture, a set of messages that the respective domains ‘produce’ has been identified. Each message set represents the current edition from which Subject Matter Experts

(SMEs) can modify the messages within their respective sub-groups in future Interface Control Working

Group (ICWG) meetings and Technical Interchange Meetings (TIMs). The message sets produced by each domain contain data generated by operations inherent to that domain’s functions. Also, each domain may ‘consume’ WOSA messages containing data produced by peer domains that the consuming domain requires to perform its operations.

TheWOSA architecture presented in Section 3 represents the latest framework to emerge from the domain identification and message definition processes—two key objectives of this document. It is expected that the architecture and potentially some domains will be modified or changed as the architecture evolves.

Needed changes will be identified through day-to-day research, new weapon program office additions, and modeling activities, and enhanced and recommended for approval by the ICWG and TIM forums that occur periodically.

1.2 Reference Architecture Document Process

TheWeaponOpen SystemArchitecture and associated documents use a continuing process of discussions, findings, and consensus developed over time among the Precision Guided Munitions (PGM) community to enhance the architecture. The current WOSA Reference Architecture version 3.4 is an evolving work-in-progress activity. The way forward is determined by continuing ICWG milestones as the architecture development process proceeds. WOSA is not a formal acquisition program per se; however, its activities will guide new research efforts as well as current and future acquisition programs.

The goal of WOSA development is to provide an architecture that captures specific details sufficient to define a set of open interfaces that support WOSA-related program objectives. To begin the process, a

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other

September 2023 generalizedweapon reference architecture has been established that comprises a set of domains to enable a WOSA-compliant weapon to perform its intended mission functions and use cases. No specific technical design implementations for domains are implied.

Initially, the domains were identified by asking abstract questions about very high-level ‘services’ support-ing use cases that WOSA-compliant weapons must satisfy. These high-level services are composed in a general sense for operational utility—and ultimately provide the foundation for the architecture develop-ment.

To support these discussions, the high-level questions address:

• What are the general mission functions and use cases required by WOSA to service?

• How are the specific mission functions and objectives communicated to the weapon?

• How does the weapon get initialized? What are the dependencies on the host platform?

• What services are required to ‘fly’ the weapon from its release point to target impact?

• What are the supporting internal resources and their services required to support precisely ‘flying’ the weapon to the target?

• What sensors and effectors services are required to support this objective?

These questions began the process of abstracting and organizing an architecture so that theWOSA could be developed and evolved—and the open interfaces could be drafted and published. The process identifies a set of domains that addresses specific functions required by the WOSA weapons. The respective domains

‘produce’ the results of their functions, operations, methods, and processes in the form of WOSA defined messages. Each domain can ‘consume’ data produced by peer domains in the form of WOSA defined messages, using their results to perform its functions, operations, methods, and processes. Thus, the organization of WOSA is presented—followed by details of the individual domain messages produced.

1.3 Scope

This volume, theWOSA Reference Architecture, currently addresses the logical aspects of the WOSA, gen-eralizedmiddleware, and transport aspects ofWOSA. This volume does not address the physical attributes of the WOSA-compliant weapon subsystem interfaces, i.e., aerodynamic, mechanical, electrical, connec-tors, etc. The physical attributes will be addressed at a program level and will be implementation and program specific.

TheWOSA Reference Architecture contains the following sections and associated content:

• Section 1 INTRODUCTION (this section) establishes the document scope and provides basic back-ground information for the document user.

• Section 2 APPLICABLE DOCUMENTS AND ABBREVIATIONS identifies the applicable documents that are referenced in the WOSA Reference Architecture and identifies the versions of the documents applicable to this reference architecture. It also contains a list of acronyms and definitions.

• Section 3 LOGICAL INTERFACE describes theWeapon Open System Architecture logical baseline and constituent domains—identifying the messages and data elements produced by each domain at their respective interfaces.

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other

September 2023

• Section 4 WIRELESS COMMUNICATIONS INTERFACE defines the logical approach for exchanging internal information via the COM (e.g., Data Link) domain with external data exchange nodes (e.g., aircraft platforms, satellite communications). Currently it is a work-in-progress activity.

• Section 5 INFORMATION SHEETS defines the messages produced by each domain (that are ulti-mately consumed by peer domains); message data elements and their associated metadata are defined. The term ‘message’ is used in a general context to support the process of aggregating associated data elements into data groupings for each domain.

• Section 6 WIRELESS COMMUNICATION INFORMATION SHEETS This section will ultimately define the messages for Wireless Communications Interface addressed in Section 4.

• Appendix A WOSA REQUIREMENTS This appendix lists all the WOSA requirements in one central location. It also outlines a procedure for verifying those requirements.

• Appendix B CRC EXAMPLE This appendix provides example code for the CRC suggested for use in

WOSA systems.

1.4 Document Versioning Scheme

A document numbering scheme is used to track the version of this document. A release version is denoted by an “R” followed by the number of the specific release. As an example, R1.3 denotes Release 1.3. A draft release version is denoted by a “D” followed by the number of the specific release as well as a number specifying which draft version. As an example, D1.3-2 denotes the second draft of Release 1.3.

WOSA is currently broken into three volumes. Other supplements are being created but are not currently a part of the WOSA structure.

WOSA Reference Architecture—This document is the logical definition of WOSA. It contains the message definitions, the architectural and functional decomposition of a munition, and design requirements.

WOSA Verification Plan—This describes themethodology used to verify compliance with theWOSA Refer-enceArchitecture standard. The steps usedbyMOATEL for the certificationof a domain asWOSACompliant are outlined in this document.

WOSA Implementation Architecture—This document is the detailed description of the actual implemen-tation of the specific munition system. It contains all of the interface and communication information for each of the domains necessary to enable an integrator to interoperate with a domain and integrate into a munition system (e.g., Interface Control Documents, Interface Design Documents, Schematics, etc.). The

WOSA Implementation Architecture documentation will be used during verification to ensure the informa-tion is complete and accurate. The following are a few examples of how the documentation will be used during verification:

• Inspect all inter-domain message exchange;

• Parse all inter-domain messages;

• Verify completeness of inter-domain message production with respect to WOSA Message Identifi-cation Summary, Section 5.1;

• Verify compliance of inter-domain message formats with respect to theWOSA GeneralizedMessage

Format, Section 5.1.3;

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other

September 2023

• Assess timing performance for inter-domain message exchange in accordance with timing measures defined in the WOSA Implementation Architecture.

1.5 Term Definition

The terms ”shall”, ”should”, ”must”, ”will” and ”may” are used with specific intent throughout this docu-ment and observe the following rules.

1.5.1 ”Shall”

Requirements defined using ”shall” in the text are mandatory requirements to include legislative or regu-latory requirements (e.g. Health and Safety).

1.5.2 ”Should”

The word ”should” in the text expresses a recommendation or advice for which a deviation and/or degra-dation from the requirement is acceptable. However, it is expected that the recommendation or advice is followed unless good reason is given for not doing so.

1.5.3 ”Must”

The word ”must” in the text highlights requirements for external systems not covered by theWOSA Refer-ence Architecture.

1.5.4 ”Will”

The word ”will” in the text expresses statements of fact or the future tense.

1.5.5 ”May”

The word ”may” in the text expresses a permissible practice or action.

1.6 WOSA Verification and Compliance

In order to ensure a requirement is met, the requirement must be verified and the testingmethodmust be validated. WOSA Compliancemeans requirements have beenmet through verification and the verification method has been validated. Currently the Munitions Open Architecture Test and Evaluation Laboratory

(MOATEL) is the only validated WOSA verification entity. However, new MOATEL 3rd party approved facili-ties may exist in the future. MOATEL is an AFRL/RWMunitions Directorate resource that develops testing and verification plans, procedures, software, and other resources by which to verify WOSA Compliance.

While self-verification can occur, it does not mean WOSA Compliance has been achieved. A primary goal of Open Architecture is to provide third-parties access to data necessary to accomplish integration and in-teroperability between open modules and components. Therefore, the best verification will involve third-party integration and interoperability in some form or fashion. It is due to the primary goal of third-party interoperability that self-compliance cannot occur. MOATEL is intended to be a third-party that can verify

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other

September 2023

WOSA requirements are met and the modules and components under test are open by using documen-tation available to third-parties and performing integration within a hardware-in-the-loop environment.

This ensures communication can be accomplished, which is the first and most important step to achieve open architecture. As such, a requirement has been added to theWOSA Reference Architecture regarding compliance.

• [OSA-0015] The WOSA Architecture implementation shall be verified for WOSA compliance using the Munitions Open Architecture Test and Evaluation Laboratory (MOATEL)

MOATEL is the authority that determines WOSA compliance. MOATEL will apply verification software to

WOSAphysicalmodules in order to ensure the vendor adhered to theWOSAReference Architecture. MOA-

TEL verifies vendor WOSA Implementation Architecture is in line with delivered hardware and software and fully characterizes the MDB to determine modularity, future upgrade paths, and capabilities. More information regarding details of WOSA Verification and Compliance can be found in the WOSA Test and

Evaluation Document.

• Compliance will be determined by MOATEL

• Compliance will be assessed per WOSA Physical Module

1.7 WOSA Modularity Assessment

WOSAModularity is ameasure of decomposition and coupling betweenmajor functions of a system. Com-plexity between modules/components of a system are expected to decrease as modularity increases, and thus the resources required to interchangemodules/components or extend a systems capability should de-crease. Open Architecture andModularity are not the same. Open indicates the availability of information to be shared with other parties. WOSA has been designed to enable modularity. AModularity Assessment has been developed to identify themodularity of an embedded system, identify key interfaces, and provide amethod for programoffices to createmodularity requirements. Amethod for scoringmodularity has also been developed. Modularity Scoring provides a way to create a WOSA Modularity requirement and verify the requirement is met using an objective process. Modularity will be assessed per each WOSA Physical

Module. A modularity requirement has been created to ensure modularity is captured to some degree and the overall goal of WOSA is obtained. Details on how to perform a WOSA Modularity Assessment can be found in the WOSA Modularity Assessment Guide.

• [OSA-0016] A WOSA Physical Module shall satisfy [OSA-0016A] -OR- [OSA-0016B] -OR- both.

– [OSA-0016A] A WOSA Physical Module shall have a modularity score greater than 0 as calcu-lated using the WOSA Modularity Metric Process

– [OSA-0016B] AWOSA Physical Module shall have available sufficient data (including all neces-sary documentation, models, software, and/or firmware) with Unlimited or Government Pur-pose data rights to enable third-party REMOVAL and REPLACEMENT of every WOSA domain contained within the WOSA Physical Module.

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other

September 2023

1.8 General Comments

Interface Control Documents used in many systems are fundamentally declarative in style—using more direct and specific language and assertions. The WOSA Reference Architecture addresses many different types of weapon system configurations in one document and is fundamentally more narrative in style— using more generalized language to address a wide spectrum of technology implementations within a single document.

2 APPLICABLE DOCUMENTS AND ABBREVIATIONS

2.1 Applicable Department of Defense Documents

The following documents of the exact issue shown form part of this document to the extent specified herein. For those documents showing no date of issue, the latest issue applies.

Table 1: Applicable Department of Defense Documents

Ref. No. Title Document No. Issue / Date

Universal Armament Interface

Platform/Store Interface Control Document

UAI-PSICD-R06 2023

Interface Standard for Digital Time Division

Command/Response Multiplex Data Bus

MIL-STD-1553B

(Notice 4) 15 Jan 1996

Interface Standard for Aircraft/Store Electrical

Interconnection System MIL-STD-1760E 24 Oct 2007

Interface Standard for Mission Data Exchange

Format MIL-STD-3014 20 Feb 2004

5 Miniature Mission Store Interface (MMSI) MIL-STD-3016

DoD Interface Standard, Tactical Data Link

(TDL) 16 Messages Standard (Change 1) MIL-STD-6016C 25 Mar 2005

DoD Interface Standard Variable Message

Format (VMF)

MIL-STD-6017A

(Notice 1) Dec 2014

8 UAI Mission Planning Interface Control Document UAI-MPICD-R04 05 Apr 2013

9 UAI Interface Control Plan (ICP) UAI-ICP-R02 12 Jan 2009

Weapon Data Link Network (WDLN) Advanced

Concept Technology Demonstration (ACTD) ICD

WDLN ICD

Baseline V1.0 18 May 2005

11 WOSA Verification Plan WOSAVP v1.4 1 Aug 2020

12 WOSA Modularity Assessment Guide WOSA_MAG v1.0 25 Mar 2022

2.2 Applicable Industry Documents

The following documents of the exact issue shown form part of this document to the extent specified herein. For those documents showing no date of issue, the latest issue applies.

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other

September 2023

Table 2: Applicable Industry Documents

Ref. No. Title Document No. Issue / Date

IEEE Standard for a Precision Clock

Synchronization, Protocol for Networked

Measurement and Control Systems

IEEE Std 1588TM

-2008 24 Jul 2008

2 IEEE Standard for Floating-Point Arithmetic IEEE Std 754TM

-2008 29 Aug 2008

3 IEEE Standard for Inertial Systems Terminology IEEE Std 1559TM

-2009 26 Aug 2009

4 SAE Platform/Subsystem Common Interface SAE AS5658TM 13 Feb 2009

SAE Interface Standard Common Interface

Control Plan SAE AS6030ATM 03 Jan 2011

SAE Standard Electrical and Logical Interface for Airborne ,Fuzing Systems SAE AS5716ATM Dec 2012

SAE Handbook: Standard Electrical and Logical

Interface, for Airborne Fuzing Systems SAE AIR6234TM Nov2016

American National Standard Code for Information

Interchange Aircraft/Store Common Interface Control

Document Format

ANSI X3.4-1977

AS5609

Apr 2004

9 Interface Standard, Miniature Mission Store Interface SAE AS5725TM Jan 2008

10 Megabit/sec Network Configuration Digital

Time Division Command/Response Multiplex Data Bus SAE AS5652TM Dec 2005

2.3 Acronyms and Abbreviations

The following acronyms and abbreviations are used throughout this document and are defined here for convenience.

Table 3: Acronyms and Abbreviations

Acronym Description

AA Air-to-Air

AAN Altimeter Aiding Navigation

ACM Actuation Control Motor

ACTD Advanced Concept Technology Demonstration

ADS Air Data System

AFRL Air Force Research Laboratory

AFC Air Frame Control

AGL Advanced Guidance Law

APN Augmented Proportional Navigation

APT Autopilot

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other

September 2023

ATR Autonomous Target Recognition

BC Bus Controller

BIT Built-In Tests

CAN Celestial Aiding Navigation

CCA Circuit Card Assembly

CDS Configuration Data Set

CI Common Interfaces

CONEMPS Concept of Employments

CONOPS Concept of Operations

CSCI Computer Software Configuration Item

CSC Computer Software Component

CSU Computer Software Unit

CTEIP Central Test and Evaluation Investment Program

DCM Direction Cosine Matrix

DME Distance Measuring Equipment

DMPI Desired Mean Point of Impact

DoD Department of Defense

DAN Doppler Aiding Navigation

DPR Delta Pseudorange

DSMAC Digital Scene Matching Area Correlation

DVS Doppler Velocity Sensor

DWDM Dense Wave Division Multiplex

EBR Enhanced Bit Rate

ECEF Earth-Center, Earth-Fixed

ECI Earth-Centered Inertial

EM Electromagnetic

EMS Executive Message Set

FACE Future Airborne Capabilities Environment

FADEC Full Authority Digital Electronic Control

FOG Fiber-optic Gyro

FWCI Firmware Configuration Item

GAN GPS Aiding Nav

GNSS Global Navigation Satellite System

GSE Ground Support Equipment

HAE Height Above Ellipsoid

HOST Hardware Open Systems Technologies

HWCI Hardware Configuration Item

ICD Interface Control Document

ICP Interface Control Plan

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other

September 2023

ICT Internal Communication Technology

ICWG Interface Control Working Group

IEEE Institute of Electrical and Electronics Engineers

IGTD Inertial Guidance Technology Demo

IMM Interface for Micro-Munitions

IMU Inertial Measurement Unit

INS Inertial Navigation System

IP Intercept point

JCA Joint Common Architecture

JDAM Joint Direct Attack Munition

KF Kalman Filter

LAN eLoran Aiding Navigation

LAR Launch Acceptability Region

LORAN Long-Range Aid to Navigation

LOS Line-of-Sight

LRU Line Replaceable Unit

MAN Magnetometer Aiding Navigation

MDB Munitions Data Bus

MDS Mission Data Set

MDT Mass Data Transfer

MMSI Miniature Munitions Store Interface

MMW Millimeter Wave

MOSA Modular Open Systems Architecture

MSL Mean Sea Level

MSN Mission Execution

NAV Navigation

NavAid Navigation Aiding

NED North-East-Down

NIU Network Interface Unit

NNMSB Non-Nuclear Munitions Safety Board

NVM Non-Volatile Memory

OA Open Architecture

OFP Operational Flight Program

OGTD Operational Guidance Technology Demo

OMS Open Mission Systems

OSA Open System Architecture

OSI Open-Standard Interfaces

PBIT Periodic Built in Tests

PCO Power Change Over

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other

September 2023

PF Programmable Fuze

PGM Precision Guided Munition

PNG Proportional navigation guidance

PF Programmable Fuze

PPLI Precise Position Location and Identification

PRES Post Release Environment Sensors

ProNav Proportional navigation

PTAM Periodic Transfer Alignment Message

PVA Position, Velocity, Attitude Data

R&D Research and Development

RAN Relative Aiding Navigation

RelNav Relative Navigation

RF Radio frequency

RLG Ring laser gyro

RT Remote Terminal

SA Surface-to-Air

SAE Society of Automotive Engineers

SATIN Type of TRN

SDB Small Diameter Bomb

SFSS Sub-miniature Flight Safety System

SME Subject Matter Expert

SOSA Sensor Open Systems Architecture

SWaP-C Size, Weight, and Power - Cost

T1CS Type 1 Carriage System

T2CS Type 2 Carriage System

TACAN Tactical Air Navigation System

TAN Terrain Aiding Navigation

TBD To Be Determined

TERCOM Terrain Contour Matching

TDL Tactical Data Link

TIM Technical Interchange Meeting

TRN Terrain Reference Navigation

TVC Thrust Vector Control

TXA Transfer Alignment

UAI Universal Armament Interface

UINT Unsigned Integer

URA User Range Accuracy

VAN Vision Aiding Navigation

VICTORY Vehicular Integration for C4ISR/EW Interoperability

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other

September 2023

VM Volatile Memory

VMF Variable Message Format

WDL Weapon Data Link

WDLN Weapon Data Link Network

WFC Weapon Flight Controller

WLM WOSA Logical Module

WOSA Weapon Open System Architecture

WPM WOSA Physical Module

ZEM Zero Effort Miss

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other

September 2023

3 LOGICAL INTERFACE

3.1 WOSA Domains & Interface Definitions

This section identifies the messages associated with each domain. Before proceeding further, several def-initions of key concepts in the context of this document are presented. The previous definitions list has been augmented to include additional terms presented at TIM #9 by AFRL/RW. The new definition list included below:

• Architecture: a collection of domains that uniquely contribute in an organized manner to the archi-tecture’s achievement of a system requirements specification.

• Domain: an abstract representation to coalesce unique services that produce messages and data exchanged within the architecture. Conceptually it is a ‘black box’ abstraction responsible for pro-ducing sets of messages.

• Domain Interface: common interfaces that are specified at domain boundaries that enable data to be produced by the domain.

• Message: a data grouping that aggregates uniquely related data elements to support the domain’s required services and are exchanged within the architecture at domain interfaces.

• WOSA Physical Module: a set of severable hardware containing one or more domains and has the following attributes:

• Has a definable hardware boundary

• The hardware can be severed from the system without removing any part of another physical module

• Can only contain full domains (i.e. When removed from the system, all assigned domains are completely removed)

• Exceptions to this rule:

• MDB, CLK

A WOSA Physical module (WPM) will typically identify a set hardware with a WOSA IO Boundary.

While this is not a requirement for a WPM, it is a guiding factor that can be used to more easily identify physical modules within a system.

• WOSA Logical Module: when removed from the system, all assigned domains are completely re-moved

• Has a definable hardware and/or software boundary

• The hardware and/or software can be severed from the system without removing any part of another logical module

• Can only contain full domains (i.e. When removed from the system, all assigned domains are completely removed)

• Exceptions to this rule:

• MDB, CLK

• Must be contained within a single physical module.

AWOSA LogicalModule (LM) identifies a set of hardware and softwarewithin a physical module that can be severed from the physical module or system. A LM would typically be a single domain or a set of domains that are coupled together in some way (cannot be separated/severed).

DISTRIBUTION D - Distribution authorized to the Department of Defense and U.S. DoD contractors only, contains critical technology, 6 July 2015. Refer other

September 2023

• WOSA Component: a severable hardware configuration item (HWCI) or computer software config-uration item (CSCI), contained within a single WOSA physical module or a WOSA logical module, lowest level replaceable item

• Severable Hardware and Software that make up a physical or logical module.

Typically a CSCI, or HWCI like a Circuit Card Assembly that contains a CSCI, and has an identifiable physical and electrical IO boundary.

• Severable/Severability: the capability to remove and replace amodule or component without hard-waremodification (physical, electrical, ormechanical) or source codemodification to any othermod-ule.

• Hardware interfaces typically made up of physical dimensions, connectors intended for elec-trical communication, and mechanical interactions (i.e. gears, rotors, solenoids)

• Severable software would typically be in the form of an executable, libraries, or script (i.e. .dll, .so, .exe, .sh, .py) Typically, a CSCI, or HWCI item like a Circuit Card Assembly that contains a CSCI, and has an identi-fiable physical and electrical IO boundary. Hardware configuration items often exists as circuit card assemblies (CCA), motors, rotors, solenoids, and other items that are tracked via configurationman-agement. Computer Software Configuration Items typically exist as a software package or product consisting of binaries, and input files that are tracked via configuration management.

• Service: A collective set of functional behaviors organized in a logical manner to accomplish specific requirements inherent to a domain’s behavior.

• Open Architecture: an architecture that is easier to add, upgrade, or change components through modular design that has:

– Open, consensus-based, published standards

– Standardized interfaces subject to verification and validation to ensure openness

– Anoverall systemdesign having standards and specifications that are available to domain providers on an equal-access basis for the purpose of interchangeable domains and ease of additions and upgrades.

– Third-party verification that standards are being met and documentation is complete

– Expertise in informed data-based decision making throughout implementation

• Produce and Consume: Amessaging pattern where producers (domains providing information) pro-vide a set of messages without knowledge of recipients, and consumers (domains/recipients con-suming information) consume data without knowledge of the producer. This can be done real-time

(dynamic reconfiguration) or at startup time (static…