20220310-CMOSS-IRS-v1-1-Dist-A-A518.pdf

A

PPR

O

VED

FO

R

PU

B

LIC

R

ELEA

SE

C M

O SS Interoperability

R equirem ents Specification v 1.1

C5ISR/EW Modular Open Suite of Standards (CMOSS) Interoperability Requirements Specification Version 1.1

JOSEPH D. WELCH

Director C5ISR Center

Controlled by:

Office of the MOSA Chief Engineer, MOSA Management Office (MMO) FCDD-ISE-FD

APPROVED FOR PUBLIC RELEASE

APPROVED FOR PUBLIC RELEASE

10 March 2022

Approved by:

JOSEPH D. WELCH

Director C5ISR Center

WILLIAM C. HOPPE

Associate Director, Science and Technology and Engineering

DONALD A. REAGO

Executive Director, Research and Technology Integration Directorate

MICHAEL C. MONTELEONE

Executive Director, Engineering and Systems Integration Directorate

Reviewed by:

SETH A. SPOENLEIN

Assistant Director, Systems Integration Portfolio

JOHN J. SOOS

Deputy Assistant Director, Prototyping, Integration & Testing

JOHN C. NILSEN

Project Manager, MOSA Management Office by:

JASON M. DIRNER

MOSA Chief Engineer, MOSA Management Office

WELCH.JOSEP

H.D.1241937905

Digitally signed by

WELCH.JOSEPH.D.1241937905

Date: 2022.03.10 10:19:12 -05'00'

HOPPE.WILLIAM.C

HARLES.10443874

Digitally signed by

HOPPE.WILLIAM.CHARLES.1044387464

Reason I concur and recommend approval Date 2022.03.08 15 42 32 -05'00'

REAGO.DONALD.

A.JR.1229634280

Digitally signed by

REAGO.DONALD.A.JR.1229634

Date: 2022.03.01 08:57:36 -05'00'

MONTELEONE.MIC

HAEL.C.127941312

Digitally signed by

MONTELEONE.MICHAEL.C.127

9413128 Date: 2022.02.23 15:13:37 -05'00'

SPOENLEIN.SET

H.A.1241431637

Digitally signed by

SPOENLEIN.SETH.A.124143163

Date: 2022.02.15 16:44:55 -05'00'

SOOS.JOHN.

J.1228923075

Digitally signed by

SOOS.JOHN J.1228923075

Date: 2022.01.26 08 21 29 -05'00'

NILSEN.JOHN.

C.1256161652

Digitally signed by

NILSEN.JOHN.C.1256161652

Date: 2022.01.24 15:08:39 -05'00'

DIRNER.JASON.MIC

HAEL.1369520500

Digitally signed by

DIRNER.JASON.MICHAEL.1369

520500 Date: 2022.01.24 15:06:25 -05'00'

ParentID UID Portion Marking

Content Type Strength

CMOSS0001 (U)

0BC5ISR/EW Modular Open Suite of Standards (CMOSS) Interoperability Requirements Specification (IRS)

Information

CMOSS0002 (U) Version 1.1 Information CMOSS0003 (U) Dated 20220310 Information CMOSS0004 (U) [Change Log Table.png] Information CMOSS0005 (U) Table 1 - Change Log Information

CMOSS0006 (U)

1BPurpose Information

CMOSS0007 (U) The purpose of the CMOSS Interoperability Requirements Specification is to provide a common, configuration-controlled, Science, Technology, Engineering, Experimentation, Test & Evaluation and Acquisition minimum baseline technical requirements document. This allows US Army (T), and Joint, Interagency, Intergovernmental, Multinational (JIIM) (O), materiel developers and integrators to ensure CMOSS compliant/conformant solutions are over-the-interface(s)-interoperable with other components/systems developed to the same "shalls". This document also addresses the need for the US Army (T), and JIIM (O), to have a mechanism to codify critical, Government interoperability design choices at the 'speed of relevance', in the event that public-private consortium governance processes/timelines would negatively impact Army Modernization. It also allows the Government to add additional specificity above and beyond consortium-based standards in order to achieve the portability and reuse objectives of the US Army. Although there are significant benefits from leveraging Public-Private consortium-based open standards approaches, the Government must always maintain the ability to make and coordinate inherently Governmental decisions in the best interests of the Warfighter. The requirements within this document should be incorporated by reference in contracts, citing the document title, revision number, and effective date of publication.

'CMOSS#####' Unique Identifiers (UID) will typically be linked as 'parent requirements' from which materiel system, subsystem, component, etc. 'child requirements' are derived. This CMOSS Interoperability Requirements Specification is under the configuration control of the chartered C5ISR Center MOSA Management Office (MMO).

Information

CMOSS0008 (U)

2BBackground Information

Content Type Strength

CMOSS0009 (U) In January 2019, the secretaries of the Army, Navy, and Air Force signed a memo entitled, “Modular Open Systems Approaches (MOSA) for our Weapon Systems is a Warfighting Imperative,” directing MOSA standards to be included in all requirements, programming, and development activities for future weapon system modifications and new-start development. This direction was reinforced by the House Armed Services Committee report for the FY21 National Defense Authorization Act, which recommended that “CMOSS and SOSA military electronics standards be more tightly connected to use the same hardware pinout standards and, more importantly, the same software data transport protocols, such as the Modular Open RF Architecture (MORA), to further solidify a common Department of Defense-wide technical approach to create an open systems architecture standard by which small businesses and large primes can compete”.

Information

CMOSS0010 (U)

3BCapability Overview and Benefits Information

CMOSS0011 (U) The Command, Control, Computers, Communications, Cyber, Intelligence, Surveillance and Reconnaissance (C5ISR) Center-developed and managed C5ISR/Electronic Warfare Modular Open Suite of Standards (CMOSS) delivers on that intent. This MOSA approach:

Information

CMOSS0011 CMOSS0012 (U) •Reduces the size, weight and power (SWaP) footprint of C5ISR systems by enabling integration and hardware sharing for communications, position, navigation and timing (PNT), mission command, and electronic warfare (EW) capabilities.

Information

CMOSS0011 CMOSS0013 (U) •Allows for rapid technology insertion to keep pace with emerging needs, permitting capabilities that are innovative, yet unanticipated, to be quickly implemented using well-defined components with open interfaces. The components are commonly referred to as “cards” and “radioheads”.

Information

CMOSS0014 (U) CMOSS consists of the following suite of layered standards that are individually useful and can be combined to form a holistic converged architecture:

Information

CMOSS0014 CMOSS0015 (U) •Network-based interoperability to enable sharing of services, such as time and position. Information CMOSS0014 CMOSS0016 (U) •Hardware form factor to enable capability fielding using cards in a common chassis. Information CMOSS0014 CMOSS0017 (U) •Functional decomposition to allow for sharing of resources, such as antennas and amplifiers. Information CMOSS0014 CMOSS0018 (U) •Software frameworks to enable portability of software applications. Information

Content Type Strength

CMOSS0019 (U) Information

CMOSS0020 (U) Figure 1 - Layered Standards Information CMOSS0021 (U) The overall approach has been referred to as the "Universal A-Kit," where platforms come with one or more standard chassis and are already plumbed for power, networks, and radio frequency (RF) distribution. Hardware for capabilities such as communications, PNT, mission command, and EW can then be fielded in the form of cards physically inserted in a common chassis and radioheads bolted to standard mount points.

Information

CMOSS0022 (U) CMOSS has the potential to significantly reduce costs over the lifecycle of a system. Information CMOSS0023 (U) Logistics tails can be smaller due to common spares. Information CMOSS0024 (U) Unit costs can be reduced due to greater competition among vendors and economies of scale. Information CMOSS0025 (U) Sustainment organizations can avoid purchasing spares intended to last 30+ years and instead perform modernization by upgrading to the latest hardware as components are replaced.

Information

Content Type Strength

CMOSS0026 (U) Information

CMOSS0027 (U) Figure 2 - The image above represents a notional portrayal of a Next Generation Optionally Manned Fighting Vehicle featuring a CMOSS-based chassis and capability cards.

Information

CMOSS0028 (U)

4BCMOSS Requirements Information

CMOSS0029 (U) The following describes the CMOSS requirements for systems and associated components. Information CMOSS0030 (U) CMOSS supports systems ranging in scale from a fully integrated platform to a dismounted manpack chassis. Information CMOSS0031 (U) Examples of components within systems include chassis, transceiver cards, single board computers, timing cards, radioheads, and C5ISR applications.

Information

CMOSS0032 (U)

5BVehicular Integration for C4ISR/EW Interoperability (VICTORY) Information

CMOSS0033 (U) Background: The Vehicular Integration for C4ISR/EW Interoperability (VICTORY) initiative was started as a way to correct the problems created by the "bolt-on" approach to fielding equipment on US Army vehicles.

Information

CMOSS0034 (U) Implementation of VICTORY allows tactical platforms and systems to recover lost space while reducing weight and saving power.

Information

CMOSS0035 (U) Additionally, implementation allows platform systems to share information and provide an integrated picture to the crews. Information

Content Type Strength

CMOSS0036 (U) Finally, implementation provides an open architecture that will allow platforms to accept future technologies without the need for significant re-design.

Information

CMOSS0037 (U) Under the initiative, a framework for integration of C4ISR/EW and other electronic mission equipment on tactical platforms continues to be developed.

Information

CMOSS0038 (U) Additional information is available at DI2E (https://di2e.net/). Information CMOSS0039 (U) Systems, when in a vehicle mounted configuration, shall implement a VICTORY Data Bus that complies with the following

VICTORY specifications:

Threshold shall

CMOSS0039 CMOSS0040 (U) a. Switch <VT50900-V1.9> to provide core network transport. Threshold shall CMOSS0039 CMOSS0041 (U) b. Shared Processing Unit <VT51900-V1.9> to host portable software. Threshold shall CMOSS0039 CMOSS0042 (U) c. VDB Management Service <VT52200-V1.9> to enable basic network management functions. Threshold shall CMOSS0039 CMOSS0043 (U) d. Support a minimum 10/100 Base-T Ethernet interface as specified in VICTORY <VT52303-V1.2> and <VT52101-V1.9>. Threshold shall

CMOSS0044 (U) All systems and components shall implement services to receive/consume external PNT data from authorized source such as PNT Mounted system.

Threshold shall

CMOSS0044 CMOSS0045 (U) All systems and components shall comply with the following VICTORY specifications: Threshold shall CMOSS0045 CMOSS0046 (U) a. Position Service (POS) <VT50100-V1.9> whenever position data is required. Threshold shall CMOSS0045 CMOSS0047 (U) b. Time Synchronization Service <VT50000-V1.7> with Precision Time Protocol (PTP) per VICTORY <VT50001.T2-V1.7> or

Network Time Protocol (NTP) per VICTORY <VT50001.T1-V1.4> whenever time synchronization is required.

Threshold shall

CMOSS0045 CMOSS0048 (U) c. Orientation Service <VT50200-V1.9> whenever orientation data is required. Threshold shall CMOSS0045 CMOSS0049 (U) d. Direction of Travel Service <VT50300-V1.9> whenever direction of travel (heading) data is required. Threshold shall

CMOSS0050 (U) Position, Navigation, and Timing (PNT) systems shall implement services to distribute PNT data for other client systems’ consumption:

Threshold shall

CMOSS0050 CMOSS0051 (U) a. Position Service (POS) <VT50100-V1.9> Threshold shall CMOSS0050 CMOSS0052 (U) b. Time Synchronization Service <VT50000-V1.7> Threshold shall CMOSS0050 CMOSS0053 (U) c. Orientation Service <VT50200-V1.9> Threshold shall CMOSS0050 CMOSS0054 (U) d. Direction of Travel Service <VT50300-V1.9> Threshold shall

CMOSS0055 (U) PNT systems shall implement the following services to enable remote management & control functions: Threshold shall CMOSS0055 CMOSS0056 (U) a. Global Positioning Service (GPS) Receiver < VT61000-V1.9> Threshold shall CMOSS0055 CMOSS0057 (U) b. Assured PNT <VT61600-V1.9> Threshold shall

CMOSS0058 (U) Tactical radios shall implement Data Radio <VT60800-V1.9> and Legacy Radio <VT60200-V1.9> to enable remote management & control functions.

Threshold shall

Content Type Strength

CMOSS0059 (U) Electronic Warfare (EW) and Signals Intelligence (SIGINT) systems shall implement Electronic Warfare Device <VT60900-V1.9> to enable remote management & control functions.

Threshold shall

CMOSS0059 CMOSS0060 Note that the Electronic Warfare Device component type will be deprecated in the future as the corresponding functionality will be provided by additional MORA Processing Resource component types.

Information

CMOSS0061 (U)

6BModular Open RF Architecture (MORA) Information

CMOSS0062 (U) Background: MORA extends VICTORY to support radio frequency (RF) systems. Information CMOSS0063 (U) MORA decomposes monolithic radio systems into high-level devices with well-defined functions and interfaces. Information CMOSS0064 (U) Devices include Software Defined Radios (SDRs), RF Conditioning and Distribution (RCD), and Radioheads (RHDs). Information CMOSS0065 (U) Additional information is available at DI2E (https://di2e.net/). Information CMOSS0066 (U) Please refer to “MORA DI2E Instructions” to request access to the MORA project on DI2E. Information CMOSS0067 (U) Systems shall comply with the MORA functional decomposition and interfaces. Threshold shall CMOSS0068 (U) Components containing signal resources such as but not limited to amplifiers, antennas, filters and switches shall implement the MORA Device <MT92010-V2.4> interfaces as specified in the MORA Specification.

Threshold shall

CMOSS0069 (U) Components containing signal resources such as but not limited to amplifiers, antennas, filters and switches shall implement the MORA Signal Resource Manager <MT92013-V2.4> interfaces as specified in the MORA Specification.

Threshold shall

CMOSS0070 (U) Components containing signal resources such as but not limited to amplifiers, antennas, filters and switches shall implement the MORA Signal Port Manager <MT92016-V2.4> interfaces as specified in the MORA Specification.

Threshold shall

CMOSS0071 (U) MORA interfaces shall include all required specifications as well as any optional specifications that correspond to functionality provided by the component.

Threshold shall

CMOSS0072 (U) Cascaded signal resources on different components shall communicate exclusively using MORA standard interfaces. Threshold shall CMOSS0072 CMOSS0073 (U) Signal resources shall be discovered and allocated over the VICTORY Data Bus (VDB). Threshold shall CMOSS0072 CMOSS0074 (U) Signal resources shall be controlled over the MORA Low Latency Bus (ML2B). Threshold shall

CMOSS0075 (U) Applications and processing resources shall interface with signal resources exclusively using MORA standard interfaces. Threshold shall CMOSS0075 CMOSS0076 (U) Signal resources shall be discovered and allocated over the VDB. Threshold shall CMOSS0075 CMOSS0077 (U) Signal resources shall be controlled over the ML2B. Threshold shall

CMOSS0078 (U) Systems and components should implement separate domains where the VDB is Domain 1 and the ML2B is Domain 2. Objective should

CMOSS0079 (U)

7BOpenVPX Information CMOSS0080 (U) Background: OpenVPX is a Backplane standard that uses serial fabrics with a high density connector, coupled with a systems level approach that defines standard profiles for pins, protocols, and interconnections.

Information

CMOSS0081 (U) Additional information is available at http://www.vita.com/ and http://www.opengroup.org/sosa Information

Content Type Strength

CMOSS0082 (U) Systems shall contain an OpenVPX chassis with modular hardware resources that complies with the slot and module profiles in this specification to facilitate interoperability with cards developed by third-party vendors.

Threshold shall

CMOSS0082 CMOSS0083 (U) System should use 3U OpenVPX whenever possible. Objective should CMOSS0084 (U) Systems and components shall use the Control Plane for the VICTORY Data Bus (VDB) and the Data Plane for the MORA Low

Latency Bus (ML2B).

Threshold shall

CMOSS0085 (U) Systems and components should implement separate domains on the backplane and plug-in cards where the Control Plane and Expansion Plane are Domain 1, while the Data Plane and Utility Plane are Domain 2.

CMOSS0086 (U) 3U payload cards such as RF transceivers that require RF connections shall comply with a slot profile of SLT3-PAY- 1F1U1S1S1U1U2F1H-14.6.11-4 as defined in ANSI/VITA 65.0, and shall have an Alternate Module Profile Scheme (AMPS) string that conforms to Table 2.

Threshold shall

CMOSS0086 CMOSS0087 (U) Connections on the front of these payload cards shall only be used for key fill and maintenance. Threshold shall CMOSS0088 (U) RF connections shall comply with the coaxial pin assignment in Figure 3. Threshold shall CMOSS0089 (U) 3U payload cards such as single board computers (SBCs) and general-purpose graphics processing units (GPGPUs) that don’t require RF connections shall comply with a slot profile of SLT3-PAY-1F1U1S1S1U1U2F1H-14.6.11-0 as defined in ANSI/VITA 65.0, and shall have an AMPS string that conforms to Table 2.

Threshold shall

CMOSS0089 CMOSS0090 (U) Connections on the front of these payload cards shall only be used for key fill and maintenance. Threshold shall CMOSS0091 (U) 3U payload cards that require standard I/O such as USB, DisplayPort, and serial ports or are intended to be used for system-specified interfaces shall comply with a slot profile of SLT3-PAY-1F1F2U1TU1T1U1T-14.2.16 as defined in ANSI/VITA 65.0, and shall have an Alternate Module Profile Scheme (AMPS) string that conforms to Table 2.

Threshold shall

CMOSS0091 CMOSS0092 (U) Connections on the front of these payload cards shall only be used for key fill and maintenance. Threshold shall CMOSS0093 (U) Systems that require more system-specific interfaces than can be accommodated by 14.2.16 may use a dedicated external I/O card. This card shall comply with a slot profile of SLT3-PAY-2U2U-14.2.17 as defined in ANSI/VITA 65.0, and shall have an Alternate Module Profile Scheme (AMPS) string that conforms to Table 2.

Threshold shall

CMOSS0093 CMOSS0094 (U) Connections on the front of these payload cards shall only be used for maintenance. Threshold shall CMOSS0095 (U) 3U Ethernet switch cards shall comply with a slot profile of SLT3-SWH-6F1U7U-14.4.14 or SLT3-SWH-4F1U7U1J-14.8.7-n as defined in ANSI/VITA 65.0, and shall have an AMPS string that conforms to Table 3.

Threshold shall

CMOSS0095 CMOSS0096 (U) Connections on the front of Ethernet switch cards shall only be used for external Ethernet connections, key fill, and maintenance.

Threshold shall

CMOSS0097 (U) 3U PCIe/Ethernet switch cards shall comply with a slot profile of SLT3-SWH-6F8U-14.4.15 as defined in ANSI/VITA 65.0, and shall have an AMPS string that conforms to Table 3.

Threshold shall

CMOSS0097 CMOSS0098 (U) Connections on the front of PCIe/Ethernet switch cards shall only be used for maintenance. Threshold shall

Objective should

CMOSS0086

Content Type Strength

CMOSS0099 (U) 6U payload cards such as RF transceivers that require RF connections shall comply with a slot profile of SLT6-PAY- 4F2Q1H4U1T1S1S1TU2U2T1H-10.6.4-2 as defined in ANSI/VITA 65.0, and shall have an AMPS string that conforms to Table 13.3.4-2 in SOSA Technical Standard Edition 1.0.

Threshold shall

CMOSS0099 CMOSS0100 (U) Connections on the front of these payload cards shall only be used for key fill and maintenance. Threshold shall CMOSS0099 CMOSS0101 (U) RF connections shall comply with the coaxial pin assignment in Figure 3. Threshold shall

CMOSS0102 (U) 6U payload cards such as SBCs and GPGPUs that don’t require RF connections shall comply with a slot profile of SLT6-PAY- 4F2Q1H4U1T1S1S1TU2U2T1H-10.6.4-0 as defined in ANSI/VITA 65.0, and shall have an AMPS string that conforms to Table 13.3.4-2 in SOSA Technical Standard Edition 1.0.

Threshold shall

CMOSS0102 CMOSS0103 (U) Connections on the front of payload cards shall only be used for key fill and maintenance. Threshold shall CMOSS0104 (U) 6U Ethernet switch cards shall comply with a slot profile of SLT6-SWH-14F16U1U15U1J-10.8.1-n as defined in ANSI/VITA 65.0, and shall have an AMPS string that conforms to Table 13.3.5-1 in SOSA Technical Standard Edition 1.0.

Threshold shall

CMOSS0104 CMOSS0105 (U) Connections on the front of Ethernet switch cards shall only be used for external Ethernet connections, key fill, and maintenance.

Threshold shall

CMOSS0106 (U) Timing cards shall comply with a slot profile of SLT3x-TIM-2S1U22S1U2U1H-14.9.2-1 as defined in ANSI/VITA 65.0, and shall have an AMPS string that conforms to Table 2.

Threshold shall

CMOSS0106 CMOSS0107 (U) Connections on the front of timing cards shall only be used for key fill and maintenance. Threshold shall CMOSS0108 (U) Switch cards shall support auto-negotiation and fixed rates. Threshold shall CMOSS0109 (U) Non-switch cards should support auto-negotiation and fixed rates. Objective should CMOSS0110 (U) All cards shall only use the following power inputs from the backplane: 12 VDC (Vs1), 3.3V_AUX, and VBAT. Threshold shall CMOSS0111 (U) Payload cards and timing cards shall support a 100 MHz REF_CLK and 1 PPS AUX_CLK that are distributed radially over the backplane.

Threshold shall

CMOSS0112 (U) All cards shall zeroize when GDiscrete1 is asserted. Threshold shall CMOSS0113 (U) All cards shall be Type 1, 1.0 in. pitch conduction cooled plug-in units per ANSI/VITA 48.2 or Type 1, 1.5 in. pitch air flow through plug-in units per ANSI/VITA 48.8 to support 2 Level Maintenance.

Threshold

CMOSS0113 CMOSS0114 (U) Cards should use ANSI/VITA 48.2 whenever possible. Objective should CMOSS0115 (U) Systems should conform to the Out-of-Band Hardware Management Definitions within the Sensor Open Systems Architecture

(SOSA TM) Technical Standard whenever possible.

Objective should

CMOSS0115 CMOSS0116 (U) These requirements can be found in Section 6.4 (Out-of-Band Hardware Management Definitions) of SOSA Technical Standard Edition 1.0 and are based on the Hardware Open Systems Technology (HOST) and ANSI/VITA 46.11 standards.

Information

CMOSS0117 (U) All cards shall conform to the plug-in card specifications within the Sensor Open Systems Architecture (SOSA TM) Technical Standard that don’t conflict with requirements within this document.

Threshold shall

CMOSS0117 CMOSS0118 (U) These requirements can be found in Section 13 (Hardware Element) of SOSA Technical Standard Edition 1.0. Information shall

Content Type Strength

CMOSS0119 (U) In the case of a conflict, this document shall supersede the SOSA TM Technical Standard. Threshold shall CMOSS0120 (U) Threshold shall

CMOSS0121 (U) Figure 3 - 3U Payload Card Coaxial Pin Assignment Information

CMOSS0122 (U) Threshold shall

Content Type Strength

CMOSS0123 (U) Table 2 - AMPS Strings for 3U Payload Plug-In Card Profiles (adapted from Table 13.3.4-1 in SOSA Technical Standard Edition 1.0)

Information

CMOSS0124 Threshold shall

CMOSS0125 (U) Table 3 - AMPS Strings for 3U Switch Plug-In Card Profiles (adapted from Table 13.3.5-1 in SOSA Technical Standard Edition 1.0) Information

CMOSS0126 (U)

8BSoftware Frameworks Information CMOSS0127 (U) Background: Software frameworks enable portability of applications between hardware platforms. Information CMOSS0128 (U) CMOSS leverages prominent software frameworks within each mission area to maximize reuse of existing software capabilities. Information CMOSS0129 (U) Software frameworks can be integrated with underlying specifications such as VICTORY and MORA which provide standard interfaces to sensors and services on the platform.

Information

CMOSS0130 (U) Additional information is available at https://redhawksdr.github.io/Documentation/, http://www.public.navy.mil/jtnc/, and http://www.opengroup.org/face/.

Information

CMOSS0131 (U) Systems shall implement applications within REDHAWK/TOA, SALVAGE, X-Midas, Photon, Software Communications Architecture (SCA), and/or Future Airborne Capability Environment (FACE) when appropriate.

Threshold shall

CMOSS0132 (U) Where existing Government frameworks are determined to be insufficient for a required application, such as in cases where hardware acceleration is used, the contractor shall document the design choices and provide the explanation to the Government for their concurrence.

Threshold shall

Content Type Strength

CMOSS0133 (U) The contractor shall deliver a Software Development Kit (SDK) or Integrated Development Environment (IDE) to facilitate development and deployment of applications for lower level processing hardware, such as hardware accelerators, that may not be covered by existing Government frameworks.

Threshold shall

CMOSS0134 (U)

9BMechanical and Electrical Interfaces Information

CMOSS0135 (U) Background: The Sensor Open Systems Architecture (SOSA TM) Technical Standard defines standard mounts and connectors in order to facilitate platform integration and maximize cable reuse.

Information

CMOSS0136 (U) Additional information is available at http://www.opengroup.org/sosa/. Information CMOSS0137 (U) Systems should conform to the mechanical and electrical specifications within the SOSA TM Technical Standard whenever possible.

should

CMOSS0138 (U) These requirements can be found in Section 13.5 (SOSA Aperture and Chassis Electrical and Mechanical Interface Standard) of SOSA Technical Standard Edition 1.0.

Information

CMOSS0139 (U) Reserved Information CMOSS0140 (U) Reserved Information CMOSS0141 (U) Reserved Information CMOSS0142 (U) Reserved Information CMOSS0143 (U) Reserved Information CMOSS0144 (U) Reserved Information

Auto-generated from Authoritative Source: https://armyeitaas.sharepoint-mil.us/teams/MMO/Lists/cmossIRS/

Data is valid as of: 2021-12-08_1627EST

Objective