Picatinny_CLIK_1760580463_Distro A.pdf

PDF 2 MB Posted

Attached to
Uncrewed Aerial System (UAS) Munition Payload Interface Solution - Sources Sought
Solicitation number
W15QKN-26-X-1B5A
Issued by

About this file

This is a Design Standard document for the Picatinny Common Lethality Integration Kit (CLIK), an open architecture platform agnostic system developed by Combat Capabilities Development Command (DEVCOM) Armaments Center to enable rapid integration and interoperability of modular lethal and non-lethal payloads on Unmanned Aerial Systems (UAS). The standard addresses the need to minimize integration burden across UAS platforms with shorter lifecycle expectations and more frequent technological upgrades.

The standard establishes four integration levels progressing from physical-only interface (Level 1) through power integration (Level 2), communications integration (Level 3), and full sensor integration (Level 4, not yet fully described). Key technical specifications include: Picatinny rail-based mechanical mounting per MIL-STD-1913 with minimum 5-inch lengths spaced 5 inches on-center; 28-volt DC power supply with 250 milliamp CPU (CLIK Power Unit) definition and maximum 10-amp connector current limit; standardized connector options (801, 2M801, or MD801 series with 9-19 pin arrangement); optional Ethernet (IEEE 802.3u 100BASE-TX) and required RS232 serial interfaces at 115,200 bps; and dedicated safety discretes for arm and fire functions with isolation requirements per IEC standards. Payloads are defined in CLIK Units (1CU nominally 4.25" W x 12.75" L x 1" H) and must implement overcurrent protection, maximum weight/power labeling per MIL-STD-130N, and toolless installation capability. The platform must provide regulated power distribution, network switching, safety signal isolation, and overcurrent protection across multiple payload channels. Communication protocols are based on a standardized message format with error codes, supported across UDP and serial interfaces. The standard references existing architectures including MOD Payload and small Universal Payload Interface (sUPI) for smaller platforms, with sUPI addendum planned for future revision.

View the file

Other files

File Type Posted
sUPI_Platform_Brief_Distro A.pdf PDF
sUPI_Payload_Brief_Distro A.pdf PDF

On GovTribe

Work with this file

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

UNCLASSIFIED

Design Standard for Picatinny CLIK

DISTRIBUTION STATEMENT A: Approved for public release: distribution unlimited

DESIGN STANDARD

FOR

Picatinny Common Lethality Integration Kit (CLIK)

DISTRIBUTION STATEMENT A: Approved for public release: distribution unlimited.

POC: Daniel DiMartino, daniel.f.dimartino.civ@army.mil

DOCUMENT ORIGIN AND APPROVAL RECORD

Prepared by: ______________________________ Date: _____________

<name>, Engineer – DEVCOM-Armaments Center

Prepared by: ______________________________ Date: _____________

Reviewed by: _______________________________ Date: _____________

Reviewed by: _______________________________ Date: _____________

Approved by: _______________________________ Date: _____________

<name>, TBD – Project Manager Close Combat Systems (PM CCS)

REVISION STATUS

Revision Date Notes Approved X- 2024-

10-17 PRE-PRODUCTION RELEASE

XC-

working

2025- 04-25

Version 2 Working Copy. Revised from Interface Control Document to Design Standard.

2.1 2025- 09-17

Interim Release: Updates/Refinements based on comments and working group meetings.

Contents

1. Scope

1.1. Purpose

1.2. System Overview

1.3. Picatinny CLIK Integration Level Approach

2. Applicable Documents

2.1. Government Documents

2.2. Non-Government Documents

3. Payload Requirements

3.1. Mounting/Physical Interface

3.1.1. Picatinny Rail

3.1.2. Picatinny Rail Bracket Accessory

3.1.3. Picatinny Rail Bracket Marking Identifier

3.1.4. CLIK Unit

3.1.5. Picatinny CLIK Ecosystem

3.1.6. Payload Human Factors

3.1.7. Identification Markings

3.2. Power and Signal Interface

3.2.1. Payload Connector

3.2.2. Connector Placement

3.2.3. Connector Pinout

3.2.4. Power

3.2.5. Ethernet

3.2.6. Serial

3.2.7. Function Channels

3.2.8. Safety Discretes

3.2.9. Loopback

3.2.10. Chassis

4. Platform Requirements

4.1. Mounting/Physical Interface

4.1.1. Picatinny Rail Markings

4.1.2. Picatinny CLIK Array

4.1.3. Identification Markings

4.2. Power and Signal Interface

4.2.1. Platform Interface

4.2.2. Payload Channels

4.2.3. Grounding

4.3. Platform to Payload Cabling

4.3.1. Cable Connectors

4.3.2. Power

4.3.3. Ethernet

4.3.4. Serial

4.3.5. Safety Discretes

4.3.6. Loopback

5. Communication Protocol Requirements

5.1. Common Message Protocol Format

5.2. Payload Serial Protocol

5.2.1. Get Payload Status

5.2.2. Get Payload Identifier

5.2.3. Get Payload System Config

5.2.4. Get Payload Network Config

5.2.5. Set Function State

5.2.6. Set Payload Network Config

5.2.7. Set Payload Network State

5.3. PI UDP Protocol

5.3.1. Get PI Status

5.3.2. Get Platform Identifier

5.3.3. Get Platform System Config

5.3.4. Get Platform Network Config

5.3.5. Set Platform Power

5.4. Payload Channel UDP Protocol

5.4.1. Get Payload Channel Status

5.4.2. Get Payload Channel Power Config

5.4.3. Set Payload Channel Power

5.4.4. Set Payload Channel Current Limit

Appendix A Acronyms and Abbreviations

Figures

Figure 1 – Picatinny CLIK Domain Context Figure 2 – Notional Bracket Accessory Figure 3 - Picatinny CLIK 1 CU Nominal Space Claim Example Figure 4: CLIK Unit Example for payload height in inches Figure 5 – Single Picatinny CLIK Ecosystem Package Unit Figure 6 – Payload Clearances Figure 7 – Notional Multiple rail adapter Figure 8 – Mult-Picatinny CLIK Array (2x3CU) Figure 9 - Picatinny CLIK Ecosystem Package Even Array (2x2CU) Figure 10 – Dual Rail Required Clearances Figure 11 - Picatinny CLIK Ecosystem Pkg Odd Array (3x3CU) Figure 12 - Picatinny Rail layout when carrying a single long item “as shown in blue” Figure 13: Receptacle Connector Typical Mounting Options Figure 14: Payload Connector Insert Arrangement Figure 15: Connector Keying Figure 16: Payload Connector location (notionally on payload backplane) Figure 17 – Notional Payload Safety Circuit Figure 18 - Picatinny Rail w/centerline & defined GO & NO-GO markings, viewable thru Notional window design Figure 19 - Picatinny Rail longer than the min 5.0” w/centerline & defined GO & NO-GO markings viewable thru Notional window design Figure 20 – Picatinny CLIK Functional Architecture Figure 21 –Notional Network Devices (Expanded) Figure 22 –Notional Network Devices (Condensed) Figure 23 –Platform Interface Functions Figure 24 –Payload Channel Functions Figure 25: Platform to Payload Cables Figure 26: Plug Connector Series Options

TABLES

Table 1: Government Documents Table 2: Non-Government Documents Table 3: Approved Payload Connectors Table 4: Approved Manufacturer’s Connectors Series Table 5: Approved Connector Class Series Table 6: Shell Style Options Table 7: Approved Connector Material/Finish Table 8: Payload Connector Pinout Table 9: Picatinny CLIK IP/Port Pairs Table 10: Approved Options for Platform Connectors Table 11 Approved Options for Cable Connectors Table 12: Approved Connector Series Table 13: Shell Style Options Table 14: Message Structure Table 15: Response Error Codes Table 16: Payload Serial Message Identifiers Table 17: Payload Status Response Data Structure Table 18: Payload Status Bit Fields Table 19: Payload Identifier Response Data Structure Table 20: Payload System Config Response Data Structure Table 21: Get Payload Network Config Table 22: Payload Get Network Config Response Data Structure Table 23: Set Payload Function State Receive Data Structure Table 24: Set Payload Network Config Receive Data Structure Table 25: Set Payload Network State Receive Data Structure Table 26: PI UDP Protocol Table 27: PI Status Response Data Structure Table 28: Platform Status Bit Fields Table 29: Get Platform Identifier Table 30: Platform System Config Response Data Structure Table 31: Get Platform Network Config Table 32: Payload Get Network Config Response Data Structure Table 33: Set Platform Power Receive Data Structure Table 34: PI UDP Message Identifiers Table 35: Payload Channel Response Status Data Structure Table 36: Payload Channel Status Bit Fields Table 37: Payload Channel Power Config Response Data Structure Table 38: Payload Channel Power Option Bit Fields Table 39: Set Platform Power Receive Data Structure Table 40: Set Payload Channel Current Limit Receive Data Structure

DISTRIBUTION STATEMENT A: Approved for public release: distribution unlimited

1. SCOPE

1.1. PURPOSE

Rapid proliferation of Unmanned Aerial Systems (UAS) at all echelons of combat operation has introduced new capabilities for the Warfighter to deliver decisive overmatch and obtain freedom of maneuver across multiple domains. The pace of technology of UAS far exceeds any legacy military platform and associated acquisition lifecycle. UAS lifecycles will trend shorter with greater and more frequent technological platform upgrades. To minimize burden of integration at each platform upgrade, modular lethal payloads must have a common interface and architecture for attachment, power, communication, and safety critical commands. The desired end state is seamless interoperability of the UAS, the modular lethal payload, and the ground station controller.

Combat Capabilities Development Command (DEVCOM) Armaments Center (AC) is developing a platform agnostic, Picatinny Common Lethality Integration Kit (CLIK) to weaponize low-cost, attritable UAS. The purpose of this standard is to minimize the proliferation of physical and electronic interface standards on the UAS and the proliferation of physical and electronic interface standards on the payloads. The goal is to enable a soldier to move, mix and match different payloads on different platforms, without requiring a certification for each combination.

This document provides the base concepts, architectures, requirements, and overview for defining the required interoperability of Picatinny CLIK Ecosystem of packaged payloads.

This document has been developed with existing reference architectures such as the Modular Payload Design Standard (MOD Payload) and small universal payload interface (sUPI) in mind. The intent is for this document to augment existing reference architectures with a focus on lethality integration and interoperability. Additionally, airworthiness and system safety certifications have influenced the standard with the intent to reduce burden associated with those certifications both to the user and to the developers.

1.2. SYSTEM OVERVIEW

This document specifies interoperability concepts, architecture, and requirements associated with integrating unmanned systems and lethal/nonlethal payloads. The capabilities addressed within this design standard relate primarily to lethal/nonlethal weapon payload interoperability with respect to payload integration, operation, control and status. To the degree possible, capabilities have been broken down into subsets to cover integration of specific interfaces/technologies associated with the integration of lethal payload technology.

A payload is a physical device that interfaces to the UAS. A payload can be similar in nature to other devices that are integrated on a UAS platform, but a payload is not required for native UAS capabilities. Frequently payloads are integrated into the platforms in a very specific way which isn’t always transferable to other platforms using physical, power, and data interfaces. CLIK will define where the boundary between platform and payload exists permitting rapid integration as well as interoperability. Modular and interchangeable payloads will enable warfighters to select the most efficient effect based on mission needs.

Figure 1 depicts a notional diagram for the domain context that Picatinny CLIK supports.

Figure 1 – Picatinny CLIK Domain Context

1.3. PICATINNY CLIK INTEGRATION LEVEL APPROACH

The Picatinny CLIK Ecosystem has a tiered (i.e. phased) approach to the capabilities it provides. There are four integration levels. However, at this time, the design standard is focused on integrating Picatinny CLIK to platforms in active prototype and experiment with DoD components and does not fully describe Integration Level 4, the highest level of integration. The intent of integration level approach is to augment and assist Airworthiness configuration certifications in the future.

Integration Level 1 Integration: In this initial phase, Picatinny CLIK provides a physical interface only for Payload System connecting to the rail(s). The Payload System has all the subsystems (which may include communications, power, sensors, command and control) required for full operation with no dependence on the Platform including its own Ground Control Station.

Integration Level 2 Integration: In this second level, the Picatinny CLIK provides a power interface between the Platform and Payload systems that can be used. The Payload system would still maintain its own Ground Station.

Integration Level 3 Integration: In this third level, the Picatinny CLIK adds interfaces for communications (i.e. Radio, Command and Control (C2)) between the Platform System to the Payload System that can be used. The payload C2 software would be integrated on the Platform Ground Control Station.

Integration Level 4 Integration: In this fourth phase (which is not fully described in this design standard at this time), the Picatinny CLIK adds interfaces for sensors between the platform to the payload system that can be used. This would be the full integration and interoperability of the Payload and Platform Systems. The Payload system may contain its own sensors as desired (to increase accuracy or supplement Platform sensors).

2. APPLICABLE DOCUMENTS

2.1. GOVERNMENT DOCUMENTS

MIL-STD-1913 Dimensioning of Accessory Mounting Rail for Small

Arms Weapons

MIL-HDBK-338B Electronic Reliability Design Handbook

MIL-STD-464D

Electromagnetic Environmental Effects Requirements for Systems

MIL-STD-1472H Human Engineering

MIL-STD-882E Systems Safety

MIL-STD-130N Identification Marking of U.S. Military Property

MOD Payload A Modular Payload Design Standard Revision 6.1

Table 1: Government Documents

2.2. NON-GOVERNMENT DOCUMENTS

IEEE 802.3u IEEE Standard for 100BASE-T (Fast Ethernet) and 100BASE-FX (Fast Ethernet over Fiber)

IETF RFC 768 User Datagram Protocol (UDP) IETF RFC 4632 Classless Inter-Domain Routing (CIDR): The Internet

Address Assignment and Aggregation Plan EIA/TIA-232-F Interface Between Data Terminal Equipment and Data

Circuit-Terminating Equipment Employing Serial Binary Data Interchange

ANSI X3.4-1986 Coded Character Sets – 7-Bit American National Standard Code for Information Interchange (7-bit ASCII)

IEC 60747-5-5 Semiconductor devices – Part 5-5: Optoelectronic devices – Photocouplers

IEC 60747-17 Semiconductor devices – Part 17: Magnetic and Capacitive Coupler for Basic and Reinforced Insulation

Table 2: Non-Government Documents

3. PAYLOAD REQUIREMENTS

The following sections specify the mechanical, electrical, and protocol requirements for a Picatinny CLIK compliant payload. The majority of platforms will be able to support the mechanical, power and signal interface outlined for CLIK Payloads. Some platforms may require alternative mounting and electrical interfaces due to their size and mission profile.

The small Universal Payload Interface (sUPI) is the alternative for platforms constrained by low capacity for payload size, weight, and power needs. This interface is suitable for Short Range Reconnaissance (SRR) and Purpose Built Attritable System (PBAS) type aircraft with Picatinny CLIK compliant payloads. The initial sUPI and ecosystem components have been transitioned to DEVCOM AC for incorporation into Picatinny CLIK and will be an additional addendum in future revision.

3.1. MOUNTING/PHYSICAL INTERFACE

The physical interface requirements listed in this document describe which standards should be used. This does not ensure that a particular mounting(s) will support a payload, provide stable mounting, or provide the proper vehicle dynamic characteristics. It is the responsibility of the lead system integrator and payload developers to ensure that these characteristics are met, and pass testing, in a particular implementation.

3.1.1. PICATINNY RAIL

CLIK payloads shall be capable of mounting to a single rail or multiple rails in accordance with MIL-STD-1913. Connection coupler(s) of varying length not less than 5” in length and then 5” on-center (OC) from side to side up to the maximum width of the UAS mounting structure. The number of rails required to mount a payload is determined by the payload developers for proper payload mounting and spacing considerations. The payload must go through proper analysis of anticipated flight profiles and maneuvers. This data will need to be provided so that integrators can make informed decisions when integrating a payload onto a platform.

3.1.2. PICATINNY RAIL BRACKET ACCESSORY

The Picatinny CLIK interface brackets shall be compatible with MIL-STD-1913 type accessories and ideally toolless in design. If tools are required, a standard issue military multitool, such as a Leatherman pocket survivor tool or similar, is maximally allowed. It must have a redundancy feature for secondary means of attachment to ensure adequate clamp strength for static and dynamic loads, positive control and prevent dislodging or detaching during standard flight conditions. A notional example of a toolless bracket accessory is shown in Figure 2.

The Picatinny Rail Bracket Accessory shall have a maximum length of five inches.

Figure 2 – Notional Bracket Accessory

3.1.3. PICATINNY RAIL BRACKET MARKING IDENTIFIER

The minimum height of a Picatinny Rail is governed by MIL-STD-1913. The maximum height of the rail space claim on the payload is a 0.4” slot opening along the entire length to allow the payload bracket to be placed anywhere along the rail (see Figure 3).

3.1.3.1. MARKING

The mounting bracket shall incorporate a marking indicating the payload’s center of gravity (CG). This will permit integrators to align payload CG with the platform CG. For Platform marking requirements, see 4.1.1.

3.1.3.2. WEIGHT

The physical properties of the payload and mounting system must be described.

The payload connection system must withstand a maximum 5G acceleration in all directions during platform maneuvers.

3.1.4. CLIK UNIT

A CLIK Unit defines the base logical requirements for interoperability between a Payload System and a UAS Platform. Platforms possess finite resources related to weight, size, power, and data throughput. A CLIK Unit represents the expected boundary conditions for a single Payload System. While the physical dimensions of a CLIK Unit are expected to evolve as this design standard expands, the core principle remains consistent: to ensure interoperability.

1 CLIK Unit (1CU) nominally defined as 4.25” Wide, 12.75” Long and 1” High. A payload that exceeds these dimensions must be labeled as a WxLxH CLIK Unit Payload, where L defines the space claim along the length of the rail, W defines the space claim perpendicular to the rail and H defines the space away from the surface of the rail. For example, a payload 18” long, 3” High but within the standard width would be a 1x1.5x3CU Payload (round up to the nearest tenth of a CU).

The payload shall have a clearance of 1.0”x0.40” minimum center aligned at the top of the payload container as seen in Figure 3 to allow appropriate clearance for rail.

The required space claim for soldier access to notional bracket attachment mechanism is depicted in an example configuration in Figure 3 (will vary depending upon specific rail attachment method).

The payload shall come up with a launch and recovery platform or integrate a mechanism to permit launch and recovery into the payload if the payload volume is larger than the platform can support (i.e. provide legs or provisions for payload to sit on ground if platform legs are too short or nonexistant).

Figure 3 - Picatinny CLIK 1x1x8 CU Nominal Space Claim Example

Figure 4 shows a notional example of a CLIK Unit structure.

Figure 4: CLIK Unit Example for payload height in inches

3.1.5. PICATINNY CLIK ECOSYSTEM

3.1.5.1. SINGLE PICATINNY CLIK PAYLOAD

A CLIK Payload operating in standalone has greater flexibility of deployment than one that must operate with other CLIK Payloads (notional examples are shown in Figure 5 and Figure 6)..

Figure 5 – Single Picatinny CLIK Ecosystem Package Unit

Figure 6 – Payload Clearances

3.1.5.2. MULTI RAIL ADAPTER

When a Picatinny CLIK payload exceeds the platform’s single rail attachment capability a multiple rail approach is allowed to distribute loads across a greater number of rails. Shown in Figure 7 is a dual rail adapter with a mounting plate to be used on the standard 5” OC spacing, which may be the 5” minimum or continuous rail.

Figure 7 – Notional Multiple rail adapter

3.1.5.3. STANDARD GRID LAYOUT FOR MULTIPLE PICATINNY CLIK ARRAY LAYOUT

A CLIK Array is defined as a configuration consisting of two or more CLIK Payloads mounted in a defined grid pattern (suggested grid pattern; up to UAS to analyze whether they can conform to suggested or need an alternate configuration). This arrangement enables the integration of larger payloads or a compilation of smaller payloads. The figures that follow showcase notional examples of CLIK array configurations (Figure 8, Figure 9, Figure 10, Figure 11, and Figure 12).

Figure 8 – Mult-Picatinny CLIK Array (2x3CU)

Figure 9 - Picatinny CLIK Ecosystem Package Even Array (2x2CU)

Figure 10 – Dual Rail Required Clearances

UAS unladen center of gravity will always be marked (see Figure 11) on Picatinny rails to address mounting of a single Picatinny CLIK Pkg on a UAS which can mount multiple numbers of Picatinny CLIK payloads so that a balanced load reference location can be identified.

Figure 11 - Picatinny CLIK Ecosystem Pkg Odd Array (3x3CU)

Array configuration when using a barrel type weapon in conjunction with additional Picatinny CLIK pkgs (see Figure 12).

Figure 12 - Picatinny Rail layout when carrying a single long item “as shown in blue”

3.1.6. PAYLOAD HUMAN FACTORS

The Payload shall be installable onto the Picatinny CLIK System by the Soldier without the need for special tools.

The Payload shall be removable from the Picatinny CLIK System by the Soldier without the need for special tools.

All System operations regarding interfacing the Payload System to the Picatinny CLIK System performed by the Soldier shall be accomplishable when the Soldier is wearing tactical gloves.

If tools are required, a standard issue military multitool, such as a Leatherman pocket survivor tool or similar, is maximally allowed.

3.1.7. IDENTIFICATION MARKINGS

The Payload shall display a permanent identification plate with human readable text and Machine-Readable Information (MRI) in accordance with MIL-STD-130N. The identification plate shall include the following minimum information: manufacturer, part number, unique serial number, maximum payload weight in pounds to one decimal as MPW: XX.X, and maximum payload CLIK power units as MPC: XX (see 3.2.4).

3.2. POWER AND SIGNAL INTERFACE

The majority of CLIK Platforms and Payloads will be able to support or require the power and signals outlined in the following interface. Smaller UAS such as PBAS and SRR may implement the sUPI addendum. It is expected that a common ecosystem component will be developed to bridge the use of sUPI payloads with the outlined interface.

3.2.1. PAYLOAD CONNECTOR

A Picatinny CLIK payload shall integrate a single connector from the currently available options shown in Table 3 or a connector with identical form, fit, and function as detailed in sub sections below.

Series Class Shell Style Material/Finish Arrangement Contacts Keying

801 -009 -01 NF

9-19 P A 2M801 -02

-010 ZNU MD801 -07

Table 3: Approved Payload Connectors

3.2.1.1. SERIES

Picatinny CLIK Payload Connector shall be of the following Series options shown in Table 4.

Manufacturer CAGE Code Product Line Description Glenair, Inc. 06324 801 Mighty Mouse Double Start

Acme Thread

Amphenol Corp. 77820 2M801 Micro-Miniature Dual-Start Acme Thread

Cinch Connectivity Solution Inc. 34078 MD801 MD801 Dual-Start Acme

Thread Table 4: Approved Manufacturer’s Connectors Series

3.2.1.2. CLASS

Picatinny CLIK Payload Connector shall be of Receptacle Class Series options shown in Table 5.

Series Description -009 Receptacle with Banding Platform -010 Receptacle with Accessory Threads

Table 5: Approved Connector Class Series

3.2.1.3. SHELL STYLE (MOUNTING)

The approved manufacturers provide various options for how the connectors mount. Figure 13 shows mounting options typically available from the listed manufacturers.

Figure 13: Receptacle Connector Typical Mounting Options

Picatinny CLIK Payload developers can select the specific option in Table 6 that best suits their application.

Shell Style Description -01 In-Line -02 Square Flange -07 Jam Nut Table 6: Shell Style Options

3.2.1.4. MATERIAL/FINISH

The finish type shall be selected from the options shown in Table 7.

Material/Finish Description NF Aluminum/Cadmium with Olive Drab

Chromate

ZNU Aluminum/Black Zinc Nickel over Electroless Nickel

Table 7: Approved Connector Material/Finish

3.2.1.5. ARRANGEMENT

Picatinny CLIK Payload Connector shall be of Shell Size/Insert Arrangement of 9-19. Refer to Figure 14 for Contact Arrangement. Note that this image represents the front face of male (pin) contacts. Female (socket) contacts will position pins in a mirror position to the pin format shown.

Figure 14: Payload Connector Insert Arrangement

3.2.1.6. CONTACTS

Picatinny CLIK Payload Connector shall use Male (Pin) Contacts of Size #23.

3.2.1.7. KEYING

Picatinny CLIK Payload Connector shall be keyed in the A Configuration as shown in Figure 15.

Figure 15: Connector Keying

3.2.2. CONNECTOR PLACEMENT

The connector shall be located on the back plane of the payload. The specific location will be determined by the platform developer. A notional example is provided in Figure 16.

Figure 16: Payload Connector location (notionally on payload backplane)

3.2.3. CONNECTOR PINOUT

A Picatinny CLIK payload shall implement its connector pinout as described in Table 8. All signals are named from the payload perspective such that an Rx signal is transmitted from the platform and received by the payload. Pins marked as Reserved are retained for future expansion of the Picatinny CLIK design standard and shall not be used by the payload for other purposes. The connector’s 9-19 insert arrangement as seen from the front face of pin inserts is shown in Figure 14.

Pin Name Description Reference 1 RS232 Tx Serial Port. 3.2.6 2 RS232 Rx 3 RS232 Return Return path for RS232.

4 Ethernet Tx+ c

Ethernet Port. 3.2.5 5 Ethernet Tx- 6 Ethernet Rx+ 7 Ethernet Rx- 8 Power In0 Power in from the platform 3.2.4 9 Power In 10 Chassis Chassis bonding connection 3.2.10 11 Power Return Power return to the platform 3.2.4 12 Power Return 13 Safety Arm

Safety discrete signals and dedicated return path. 3.2.8 14 Safety Fire

15 Safety Return 16 Loopback Loopback signal for payload detection. 3.2.9 17 Reserved Pins reserved for future Picatinny CLIK expansion. Not to be used. 3.2.3 18 Reserved 19 Reserved

Table 8: Payload Connector Pinout

3.2.4. POWER

A Picatinny CLIK payload shall operate from a supplied 28 Volt (V) Direct Current (DC) power source. The payload shall remain operational under voltage fluctuation of ±5% from the nominal 28VDC. A Picatinny CLIK Power Unit (CPU) is defined as 250 milliamps (mA) per CPU. The maximum current draw permitted through the Picatinny CLIK connector shall be limited to 10 Amperes. The resulting Maximum Connector CPU (MCC) shall be defined as 40 CPUs.

Picatinny CLIK payloads shall determine their Maximum Possible Current (MPC) draw in multiples of CPUs with fractional CPUs always rounding up. Picatinny CLIK payloads shall implement overcurrent protection to ensure the payload does not draw more than its rated MPC from the platform under normal operations and possible failure modes.

A Picatinny CLIK payload shall not permit current to flow back to the platform unless the payload is specifically purposed for energy storage. A Picatinny CLIK payload designed for energy storage shall not permit more than 10A to flow through its Picatinny CLIK payload connector and shall maintain operation within the permitted 28V tolerance.

3.2.5. ETHERNET

A Picatinny CLIK payload shall optionally implement an Ethernet interface in accordance with Institute of Electrical and Electronics Engineers (IEEE) 802.3u 100BASE-TX. The Internet Protocol (IP) addressing scheme is left to the system integrator. A Picatinny CLIK payload implementing Ethernet shall permit the interface to be enabled and disabled with the default state at power on being disabled.

3.2.6. SERIAL

A Picatinny CLIK payload shall implement a serial interface IAW TIA/EIA-232-F. The recommended configuration for this port is 115,200 bps, 8 data bits, 1 stop bit, no parity, and no flow control. Deviation from the recommended configuration would require coordination with the platform providing this channel. Serial Tx and Rx signals shall be referenced to RS232 Return. The RS232 Return is permitted to be electrically connected to Power Return in the payload only.

A Picatinny CLIK payload shall implement the Payload Serial Protocol as defined in 5.2 over the serial interface.

3.2.7. FUNCTION CHANNELS

A Picatinny CLIK payload shall implement one or more function channels. Each function channel represents a function that can be activated, armed and/or fired. A single purpose payload would only require a single channel while a payload containing multiple individually actionable functions would require a function channel for each (i.e. a two grenade dropper payload would require two function channels to control each drop function independently).

Functions shall be assigned a numeric value starting with 1 and incremented sequentially. A function channel shall exist in one of five states: Unavailable, Not Activated, Activated, Armed, or Firing. The Unavailable state shall indicate that the function is not available to activate (i.e. dropper has released its grenade). A function that is not in the Unavailable state shall accept commands to switch between the Not Activated and Activated states via the command specified at 5.2.5. The Armed state shall be set when a function has been commanded to the activated state, the Safety Arm discrete is active and any additional payload specific safety mechanisms are armed. The Firing state shall be set when the Armed state conditions are set and the Safety Fire discrete is active. Note that function channels are not limited to munitions. For example, an energy storage payload could be commanded to the Activated state to enable its output and would transition to the Unavailable state once its energy was depleted with the Arm and Firing states never being set.

3.2.8. SAFETY DISCRETES

A Picatinny CLIK payload shall monitor the Safety Arm and Safety Fire signals provided by the platform as defined in 4.2.1.3. A false (not armed/don’t fire) value shall be interpreted as a signal with a voltage of less than or equal to 1.5V. A true (armed/fire) value shall be interpreted as a voltage of greater than or equal to 3.5V. A Picatinny CLIK payload shall maintain the isolation requirements specified in 4.2.1.3. Safety signal current draw shall not exceed 5mA for each signal.

The shared safety discrete signals combined with the ability to enable one or more function channels provides the ability for a remote operator to select independent payloads (and their functions) via software and then arm and fire them using physical switches. Note that the safety features provided by CLIK are a component of a payload’s safety functionality but are not exhaustive. Depending on the payload, additional circuits, mechanisms, and/or commands may be necessary to safe, prepare, arm, and/or fire any associated munitions.

The specific methods used to implement the full payload functionality are left to the developer, but a notional example is depicted in Figure 17 where the 28V power needed to actuate the system is gated by several switching devices in series requiring that each be enabled for the function to “fire”.

Safety Arm

Function Chan 1

Function1 Additional Safeties

Safety Fire

Func1 Armed

Func1 Firing

28V

Figure 17 – Notional Payload Safety Circuit

3.2.9. LOOPBACK

A Picatinny CLIK payload shall connect the Loopback signal from the platform to Power Return with less than 1 Ohm resistance.

3.2.10. CHASSIS

A Picatinny CLIK payload shall electrically bond any conductive components of the payloads structure, shielding, connector body, and Chassis Signal pin. A Picatinny CLIK payload shall maintain electrical isolation between all electrical signals and the payload Chassis Signal.

4. PLATFORM REQUIREMENTS

4.1. MOUNTING/PHYSICAL INTERFACE

The Picatinny CLIK platform shall utilize a Picatinny rail identified in 3.1.1. They shall meet the dimensional requirements of MIL-STD-1913. Platforms shall provide adequate ground clearance for mounted payloads, as defined in 3.1.4. Use of a takeoff platform is permitted to achieve adequate clearance.

A Picatinny CLIK platform shall implement one or more Picatinny CLIK payload interfaces.

Each Picatinny CLIK payload interface shall be assigned a unique numerical identifier, starting at 1 and increasing sequentially and permanently marked (1 to n) within three inches of its associated connector.

4.1.1. PICATINNY RAIL MARKINGS

Each singularly mounted Picatinny Rail will have the centerline identified and marked on both sides with a GO & No-GO range of locations so that the payload can be mounted and not adversely affect the flight control and operations of the UAS (see Figure 18). The UAS platform shall analyze where the best place and space of the rail(s).

The intent of this marking is to reduce, but not eliminate, burden of aircraft weight and balance calculations in an operational environment.

Figure 18 - Picatinny Rail w/centerline & defined GO & NO-GO markings, viewable thru

Notional window design

When a singularly mounted Picatinny Rail is longer than the min 5.0” rail or continuously along the UAS mounting surface, it will have the centerline identified and marked with a range of locations that the payload may be mounted in “GO” range and additionally a “NO GO” where it would adversely affect the flight control and operations of the UAS (see Figure 19).

Figure 19 - Picatinny Rail longer than the min 5.0” w/centerline & defined GO & NO-GO markings viewable thru Notional window design

4.1.2. PICATINNY CLIK ARRAY

The platform requirements when hosting an array consist of units, CU, or CPU that create a repeatable grid of expected capabilities on the UAS.

A Platform may only have one physical interface but may allow a payload of 1x2 CU if the area under the platform can accommodate it. The CU and CPU are physical and electrical boundaries that are directly related to the capabilities offered by the payload.

System Integrators are responsible for verifying that the weight and dimensions of a CLIK Unit Payload, including those designated as WxL, are within the platform’s operational limits.

When mounting the rail below the UAS, allowances shall be made to accommodate wiring connected to the UAS as shown in Figure 6. No UAS protrusions may exist in this space.

Use MIL-STD-1913 as the standard for the mounting rail for payloads. The platform will specify the minimum length of the rail to be 5” via its attachment points and is dependent on the intended use of the rail whether it is longer than the minimum 5” or continuous up to the entire length of the platform. Any secondary attachment rails shall be placed on a 5” OC spacing with a clear attachment interface as seen in Figure 6. The program will specify the quantity of rails on a platform, depending on the intended use of the rails.

Payloads can be mounted onto single Picatinny rails, that are no shorter than 5-inches-long, located on the underside of the vehicle frame. If more than one Picatinny rails are required, they will run parallel to each other and are displaced (center to center) by 5.0” (127mm) If more than one Picatinny rail is required on the long axis it will be placed centered on 13.79” (350mm) and as many as needed can be placed on the underside of the UAS fuselage and can be continuous if desired. For details and space claim on Picatinny CLIK ecosystems, see Figure 3.

Note: If the UAS does not have the nominal 8” ground clearance, a takeoff platform may be used to provide clearance. Picatinny CLIK Ecosystem Space Claim – 1 Unit

The platform shall conduct analysis to determine the best mounting configurations for multiple Picatinny CLIK payloads to support proper operations and capabilities (i.e. not hinder) of the

UAS.

4.1.3. IDENTIFICATION MARKINGS

The Platform shall display a permanent identification plate with human readable text and Machine-Readable Information (MRI) in accordance with MIL-STD-130N. The identification plate shall include the following minimum information: manufacturer, part number, unique serial number, maximum allowed payload weight in pounds to one decimal as APW: XX.X, and maximum available payload CLIK power units as MAC: XX (see 4.2.1.1).

4.2. POWER AND SIGNAL INTERFACE

Several requirements are put on both platforms and payloads to implement a Picatinny CLIK compliant system. To maximize flexibility for developers, the requirements are defined as functionalities where possible rather than physical implementations. The primary functional building blocks of a Picatinny CLIK platform implementation include a single Picatinny CLIK Platform Interface (PI) and one or more Picatinny CLIK Payload Channels (PC). Each Payload Channel provides the functionality required to support a corresponding payload. The functional architecture of a Picatinny CLIK system is shown in Figure 20.

Platform Interface

Power

Ethernet

Payload Channel n Payload Channel ..

Payload Channel 1

Payload n

Payload ..

Payload 1

Up to Platform

Up to Platform

Figure 20 – Picatinny CLIK Functional Architecture

The backbone of Picatinny CLIK communication interfaces relies on an Internet Protocol bus via Ethernet. While the flexible architecture of Picatinny CLIK permits the Picatinny CLIK functions to be implemented in various ways, those functions will exist at distinct IP address and port pairs. The individual channels are identified in Table 9 along with references to the sections describing the specific requirements for each. Note that each channel would include its own IP interfaces for each function. In addition, a payload’s IP interface configuration is limited to assigning a non-conflicting IP address(es). The ports used by the payload and the number of unique IP devices are left to the payload developer.

IP/Port Pair Description Reference PI UDP Optional UDP interface to Platform Controller 4.2.1.2 Payload Channel [1..n] UDP UDP interface to Payload Channel 4.2.2.3 Payload Channel [1..n] Serial UDP to Serial converter for Payload Channel 4.2.2.4 Payload [1..n] Optional IP interface(s) for connected Payload 3.2.5

Table 9: Picatinny CLIK IP/Port Pairs

To better illustrate the hardware agnostic approach to the Picatinny CLIK network architecture two example implementations will be provided for a notional Picatinny CLIK platform supporting three payload channels. In this example each payload includes support for a single network device. In the example diagrams the following notation is used to represent the IP/Port pairs: Platform Interface (PI), Safety Interface (SI), Payload Channel N UDP Interface (CNI), Payload Channel N Serial Interface (CNS), Payload N Interface (PN).

The respective IP address and subnet masks are represented using Classless Inter-Domain Routing (CIDR) notation, and the selected ephemeral port selected follows with a P prefix.

The notional implementation in Figure 21 uses an expanded architecture where several different devices (represented as a blue box) implement their respective interfaces. These devices could be a microcontroller or similar device. In this example the platform uses separate devices for the PI and SI. In addition, each channel uses a separate device supporting the payload channel UDP and serial interfaces. Each payload device incorporates a single network interface. In this architecture each device requires a unique IP address.

Since a unique interface is the combination of both IP address and port, port numbers can be reused across different devices.

Platform

PI 192.168.1.50/24 P50000

SI 192.168.1.51/24 P50000

C1I 192.168.1.101/24 P50000

C1S 192.168.1.101/24 P50001

C2I 192.168.1.102/24 P50000

C2S 192.168.1.102/24 P50001

C3I 192.168.1.103/24 P50000

C4S 192.168.1.103/24 P50001

Payload 1

P1 192.168.1.201/24 P50000

Payload 2

P2 192.168.1.202/24 P50000

Payload 3

P3 192.168.1.203/24 P50000

Device

IP Interface

Figure 21 –Notional Network Devices (Expanded)

The notional implementation in Figure 22 uses a consolidated architecture where a single device in the platform implements all the interfaces necessary to support three payload channels. This approach is also valid. However, since the device implements a single IP address, each interface needs to be assigned a unique port.

Platform

PI 192.168.1.50/24 P50000

SI 192.168.1.50/24 P50001

C1I 192.168.1.50/24 P50100

C1S 192.168.1.50/24 P50101

C2I 192.168.1.50/24 P50200

C2S 192.168.1.50/24 P50201

C3I 192.168.1.50/24 P50300

C4S 192.168.1.50/24 P50301

Payload 1

P1 192.168.1.201/24 P50000

Payload 2

P2 192.168.1.202/24 P50000

Payload 3

P3 192.168.1.203/24 P50000

Device

IP Interface

Figure 22 –Notional Network Devices (Condensed)

4.2.1. PLATFORM INTERFACE

The Platform Interface serves as the primary interface between the platform systems and the Picatinny CLIK functions. Raw power and an Ethernet interface are pulled from the platform.

Regulated CLIK power, network interfaces, and safety signals are then provided to one or more Payload Channels as shown below in Figure 23.

Safety

From Platform

Network Switch

Safety Arm Safety Fire

To Payload Channels

Power

Figure 23 –Platform Interface Functions

4.2.1.1. POWER

The Platform Interface shall consume electrical power from the platform and convert it as needed to deliver the 28V power required by the Picatinny CLIK payloads. The developer shall determine the maximum current to be made available for use by payloads. The maximum available payload current (MAC) shall be converted to Picatinny CLIK Power Units (see 3.2.4) with fractional CPUs always rounding down. Overcurrent protection shall be implemented such that a failure of the Picatinny CLIK system cannot affect performance of the platform. The PI shall prevent back feeding of Picatinny CLIK power back to the platform.

The PI shall implement switching of the 28V power bus between the on and off state via the Set Platform Power message as described in 5.3.5. The PI shall default to Picatinny CLIK power off when the system initially powers on. Setting the CLIK power off only removes power provided to the payloads. The functionality provided by the Platform and Channel Interfaces shall persist regardless of CLIK power state.

4.2.1.2. ETHERNET

The Platform Interface shall connect to the platform’s Ethernet network and implement an individual Ethernet interface for each supported payload channel and an Ethernet interface for the safety discretes function. All interfaces shall be connected via full Layer 2 switch functionality. The PI shall support configuration of the IP addresses, subnet masks, and UDP ports for all platform network interfaces though how this is implemented is left to the platform developer. The IP addressing scheme is left to the system integrator.

The Platform Interface shall implement the UDP Protocol defined in 5.3. This interface provides the ability to request status/configuration data and issue commands. With the IP address and port of this interface a software application can identify the platform, determine the number of channels available, and collect the IP address and port pairs for each platform hosted interface.

4.2.1.3. SAFETY DISCRETES

Due to the safety critical nature of functions like arming and firing, additional efforts are required to ensure that signals used for those functions are relayed accurately and timely.

The diligence required to prove out these functions for the purpose of obtaining an approved safety release in accordance with MIL-STD-882E has driven the Picatinny CLIK architecture to break out this functionality to more easily support the integration of proven solutions. The resulting architecture utilizes a dedicated network interface controlling the output of two safety signals: Arm and Fire.

The Platform Interface shall implement the safety control signals necessary for arming and firing of payload armaments. Safety signal output states shall be communicated via a network interface, presumably originating from a ground station controller. The details of this interface are to be defined in a future version of this document. Logic voltage output shall be 5V nominal with greater than or equal to 4.9V output for arm/fire and less than or equal to .1V for not armed/don’t fire. Each safety signal shall be capable of supplying current of no less than the number of payload channels multiplied by 10mA while maintaining the required voltage output. The PI shall provide an independent signal return path for the safety discrete signals.

The safety signals shall be shared by all Payload Channels and ultimately the Payloads themselves. Once generated by the safety interface, the Safey Arm, Safety Fire, and Safety Return signals shall be electrically isolated from all other signals using isolation devices in accordance with International Electrotechnical Commission (IEC) 60747-5-5 or IEC 60747-

17. This isolation requirement shall be enforced at the system level to include the platform and any connected payloads.

4.2.2. PAYLOAD CHANNELS

The Payload Channels implement the signals used by a Picatinny CLIK payload as defined in

3.2.3. For every Picatinny CLIK payload supported, an associated Payload Channel shall be implemented. Power, network interfaces, and safety signals are taken from the Platform Interface while the Payload Channel provides power, a network interface, serial interface, safety signals and a loopback signal to the channel’s associated payload. This is depicted in Figure 24.

UDP to Serial

From Platform Interface

Network Switch

Safety Arm Safety Fire

Payload

Power

Loopback Detection

PC UDP

Interface

Figure 24 –Payload Channel Functions

4.2.2.1. PLATFORM CONNECTORS

Platforms shall integrate connectors to interface signals from the Platform Channels to the Payloads. Platforms shall use current available options shown in Table 10 or connectors with identical form, fit, and function as detailed below.

801 -009 -01 NF

9-19 S A 2M801 -02

-010 ZNU MD801 -07

Table 10: Approved Options for Platform Connectors

Picatinny CLIK Platform Connectors shall conform to the series, class, style, material/finish, arrangement, and keying defined in 3.2.1.

Picatinny CLIK Platform Connectors shall use Female (Socket) Contacts of Size #23.

4.2.2.2. POWER

Payload Channels shall consume electrical power from the Platform Interface and provide that power to their Picatinny CLIK payloads. Payload Channels shall implement overcurrent protection to ensure that a Picatinny CLIK payload cannot exceed the lesser of the MAC as defined in 4.2.2.2 or the MCC as defined in 3.2.4.

Payload Channels shall implement and report the power options represented in the Get Payload Channel Power Config message as described in 5.4.2. Payload Channels shall optionally implement switching of the 28V payload power between the “On” and “Off” state via the Set Payload Channel Power message as described in 5.4.3. Payload channels supporting power switching shall default to power off when the system initially powers on.

Payload Channels shall optionally implement overcurrent resetting via the Set Payload Channel Power message as described in 5.4.3 with an “On” command resetting the overcurrent device and restoring power. Payload Channels shall optionally implement configurable current limit setting via the Set Payload Channel Current Limit message as described in 5.4.4.

4.2.2.3. ETHERNET

Payload Channels shall connect to the Ethernet interface instance provided by the Platform Interface. All interfaces shall be connected via full Layer 2 switch functionality. Payload Channels shall implement the Ethernet interface defined in 5.4 for channel state information and configuration. Assignment of a Payload Channel’s IP address and ports are left to the system integrator.

4.2.2.4. SERIAL

Payload Channels shall implement a UDP to bi-directional serial converter using their provided network interface. Payload Channels shall listen for network datagrams on their configured port and once received immediately transmit the raw data to the payload’s RS232 serial interface. All serial data received from the payload’s RS232 serial interface shall be discarded until communication has been initiated via receipt of a network datagram. Once a datagram has been received, data received from the payload’s RS232 Rx pin shall be packetized and returned to the IP address and source port of the most recent datagram on the indicated network port for serial transfer.

The RS232 serial interface implemented for each payload channel shall support no less than 115,200 bps data rate. Each RS232 interface channel shall implement independent functional isolation from other electrical signals. RS232 signals shall be referenced to the channel’s isolated RS232 Return signal. This isolation prevents ground loops caused by the RS232 channel’s Return line serving as an additional return path for the CLIK Power Bus provided to the payload. Functional isolation shall be no less than +/-50Vrms continuous and +/-100Vrms transient for 60 seconds.

4.2.2.5. SAFETY DISCRETES

Payload Channels shall accept the safety signals provided by the PI and pass them on to their respective payloads. Safety signals shall be measured by the payload channels for state reporting to indicate the state of the safety signals being fed to each payload. The measurement of these signals shall follow the requirements specified in 3.2.8. Measurement of these signals shall occur as close to the payload as is technically feasible. For example, where signals are split the measurement should occur after the split, closer to the payload.

4.2.2.6. LOOPBACK

Payload Channels shall implement a loopback circuit for the detection of a connected payload. Output voltage from the signal shall be less than or equal to the power voltage and when shorted to common shall consume less than 1mA of current. An example of a suitable circuit would be a 10kOhm resistor pulled up to 5V connected to a digital input which gets pulled low when a payload and its loopback jumper are connected.

4.2.3. GROUNDING

The Picatinny CLIK platform grounding scheme shall be carefully designed to eliminate ground loops. The CLIK platform shall maintain isolation between its Chassis signal and all other electrical signals. The platform host power ground should have a single connection path to any CLIK ground references. The decision to bond or isolate the platform chassis to or from other ground references outside the CLIK subsystem is left to the discretion of the platform developer.

4.3. PLATFORM TO PAYLOAD CABLING

Insulated Cables shall be utilized by Platforms to connect to Payloads and distribute Power and Signals between the Platform Channels and the Payloads as shown in Figure 25.

Platform and Payload Receptacle Connectors (specified in Sections 3.2.1 & 4.2.2.1) are denoted with ‘J’ designation. Cable Plug Connectors are denoted with ‘P’ designation.

Platform PayloadPJ P JCABLE

Figure 25: Platform to Payload Cables

4.3.1. CABLE CONNECTORS

Cables shall integrate connectors using available options shown in Table 11 or connectors with identical form, fit, and function as detailed below.

801 -007 -16 NF

9-19 *See Below A 2M801

-008 -26 ZNU MD801

Table 11 Approved Options for Cable Connectors

Picatinny CLIK Cable Connectors shall conform to the series, material/finish, arrangement, and keying defined in 3.2.1.

Picatinny CLIK Cable Connectors shall be of Plug Class Series options shown in Table 12.

The banding platform option incorporates features to support the attachment of shielding and/or shrink boots while…

This is the start of the file's text. The full file is on GovTribe.

File details come from the government source that posted it. Updated .