81-2013-24 SOW SDS 6 MAR 2024.docx

Solicitation Number: Nxxxxx-xx-x-xxxx Attachment (1)

Statement of Work (SOW) SDS -Software Definable/Reconfigurable Systems: Design, Development, Support, and Integration Solicitation Number: Nxxxxx-xx-x-xxxx Attachment (1) 02/05/2024

Version 1

Appendix 1: Glossary of Acronyms and Abbreviations………………………………………..35

Statement of Work (SOW) SDS -Software Definable/Reconfigurable Systems: Design, Development, Support, and Integration 1 Introduction The Naval Center for Space Technology (NCST), a directorate within the U.S. Naval Research Laboratory (NRL) in Washington, DC, is the designated lead for Navy Space Programs. NCST has the mission to preserve and enhance a strong space technology base and provide expert assistance in the development and acquisition of space systems for naval missions. The activities of the NCST extend from basic and applied research through advanced development in all areas of Navy space program interest. These activities include developing spacecraft, systems using these spacecraft, and ground command and control stations.

The efforts in this statement of work will support the Space Systems Development Division (SSDD), which is the space and ground support systems research and development organization of the NCST. The primary objective of the SSDD is to develop command, control, communications, computers, cyber, intelligence, surveillance, and reconnaissance (C5ISR) hardware and software solutions to space, airborne, and ground applications.

SSDD responds to Navy, DoD, and national mission requirements with improved performance, capacity, reliability, efficiency, and/or life cycle costs. The Division derives system requirements from the mission, develops architectures in response to these requirements, and designs and develops systems, subsystems, equipment, and implementation technologies to achieve optimized and integrated operational space, airborne, and ground systems.

SSDD responsibilities extend across the entire space/airborne/ground spectrum of hardware, software, and advanced technologies, including digital processing and control, analog systems, power, communications, payload command and telemetry, radio frequency, optical, payload, and electromechanical systems, as well as systems engineering.

1.1 Mission

The mission of SSDD is to derive system requirements from mission requirements, develop architectures in response to the systems requirements, and design and develop systems, subsystems, equipment, and implementation technologies to achieve optimized, integrated operational ground, aviation, underwater, surface or space (GAUSS) systems.

1.2 Background

SSDD is currently involved in the concept definition and design phases on various advanced concepts studies and projects which will evolve into future space, aerospace and tactical C5ISR systems. Development responsibilities extend across any domain (i.e. aerospace, ground, maritime, cyber) of hardware, software, and advanced technologies including digital processing and control analog systems, power, communications, command and telemetry, radio frequency, optical, payload and electromechanical systems, as well as systems engineering.

This statement of work involves Systems Development, Support and Integration (SDSI) for Software Definable/Reconfigurable Systems (SDS), design tasking required in support of the SSDD technology advancements, system requirements definition, architecture development, and the system and unit design development and transition to operational use. Recent and current NRL SDS Programs include the Software Reconfigurable Payload (SRP), Furious Mercury, Rader-M, and others. These programs represent a core technology for the creation of radio transceivers/software defined payloads that are smaller, lighter and more flexible tactical systems. Advanced waveform development and porting, advanced transceiver design and implementation, and embedded hardware design and implementation are required.

1.3 Scope

The purpose of this contract is to provide personnel, facilities, and manufacturing capability in support of the tasks delineated in Section 3, Performance Requirements identified below. The effort will be conducted in coordination with Principal Investigator (PI) led teams that may include Government scientists and engineers, and other Contractors. The quality and timeliness of the provider's contribution to the work will be evaluated in terms of its impact on the success of the overall programs/project.

3.1 SDS Programs Systems Engineering (SE) Support

3.2 SDS Design, Implementation, and Analysis

3.3 SDS Subsystem Fabrication and Assembly

3.4 SDS Parts Engineering and Management Support

3.5 Programs/Projects Reporting

2 General Requirements The Contractor shall have its support team in place and fully functioning within 90 days of contract award and issuance of the initial task order.

During this period the contractor will transition all activities from the incumbent, as required. The Contractor must execute the scope of work in a manner that provides for high quality, timely services while incorporating the proper mix and the most effective use of personnel.

The Government holds the exclusive authority to define and establish any specific quality standards for all components and equipment produced under this contract, and may execute this authority when it deems necessary. The Contractor must adhere to any qualifications and specifications set forth by the Government and must not modify explicitly stipulated quality standards, unless such standards are subsequently amended or later waived by the Government. Standards and requirements set by the Government may be more or less stringent than the standards and specifications preferred/favored by the Contractor.

2.1 Non-Personal Services

The Government will neither supervise contractor employees nor control the method by which the contractor employees perform assigned tasks.

The Government will not assign tasks to, or prepare work schedules for, individual contractor employees.

The Contractor shall be responsible for managing its employees and guarding against any actions that are of the nature of personal services, or give the perception of personal services as defined in FAR-Part 37, Service Contracting.

The Contractor shall notify the procuring contracting officer (PCO) if any Government requested actions constitute, or are perceived to constitute personal services.

2.2 Business Relations

The contractor shall integrate and coordinate all activity needed to execute this contract.

2.3 Contract Administration and Management

The following subsections specify requirements for contract management and contractor personnel administration.

2.3.1 Contract Management

The Contractor shall establish clear organizational lines of authority and responsibility to ensure effective management of the resources assigned to this contract.

2.3.2 Personnel Administration

The Contractor shall assign a single point of contact, also known as the program manager (PM), who must work closely with the government PCO, contracting officer’s representative (COR), and technical program manager as set forth with each task order.

The Contractor PM shall ultimately be responsible for ensuring that the Contractor’s performance meets all government contracting requirements within cost and schedule. PM must have the requisite authority for full control over all company resources necessary for contract performance. As appropriate, the role of PM is a full time management position.

The Contractor shall maintain the adequacy of their employees by providing initial and refresher training to meet the SOW requirements.

The Contractor shall make necessary travel arrangements for employees.

2.3.3 Contract Administration

The Contractor shall establish processes and assign appropriate resources to effectively administer this contract.

The Contractor shall respond to Government requests for contractual actions within five work days.

2.3.4 Contractor's Management Plan (CMP)

The Contractor shall submit a Contractor's Management Plan (CMP) (CDRL A001) defining the Contractor's approach to implementing the contract. The CMP provides the Government insight to the systems, processes, and structure within which the contractor operates. The CMP should include, as applicable and if not defined in a separate plan: quality control, risk management, systems engineering, software development, configuration management, and subcontract management.

Deliverables A001 Contractor's Management Plan (CMP)

2.4 Contractor Furnished Equipment, Materials, Subcontracts and Supplies Equipment and unexpended materials and supplies purchased by the contractor under this contract become the property of the Government at the end of the performance period.

The Contractor shall provide supplies for contractor personnel.

The Contractor shall provide any other equipment, material, and supplies not furnished by the Government, but required to perform the work defined under Section 3, Performance Requirements, below.

The Contractor shall be responsible for any subcontract management necessary for performing efforts described in Section 3, Performance Requirements, below.

2.5 Facilities and Staffing

2.5.1 Electronics Manufacturing and Support

The Contractor shall provide facilities for automated surface mount printed circuit board (PCB) assembly using pick-and-place and other technology.

The Contractor shall provide a capability for PCB assembly and finishing to include a multi-zone reflow oven, water bath cleaning capability and others.

The contractor shall provide a capability for X-ray analysis of bare an assembled PCB for quality assurance purposes.

The Contractor shall provide a capability for detailed, complex, surface mount technology assembly.

The Contractor shall provide SMT assembly facilities or capabilities for supporting single or dual sided placement, complex, fine-pitch ball grid array (BGA), and pick-and-place machines.

The Contractor shall provide soldering facilities or capabilities for a multi-zone reflow oven or wave soldering, as required for installation.

The Contractor shall provide an X-Ray machine with BGA analysis software for verification of installation of large ball grid arrays.

The Contractor shall provide a limited-access secure facility IAW DoD security requirements and proper ESD protection operations for proper tracking of the assembly process.

The Contractor shall provide conformal coating in dip, manual, and aerosol methods with silicon and urethane for SDS protection.

2.5.2 Wiring Harness / Components and Cables

The Contractor shall provide a capability for standard and high-reliability wiring harness build-up, including but not limited to: power delivery, high speed data, and mixed mode harnesses.

The Contractor shall provide specialized wire types such as variety of coaxial RF cables, twisted pair, shielded cable, EMI/ESD wraps on harnesses and braiding as required, for assembly of SDS.

The Contract shall provide facilities support for building of a flex circuit wiring harness, as required, for a flex circuit wiring harness as required.

The Contractor shall provide specialized wire types such as variety of coaxial RF cables, twisted pair, shielded cable, EMI/ESD wraps on harnesses and braiding as required.

The Contract shall provide a capability to build flex circuit wiring harnesses, as required.

2.5.3 Top Level Assembly (TLA)

The Contractor shall provide for complete mechanical and electrical systems or TLA assembly.

The Contractor shall provide complete top level assembly capability for working with the mechanical shop and all others at NRL.

2.5.4 Assembly QA / Inspection / Rework

The Contractor shall provide a capability for assembly QA, board inspection, and board rework.

The Contractor shall provide independent automated optical inspection, x-ray imaging, and other inspection means for inspection of all parts of the assembly process.

The Contractor shall provide in-house capability for simple and minor board rework. These in-house capabilities shall include leaded and RoHS: surface mount passive component rework, active component rework at a minimum 100 pin ball grid array, and RF connectors.

2.6 Location and Hours of Work

Performance of this SOW requires work at various Naval Research Laboratory facilities in the National Capital Region. At minimum, 25% of employees covered by this SOW are expected to fulfil the conditions of this contract working in-person, on-site at NRL facilities. Normal workdays are Monday through Friday except US Federal Holidays. NRL workers typically work eight (8) hours per day, 40 hours per week. Flextime workers start not earlier than 0600 and not later than 1000. Core hours of work are from 1000-1100 and 1300-1400 daily. All employees are expected to be available during core hours. Additional information on work hours is provided in Section 1. (c), NRL HOURS OF OPERATION AND HOLIDAY SCHEDULE, in the NRL ROSC.

2.7 Travel / Temporary Duty (TDY)

Travel to other government facilities or contractor facilities may be required for conduct of experimental research, testing, or attendance at government reviews or scientific meetings and seminars.

The Contractor shall maintain the capability to arrange the travel of contractor personnel to locations in CONUS/OCONUS often on short notice.

The Contractor shall submit all travel (plans and dates) for pre-approval to the Government.

The Contractor shall bill costs for travel in accordance with FAR 31.205-46 Travel Costs (subject to local policy & procedures).

2.8 Applicable Documents

The Contractor shall comply with the following specifications, standards, and publications as they apply to each task. Where specified, the exact revision level of the reference listed should be used. In some circumstances there may be additional documents required not listed below. In those circumstances, the government will inform the contractor and provide one copy as necessary. Where a revision level is not included, the latest reference to the document from the Department of Defense Index of Specifications and Standards (DODISS) apply. Nothing in this document, however, supersedes applicable laws or regulations unless a specific exemption has been obtained. In the event of conflict between the referenced documents and this SOW, the requirements of this SOW apply.

2.8.1 Military/Department of Defense Specifications and Standards

Environment, General Specification for

Electrical and Electronic Parts, Assemblies and Equipment (Excluding Electrically Initiated Explosive Devices)

MIL-PRF-31032C(1)

Specification Printed Circuit Board/Printed Wiring Board, General Specification for

MIL-PRF-123E

Capacitors, Fixed, Ceramic Dielectric (Temperature Stable and General Purpose), High Reliability, General Specification for

MIL-PRF-55365H

Capacitor, Fixed, Electrolytic (Tantalum), Chip, Non-established Reliability, Established Reliability, General Specification For

Characteristics of Subsystems and Equipment

Electromagnetic Devices for Space Applications

TOR-2004 (3909)-3537-REV B REV-B,

11 March 2005 Software Development Standard for Space Systems

NRL Occupational Safety and Health Manual 5100.13G

JTRS Software Communications Architecture Specification Version 4.1, 23 February 2016

JTRS Software Communications Architecture Extensions Version 2.2.2, 22 December 2006

JPEO JTRS Standards Standardization Plan Version 1.8, 30 April 2008

2.8.2 Other Government Documents

of Wiring Boards and Electronics Assemblies

and Derating

All applicable documents can be found at: https://standards.nasa.gov/safety-quality-reliability-maintainability and https://nepp.nasa.gov/index.cfm/316

2.8.3 Non-Government Documents

2.8.3.1 American National Standards Institute (ANSI)/Electronic Industries Association (EIA)

(Applications for copies should be addressed to the American National Standards Institute, http://www.ansi.org, 1430 Broadway, New York, NY 10018.) and/or (Application for copies should be addressed to Electronic Industries Association, http://www.eia.gov, 2001 Pennsylvania Ave., NW, Washington, DC 20006.)

2.8.3.2 Institute of Electrical and Electronic Engineers (IEEE)

IEEE/EIA

12207.0, 2017 Standard for Information Technology – Software life cycle processes

IEEE/EIA

12207.2, 2017 Standard for Information Technology – Software life cycle processes – Implementation considerations

Related documents may be found at https://ieeexplore.ieee.org/Xplore/home.jsp

2.8.3.3 International Organization for Standardization (ISO) Standards

Related documents may be found at http://www.iso.org

3 Performance Requirements General systems engineering tasks for analyzing systems, determining internal and external interfaces, performance of system definition tasks, and determination of evaluation metrics and measures of effectiveness are defined in EIA/IS-632, Systems Engineering.

The following subsections specify the specific Systems Engineering tasks, performance objectives, and performance elements required for this contract. Selection and use of electronic parts in SSDD systems/subsystems are in accordance with standards cited in the performance requirements below and are guided by requirements in DoD-E-8983C(1): Electronic Equipment, Aerospace, Extended Space Environment, General Specification for, DoD-HDBK-263B: Electrostatic Discharge Control Handbook for Protection of Electrical and Electronic Parts, Assemblies, and Equipment (Excluding Electrical Initiated Explosive Devices), and MIL-HDBK-454B: General Guidelines for Electronic Equipment, as specified herein.

3.1 SDS Programs Systems Engineering (SE) Support

Systems Engineering (SE) support involves all aspects of the SDS Design and Development using engineering processes and program management to bring sponsor articulated requirements through the design process and to a manifestation that meets the majority of the requirements.

The specifications for the system being developed may be derived from a wide variety of sources and encompass the entire SDS ultimate performance, physical form factor, security, and other factors.

The requirements to meet this SDS Programs System Engineering (SE) Support are (3.1.1) General Engineering Process and Planning, (3.1.2) SDS Projects Programmatic and Technical Reviews and Audits, and (3.1.3) SDS programs/projects configuration control of classified and unclassified documents, all of which include explicit, implicit, and derived system security requirements as properly articulated and accounted for.

Content and delivery media (optical media, hard copy, as attachment to the technical report, or another) of technical data, as required, will be defined at as needed.

Deliverables CDRL A004 Technical Documentation, Reports and Data

3.1.1 General Engineering Process and Planning

General engineering and planning support involves all program level efforts such as program management and technical planning for designing the SDS, general engineering and planning based on sponsors requirements.

Achieving the program goals means achieving the requirements listed in sections 3.1.1.1 through 3.1.1.5.

SDS engineering process is iterative and involves other parts of the systems engineering processes and interaction with the other project partners either government or other contractors.

3.1.1.1 The Contractor shall develop a systems engineering management plan (SEMP) and associated technical documentation as required for the assigned SDS program.

The SEMP describes the contractors proposed efforts for planning, controlling, and conducting a fully integrated engineering effort. The Plan is used to understand and evaluate the contractors engineering work efforts as part of the contract monitoring.

Deliverables CDRL A011 Program Documentation

3.1.1.2 The Contractor shall develop and document systems architecture concept, plans, implementations, and operational analyses for current and planned SDS programs/projects.

Analysis efforts include development and maintenance of concept plans, white papers, and Concept of Operations (CONOPS).

3.1.1.3 The Contractor shall perform decomposition and allocation of high-level requirements into lower-level and derived requirements for SDS design and development.

3.1.1.4 The Contractor shall perform trade-space analysis for all parts of the engineering process for SDS systems/subsystems.

3.1.1.5 The Contractor shall provide logistical support for SDS software and hardware development and system repairs.

3.1.2 SDS Projects Programmatic and Technical Reviews and Audits In the following paragraphs, conducting/attending reviews means organizing the meetings, active participation in the discussions, and preparing technical/programmatic data package for required technical/programmatic reviews and audits, as required. These reviews may involve external/internal dependencies, such as interfacing with platform provider, NRL SDS team, SDS customer, and sponsoring organization. These reviews cover all aspects of the project, design and development activity, as required. Representative reviews are systems requirements reviews (SRR), preliminary design reviews (PDR), critical design reviews (CDR), Test Readiness Reviews (TRR). The specific reviews that occur depend on the phase of development the program or project is in e.g. concept development, engineering development, or test and evaluation.

Design data includes:

· Technical Reports - system analysis reports, system requirements allocation reports, system test reports, and document lists

· Programmatic Reports - risk mitigation/management plans, integrated master schedules, program execution plan, programmatic budgets, and other tools to be used by the program managers

Specification Trees - preparation and maintenance of all specification trees related to the program

· Parts Lists - all system parts lists

· Design Review Reports - system design review results, action item assignments, action item resolutions and First Article Configuration Inspection (FACI) results

· Level two technical data package that includes drawings, procedures (such as processes for configuring programmable devices and system assembly), materials and process documents, system drawings, lists that define a specific system, subsystem or unit design, and other artifacts as required

· Parts Program Documents

· Quality Assurance Documents

· Manufacturing Documents

· Test Methods and Control Documents Deliverables CDRL A011 Program Documentation

3.1.2.1 The Contractor shall execute technical program management reviews for the SDS design and development for the assigned program.

3.1.2.2 The Contractor shall conduct and participate-in system level program reviews as required for the SDS design and development for the assigned program.

3.1.2.3 The Contractor shall conduct and attend the NRL systems engineering reviews as required for the SDS system, subsystem, and component level design.

3.1.2.4 The Contractor shall conduct and attend integration meetings and reviews with the host vehicle provider and their contractor partners for evaluating and incorporating all of the technical information necessary to support evolving software and hardware integration efforts, if required by the program.

3.1.2.5 The Contractor shall attend and participate in Technical Interchange Meetings (TIM) as necessary for SDS programs/projects.

Notes from these meetings shall be submitted to the Government upon request.

Deliverables CDRL A011 Program Documentation

3.1.3 The Contractor shall manage configuration control of classified and unclassified documents for SDS programs/projects.

Management functions include performance of: hardware and software configuration item updates, configuration change management, configuration status accounting, configuration audits and verification, and CM planning and management.

3.2 SDS Design, Implementation, and Analysis

The minimum requirements are set forth in sections addressing (3.2.1) RF waveform and software development, (3.2.2) design, development, integration, and operation of infrastructure software and firmware for integration, (3.2.3) SDS subsystem development, (3.2.4) characterization of systems designed, (3.2.5) technical assessment and engineering analyses, (3.2.6) application development, (3.2.7) pre-mission, mission, post-mission performance analysis, (3.2.8) payload hardware engineering, (3.2.9) software systems engineering, (3.2.10) packaging design engineering, (3.2.11) software and hardware subsystem integration and packaging, and (3.2.12) design improvement. All processes are iterative and involves other parts of the SDS Design and implementation process and other project partners either government or other contractors.

Deliverables CDRL A003 Technical Documentation/Reports and Data

3.2.1 The Contractor shall develop RF waveform and software as required by NRL.

Deliverables CDRL A004 Technical Documentation, Reports, and Data CDRL A011 Program Documentation

3.2.2 The Contractor shall design, develop, integrate, and operate infrastructure software and firmware for integration of the equipment into ground, space, and maritime vehicles and facilities.

Integration of equipment into selected vehicles and facilities includes development of modifications to power systems, antennas, electronics and man-machine user interfaces needed to operate the SDS equipment.

Deliverables CDRL A005 Software, Algorithms, Executable Programs and Source Code, and Documentation and Instructions CDRL A011 Program Documentation

3.2.3 SDS Subsystem Development

The Contractor shall develop subsystems for SDS.

Subsystem development includes design decomposition, and design interface definition development.

3.2.3.1 The Contractor shall decompose subsystem requirements into lower level requirements for development of software.

3.2.3.2 The Contractor shall define and design interfaces between hardware and software systems as requested for the SDS subsystems at the board or lowest subsystem level for SDS HW integration.

These interfaces may be analog, RF, digital or mixed signal interfaces, and may operate at frequencies from DC to 300 GHz. Interface design may involve utilizing HW or designs generated by other program team members, whether government or contractor.

3.2.4 The Contractor shall characterize system designs in terms of performance, weight, internal/external interfaces, specifications, and life cycle cost (LCC) objectives for SDS based systems.

A system may include a single sensor, GAUSS sensor/communications element (either stand alone or for integration into a larger system) up to all major components of a large, complex multiple component system.

Deliverables CDRL A011 Program Documentation

3.2.5 The Contractor shall perform technical assessments and engineering analyses for SDS programs/projects.

Assessments and analyses include efforts to: identify, recommend, and implement solutions for critical design or performance deficiencies; provide system level integration test plans and procedures; identify and report deficiencies; perform hardware and software design reviews; identify, analyze or develop decision support, simulation or modeling support activities; perform short-term engineering analyses and quick reaction studies; perform system survivability analyses; and analyze/resolve LAN/WAN network protocol issues.

Deliverables CDRL A005 Software, Algorithms, Executable Programs and Source Code, and Documentation and Instructions

3.2.6 The Contractor shall analyze, evaluate, define, and develop systems applications for SDS programs/projects.

System applications to be evaluated will be assigned by task and may include bus architectures, their protocols and throughput characteristics; subsystem design implementations; fail-safe/fault-tolerant provisions; modeling and simulation of system performance using software such as MATLAB and SIMULINK; functional interfaces among subsystems; interface circuit configurations; interface signal level requirements; and internal power distributions and revised power budgets.

3.2.7 The Contractor shall conduct pre-mission, mission, and post-mission systems performance analyses for SDS experiments and operations.

The work to be performed include analysis and evaluation of: mission data to determine subsystem and system performance characteristics; recovery, reduction and analysis of mission data; development of systems necessary for collection, reduction and analysis of mission data; real-time problem analysis and resolution for operational missions; analysis of mission data to determine the nature of faults or performance-limiting factors; and development of recommended solutions for improving systems performance in subsequent mission experiments/operations, including flight software or hardware upgrades to maximize mission performance.

Deliverables CDRL A011 Program Documentation

3.2.8 Hardware Engineering

The Contractor shall perform hardware engineering required to produce prototype SDS for laboratory and field-testing.

3.2.8.1 The Contractor shall convert the subsystem requirements allocated to hardware to the next level of design detail.

Examples of next level are down the logic device, transistor, resistor, or other component levels. For RF and high-speed digital design, this design decomposition may involve performance analysis of the subsystem. These types of analysis may include RF gain, noise performance, spur analysis, phase noise analysis, jitter, and others. Digital design and mixed signal design may involve other analysis tools (e.g., Hyperlynx, Sonnet, SPICE and others).

3.2.8.2 The Contractor shall perform analysis of the resulting detailed layout in both the analog/RF and digital domains at the completion of the subsystem design process for SDS and subsystem HW verification and validation.

Analysis may involve digital energetic analysis such as those provided by Hyperlynx, analog RF analysis such as provided by Microwave Office or EM/SYS or other performance verification and validation tools necessary to help improve the Reliability, Maintainability, and Availability (RMA) of board meeting its performance requirements.

Deliverables CDRL A005 Software, Algorithms, Executable Programs and Source Code, and Documentation and Instructions CDRL A006 Test and Analysis Report(s)

3.2.8.3 The Contractor shall provide and maintain hardware configuration management process for SDS development.

Deliverables CDRL A005 Software, Algorithms, Executable Programs and Source Code, and Documentation and Instructions

3.2.9 Software Systems Engineering

It is expected that the Contractor's software development processes meet the intent of ISO/IEC/IEEE 12207:2017, Standards for Information Technology - Software life cycle processes, which provides guidance on performing life cycle support for software that is part of a larger systems, as well as, stand-alone software products and services. Software development must be done with a process similar to the Software Engineering Institute (SEI) Capability Maturity Level Integration (CMNI) level 3 process. The process will include (but is not limited to) requirements analysis, design, implementation, peer review, unit testing, system testing, and security verification testing (SVT). These steps will each be described in additional detail in other parts of this document. The software engineering process may incorporate a tailored Agile Scrum process. The main steps in this process are backlog grooming, sprint planning, the sprint itself, status meetings, and the sprint review (which is combined with planning the next sprint).

3.2.9.1 The Contractor shall generate and update subsystem software development specifications for SDS programs/projects.

ISO/IEC/IEEE 12207:2017, Standard for Information Technology - Software life cycle processes provides guidance on performing life cycle support for software that is part of a larger system, as well as, stand-alone software products and services.

3.2.9.2 The Contractor shall decompose the allocated software subsystem requirements for defining the next level of SW details.

The next level should include down to the CSCI level and eventually to the logical software blocks. Performing this task may involve utilizing application programming interfaces, documentation, and other tools to support the design of the subsystem at this level of detail. Additionally operating system information, operating environment interfaces, SCA and REDHAWK documentation, and other data such as security requirements to assist in this process. The design decomposition may include analysis to ensure the performance of the subsystem by determining corresponding data throughput, processing speed in operations per second, security analysis on the design, and others.

3.2.9.3 The Contractor shall develop software for interfacing SDS to external systems/subsystems.

These interfaces may involve socket, TC/IP, and UDP library calls with TLS security CORBA IDL interfaces, XML standards for the passing of data, service-oriented-architecture (SOA) interfaces, standard socket-based interfaces, MQTT, and others.

Deliverables CDRL A005 Software, Algorithms, Executable Programs and Source Code, and Documentation and Instructions

3.2.9.4 The Contractor shall develop software for implementing an SDS per requirements.

Software may be in VHDL, Verilog, C, C++, JavaScript, OpenCPI, OpenCL, CUDA, Go, Rust or others as required. VHDL/Verilog may be used for any system developed to be installed on hardware such as Field Programmable Gate Array (FPGA). Other languages are suitable for other systematic efforts include scripting languages such as BASH, PERL, and PYTHON.

Software systems may be written with a makefile construct to include both the compilation of the code as well as running verification tests for that software module. As required by the government, the software implementations may require unit testing; software quality and security requirements may require mitigation of cyclomatic complexity and other problematic software constructs.

Deliverables CDRL A005 Software, Algorithms, Executable Programs and Source Code, and Documentation and Instructions

3.2.9.5 The Contractor shall conduct performance evaluation for assessing the performance of the SW implemented for an SDS, per requirements.

Certain firmware requirements may need to be written in other languages such as assembly code or even limited microcode/machine code. Code not meeting performance requirements must be tested against a profiling tool and refactored to meet timing/CPU utilization and/or memory utilization

Deliverables CDRL A006 Test and Analysis Report(s)

3.2.9.6 The Contractor shall conduct unit level testing of the SW for SDS and subsystems.

Unit-level testing is for any SW function and subroutine developed under the SDS program for any high level programming language.

Deliverables CDRL A006 Test and Analysis Report(s)

3.2.9.7 The Contractor shall develop and provide test benches for any software developed in any hardware programming languages for SW verification/testing.

A test bench is a template of inputs and expected outputs and the software harness to hold it together. For most code, the unit tests will meet these requirements. Test benches are often built up to support firmware/gateway development for FPGAs. Test benches will be used to evaluate performance as part of the development processes.

Deliverables CDRL A005 Software, Algorithms, Executable Programs and Source Code, and Documentation and Instructions CDRL A006 Test and Analysis Report(s)

3.2.9.8 The Contractor shall provide and maintain software configuration management system for SDS development.

The government may also mandate utilization of its CM system which is currently hosted on GIT via Atlassian Bitbucket.

3.2.9.9 The Contractor shall conduct performance evaluation for verification and validation of the SW developed under this effort.

This subpart applies to external and internal SW including interfaces/protocols developed for operation of the entire SDS to ensuring that the test system is not affecting the code under test.

Deliverables CDRL A006 Test and Analysis Report(s)

3.2.10 Packaging Design Engineering

This subsubsection involves packaging design engineering as specified below for implementing electronic devices assigned in task 3.1 above. Packaging engineering refers to design, analysis, and manufacturing of the sub-system and system level packaging for the operating environment, physical connections, and mounting in accordance with the SDS platform packaging requirements. Packaging involves thermal management, tamper protection / security requirements, and mechanical performance/vibration resistance, as addressed in the subtasks below.

Deliverables CDRL A006 Test and Analysis Report(s)

3.2.10.1 The Contractor shall verify that EMI/EMC requirements of MIL-STD-461E are met for electronic package designs, as required.

3.2.10.2 The Contractor shall conduct analysis of structures, housings, and printed wiring board (PWB) designs for evaluating electronic/optical packaging designs conformance with NRL dynamic environment design margins, as required.

3.2.10.3 The Contractor shall assemble contamination sensitive technology systems and assemblies for evaluation of electronic packaging designs conformance with NRL thermal environment design margins, as required.

Assembles may be required to be manufactured in accordance with some or all of the documents referenced in Section 2.8.2 in this Statement of Work.

3.2.10.4 The Contractor shall design, manufacture, and analyze the SDS subsystem and system level packaging in accordance with thermal requirements for operating in a variety of challenging environments, as required.

3.2.10.5 The Contractor shall design, manufacture, and analyze the SDS subsystem and system level packaging in accordance with thermal requirements for physical security, as required.

Physical security requirements may involve tamper protection and others as required and in accordance with COMSEC, classification level, and others service-imposed standards as required.

3.2.10.6 The Contractor shall design, manufacture, and analyze the SDS subsystem and system level packaging for operating in various vibrational environments, as required.

3.2.11 Software and Hardware Subsystem Integration and Packaging This section involves integration and packaging of the hardware developed in 3.2.8 and the software developed in 3.2.9 with packaging designed and tested in 3.2.10 for SDS prototype development.

Deliverables CDRL A006 Test and Analysis Report(s)

3.2.11.1 The Contractor shall develop test fixtures, SW, HW, and harnesses for validating the SDS prototype operation, as required.

In this particular task, test fixtures refer to hardware devices as well as software interfaces that are utilized in testing the end-to-end system SDS prototype. One example of a test fixture may be a test rack that is utilized in stimulating the RF transmissions, receiving the stimulation, and generating automated test reports.

3.2.11.2 The Contractor shall maintain configuration management for the SDS prototype HW/SW system(s) developed under this effort, as required.

3.2.11.3 The Contractor shall perform integration and packaging of the hardware developed in 3.2.8 and the software developed in 3.2.9 by utilizing the results of subtasks 3.2.10 for SDS prototype development, as required.

3.2.12 Design Improvement

Deliverables CDRL A006 Test and Analysis Report(s)

3.2.12.1 The Contractor shall evaluate and document the performance of the SDS subsystems/components developed in accordance with the analytical methods as required for determining design improvement options.

Documentation includes lessons learned such as what worked, what did not work, and areas of improvements for the entire system/subsystem/components, and payload assembly and integration.

3.2.12.2 The Contractor shall provide mitigation and improvement options based on trade space analysis and lessons learned for SDS prototype system/subsystem/components.

3.2.12.3 The Contractor shall implement and execute the mitigation and improvement options approved by COR for the SDS prototype modifications.

3.3 SDS Subsystem Fabrication and Assembly

Fabrication and assembly involves all parts of fabrication and assembly of software defined systems.

Deliverables CDRL A009 Other Data Deliverables

3.3.1 Material Acquisition and Control

Material acquisition and control means acquiring components in accordance with supply chain management practices for the construction of SDS hardware configuration items and control of those parts. Supply chain management involves working with SDS design and test engineers to ensure that the items to be purchased as custom-made or manufactured for the SDS project are delivered in accordance with the schedules as approved.

This subtask includes parts engineering, inventory and lot management, and parts quality assurance engineering.

3.3.1.1 The Contractor shall procure the parts as required for constructing the SDS subsystem/components through its purchasing department in accordance with the system design requirements as approved.

This subtask includes purchasing all parts and components, as required and approved by COR, for fabricating and assembling SDS subsystems/components and apparatuses, interfaces, flight harnesses, integration, bench/component/field testing, and others.

3.3.1.2 The Contractor shall provide kitting, packaging, and shipment of individual material items and material lots for delivery to other entities as directed by the COR.

3.3.1.3 The Contractor shall provide inventory and lot management for the SDS parts and fabrication components, as required.

Inventory and lot management involves maintaining the storage of on-hand components, tracking the lots of critical components, providing an inventory of the available parts in-stock at any point within the program, and working with the fabrication shop for kitting assemblies from component stock.

3.3.1.4 The Contractor shall conduct quality assurance (QA) engineering and management on the parts acquired/procured and received, materials, and parts and components for SDS implementation materiel, as required.

Parts QA process includes verifying that components are not damaged during shipping and handling and ensuring that the proper quantities, packages, and part numbers are received. This may involve coordination and working with the cognizant design engineer to ensure that the proper QA processes are put in place at the time of the purchasing effort and that the process is ready to execute when the parts or material arrive.

Some fabricated components may need additional QA processes applied; PCBs and other components may need X-ray inspection to verify that they were manufactured appropriately. Mechanical pieces may need inspection or testing to ensure that they meet the coating, material or tolerance requirements.

3.3.2 Fabrication and Assembly

Fabrication and assembly operations include but are not limited to: operation of automated pick-and-place, surface mount technology (SMT) assembly; ball grid array (BGA) assembly; column grid array (CGA) assembly for GAUSS environments; and radiographic inspection capabilities for the inspection of parts, printed wiring boards (PWBs) and completed assemblies. Fabrication methods further encompass additive and subtractive manufacturing (e.g. FDM 3D printers and CNC machining respectively), as well as plating and coating of parts (e.g. conformal coating of PCBs or chemical conversion coating of metal parts).

3.3.2.1 The Contractor shall fabricate, assemble, and deliver qualified hardware and software for use in SDS-based GAUSS systems, as required.

3.3.2.2 The Contractor shall provide configuration control and document fabrication and assembly processes for producing all SDS.

3.3.3 Verification Testing

Testing and verification are a critical component of the development process, and the Contractor must be able to interface with and evaluate their own designs/products.

Deliverables A011 Program Documentation

3.3.3.1 The Contractor shall conduct and develop test and verification programs for Contractor developed SDS subsystems/elements.

Test activities include: development testing (DT); design verification testing (DVT); Qualification Testing; and Acceptance Testing at the part, software, hardware module, subassembly, unit, and system levels.

3.3.4 SDS/Platform Integration and Installation Engineering Support This subsection involves services for integration and installation of the SDS for testing in host platforms.

Deliverables CDRL A011 Program Documentation

3.3.4.1 The Contractor shall develop and implement a product verification test process for SDS intended for use in GAUSS systems.

Deliverables CDRL A006 Test and Analysis Report(s)

3.3.4.2 The Contractor shall develop, design, document, install, and test integration of GAUSS SDS for assigned programs and projects.

Deliverables CDRL A006 Test and Analysis Report(s)

3.3.4.3 The Contractor shall develop, design, document, install, and test integration of vehicle power systems, antenna, electronics, and man-machine interface modifications for SDS into GAUSS systems.

Deliverables CDRL A006 Test and Analysis Report(s)

3.3.4.4 The Contractor shall develop, design, document, install, and test integration of GAUSS systems, and ground station control equipment for assigned SDS programs and projects.

Deliverables CDRL A006 Test and Analysis Report(s)

3.3.4.5 The Contractor shall develop and design power systems that convert, condition, and distribute electric power for GAUSS systems.

These power systems range from low voltage and high voltage DC-to-DC power converters for space systems to high power (> 3kW) stackable power systems for SDS that automatically load share and balance input AC power.

Deliverables CDRL A004 Technical Documentation, Reports and Data

3.3.4.6 The Contractor shall design, develop, and integrate software defined radio communications applications for use in SDS tactical communications networks.

These system may require compliance with some or all of the documents referenced in Section 2.8.2 in this Statement of Work.

3.3.5 Test Systems Design and Development

Deliverables CDRL A005 Software, Algorithms, Executable Programs and Source Code, and Documentation and Instructions

3.3.5.1 The Contractor shall develop automated test systems for automated testing of SDS.

This development involves integrating comprehensive test fixtures and software related to those test fixtures, as well as test systems to support factory-level testing of the end item unit as well as regression testing and system verification as required.

3.3.5.2 The Contractor shall develop, enhance, and maintain a software environment for simulating target hardware and software operating environments.

3.3.6 SDS Design, Fabrication, and Test Process Improvement

Deliverables CDRL A006 Test and Analysis Report(s)

3.3.6.1 The Contractor shall evaluate and document the design, fabrication, and testing of the SDS subsystems/components developed in accordance with the analytical methods as required for developing lessons learned and risk mitigation for SDS improvements.

Process improvements include evaluation and documentation of bench-top testing, field testing, and procedure testing. Documentation includes what worked, what did not work, and areas of improvements for the entire system/subsystem/components, assembly, and integration.

3.3.6.2 The Contractor shall provide risk mitigation and improvement options based on trade space analysis and lessons learned for SDS prototype subsystem/components.

3.3.6.3 The Contractor shall implement and execute the risk mitigation and…