DRAFT Work Description Task Order 1 20191121.pdf

AIR FORCE RESEARCH LABORATORY

ROME RESEARCH SITE

ROME, NEW YORK

WORK DESCRIPTION

FOR

COUNTER SMALL UNMANNED AIRCRAFT SYSTEMS (C-sUAS)

COMMAND AND CONTROL, RF AND INTERCEPTOR PROTOTYPE

ORDER 0001

PCSN G-0-2704

21 NOV 2019

(Solicitation Number FA8750-20-R-1000 0001)

TABLE OF CONTENTS

Section Title Page

1.0 OBJECTIVE: 3

2.0 SCOPE: 3

3.0 BACKGROUND: 3

4.0 TECHNICAL REQUIREMENTS. 4

1.0 OBJECTIVE

1.1 The objective of this effort is to research, design, prototype, test, evaluate, operationally evaluate and repeat as needed to provide efficient/automated C2, RF and interceptor technologies. Emphasis shall be placed on: a) Optimization and automation of C2 for on the move control of C-sUAS sub systems. b) RF effects that limit Spectral fratricide and are effective. c) sUAS interceptors that can operate in populated areas and dynamically adapt to approved, nuisance and nefarious sUAS operating in the area. d) Prototype, test, evaluate, demonstrate and operationally assess complete systems that address a, b and c.

2.0 SCOPE

2.1 The scope of this effort is to perform R&D, Test and Evaluation of all technologies needed to accomplish the order objective. Discovery, concept development, modeling and simulation (M&S), technology maturation, rapid prototyping, developmental test & evaluation, field assessment, operational evaluation and productization are all within scope of this task in the following areas.

2.1.1 Exploration, simplification, automation, and integration of C2 and open systems architectures in both fixed site, mobile and dismounted scenarios. Effective operation of multimodality C-sUAS systems and subsystems by as few operators as possible.

2.1.2 RF detection, analysis, processing, resource allocation, interrogation, emission and assessment of sUAS wireless C2 links. Confirmed detection, geolocation, low collateral damage electronic attack and Cyber over RF.

2.1.3 Modular and adaptable interceptor systems and subsystems (including cueing) that interact with sUAS in their airspace to identify friend or foe, track, analyze, and defeat. Kinetic, high power microwave, electronic attack or any other potential defeat weapon needed to mitigate sUAS threats.

3.0 BACKGROUND

3.1 This order is to address technical gaps that result in exuberant manpower requirements, ineffective defeat for sUAS with active wireless C2 links and lack of low collateral damage kinetic defeats for sUAS. Engagements by C-sUAS systems beyond a few sUAS are complicated for a single person to manage. Optimized human interfaces, human machine teaming and automation of the Rules of engagement are needed. Simple spectrum disruption to defeat sUAS is both ineffective and overly destructive to spectrum at locations that rely heavily on it for infrastructure and normal operations of both Military and Civilian activities. Building capabilities that limit spectral fratricide and continue to defeat sUAS are needed. The ability to dynamically adjust and employ low collateral damage interceptors in permissive and non-permissive environments is needed. Affordable, effective, adaptable and scalable interceptors are required. The challenge of detecting, locating, and countering COTS sUAS and related technologies has become a dynamic and growing endeavor – it represents a global threat to US and allied forces. Of note, ISIS has successfully deployed these systems for both ISR and kinetic attacks via UAS-carried improvised explosive devices. Peer adversaries can field stealthy, more capable UAS and are continuing to improve their technologies. Moreover, advanced militaries are testing the use of swarms of unmanned aerial vehicles (UAVs) which are autonomous, distributed, collaborative systems made up of many small, cheap, unmanned aircrafts. The challenge of detecting and countering small UAS and sUAS swarms is particularly acute.

3.2 The US must develop superior technologies for the detection and countering of sUAS and sUAS swarms. These technologies must be advanced and include prospects for improvements in size, weight, power and performance as well as cost to develop and prove viable approaches to counter sUAS. Lastly, the US must be strategically positioned to rapidly respond to the dynamic and diverse sUAS threat to US personnel, equipment, and interests across the spectrum of local, regional and global threats.

3.3 Reference documents

3.3.1 Joint Publication 1-02, Department of Defense Dictionary of Military and Associated

Terms, 12 April 2001 (as amended through 15 February 2016)

4.0 TECHNICAL REQUIREMENTS

4.1 The contractor shall accomplish the following activities as part of this order. The requirements encompass Research & Development (R&D), tradespace analysis and studies, design, rapid prototyping, demonstration, scenario/concept development, experimentation and evaluation, integration, testing, field assessment, maturation and operational evaluations of technologies and solutions.

4.2 Command and Control

4.2.1 Collect, document, and analyze requirements with the goal of completeness, consistency, cost efficiency, and achievability. Collect requirements from attendees at conferences, user site visits, AF/DoD/Intelligence Community (IC) documents and publications, deployment site surveys, etc. Translate User requirements into a set of technical requirements (conforming to agile development approaches) to dictate the overall system design. User and technical requirements shall be presented to the AFRL PMPM and the Contracting Officer Technical

Representative (COTR) for review and approval. The Government shall establish the requirements priority order for further investigation. (See CDRL, A004)

4.2.2 Analyze alternatives (i.e., perform trade studies) to explore various technical approaches for satisfying the requirements that are suitable for the intended operational environments (See

CDRL, A005).

4.2.3 Identify real or surrogate subsystems to integrate and optimize. Collect interface documents, performance parameters and projected subsystem evolution.

4.2.4 Design and/or identify changes needed to an existing C2 system that would allow for optimization and automation for the multimodality C-sUAS trade space (See CDRL, A004)

4.2.4.1 Identify and evaluate needed automation

4.2.4.2 Identify and evaluate needed user mobility

4.2.4.3 Evaluate cost, scalability and ease of use of proposed design

4.2.4.4 Present scenarios and how the technology would work

4.2.4.5 Propose methods for on-ramping 3rd party applications

4.2.4.6 Present system evolution strategy

4.2.5 Prototype software, test on a variety of hardware and establish a hardware compatibility list (HCL) that should be maintained, updated and delivered to the government (See CDRLs, A006, A007, A008 and A009)

4.3 RF Detect, ID, Track and Defeat

4.3.1 Collect, document, and analyze requirements with the goal of completeness, consistency, cost efficiency, and achievability. Collect requirements from attendees at conferences, user site visits, AF/DoD/Intelligence Community (IC) documents and publications, deployment site surveys, etc. Translate User requirements into a set of technical requirements (conforming to agile development approaches) to dictate the overall system design. User and technical requirements shall be presented to the AFRL PM and COTR for review and approval. The

Government shall establish a priority order for further investigation.

4.3.2 Analyze alternatives (i.e., perform trade studies) to explore various technical approaches for satisfying the requirements that are suitable for the intended operational environments. (See

CDRL, A005)

4.3.3 Research and develop new capabilities and functionalities for C-sUAS such as: (See

CDRL, A004)

4.3.3.1 Novel RF detection techniques such as Multiple-In-Multiple-Out (MIMO) state matrices for the detection of physical changes in base electromagnetic environments in order to monitor large areas using passive techniques.

4.3.3.2 Techniques for analysis and reverse engineering of RF C2 links for detection, tracking, exploitation, and defeat

4.3.3.3 Cyber over RF capabilities to create a “Cyber Conduit” or “Barrel” and cyber effects

“Cyber Bullet” or “Munition” that can be added to the C-sUAS RF arsenal.

4.3.3.4 Techniques for static and dynamic Vulnerability Research (VR) of COTS sUAS for the purpose of developing cyber effects.

4.3.3.5 Research, develop, and utilize techniques to automate RF C2 link analysis and reverse engineering activities so as to reduce the manpower needed to accomplish these tasks.

4.3.3.6 Research, develop, and utilize techniques to automate vulnerability research and cyber effects development so as to increase the speed of delivery and increase effect useful lifespan.

4.3.3.7 Develop capabilities for new components of OA to support next generation hardware processors and/or to reduce required patch queues.

4.3.3.8 Research, develop, and integrate new capabilities and functionalities to further develop system components.

4.3.3.9 Develop a plan for implementation/integration of new capabilities into new or existing baselines. (See CDRL, A010)

4.3.3.10 Research, develop, and integrate new capabilities into new or existing C-sUAS software baselines. Ensure new C-sUAS baselines maintain support for all platform and components on legacy C-sUAS HCL or as directed by the Government.

4.3.3.11 For each new feature/capability, create feature design documentation. (See

CDRL, A006) The feature design document shall include:

• Statement of feature

• One or more technical approaches (as applicable), including design or implementation alternatives and their pros/cons

• Architecture diagram

• User Interface (UI) changes and diagrams

• Impact analysis

• Data communication standards

• 3rd party technology incurred

• Derived requirements

4.4 Interceptor Cue, Search, Acquire, Track, Defeat & Automate

4.4.1 Collect, document, and analyze requirements with the goal of completeness, consistency, cost efficiency, and achievability. Collect requirements from attendees at conferences, user site visits, AF/DoD/Intelligence Community (IC) documents and publications, deployment site surveys, etc. Translate User requirements into a set of technical requirements (conforming to agile development approaches) to dictate the overall system design. User and technical requirements shall be presented to the AFRL PM and COTR for review and approval. The

Government shall establish a priority order for further investigation. (See CDRLs. A004, A011 and A012)

4.4.2 Analyze alternatives (i.e., perform trade studies) to explore various technical approaches for satisfying the requirements that are suitable for the intended operational environments. (See

CDRL, A005)

4.4.3 Research and develop new capabilities and functionalities for C-sUAS. (See CDRL, A004)

4.4.3.1 Design and develop open architecture for information to move to and from components of system of systems.

4.4.3.2 Demonstrate the ability of the system to consume data from various sensors and direct multiple interceptors to accomplish a dynamic threat scenario

4.4.3.3 Develop algorithms to search areas for potential threats and report their location

4.4.3.4 Develop acquisition techniques using one or many sensor inputs

4.4.3.5 Develop track formation approaches for sensor level and system level tracks

4.4.3.6 Design and prototype modular defeat systems for evaluation

4.4.3.7 Integrate various defeat payloads and calibrate the system of systems to optimize performance around the weapon

4.4.3.8 Model and Simulate high level scenarios to identify and inform automation development.

(See CDRL, A013)

4.4.3.9 Automate the tasking of interceptors to optimize performance against user and PM scenarios using the appropriate AI and ML techniques

4.4.3.10 For each new feature/capability, create feature design documentation. (See

CDRL, A006). The feature design document shall include:

• Statement of feature

• One or more technical approaches (as applicable), including design or implementation alternatives and their pros/cons

• Architecture diagram

• User Interface (UI) changes and diagrams

• Impact analysis

• Data communication standards

• Derived requirements

4.4.3.11 Develop a technology demonstration using sound software and hardware engineering principles. (See CDRLA014)

4.5 Integrate subsystems

4.5.1 Identify possible technology

4.5.2 Develop Software Development Kit (SDK) and integration strategy (See CDRLs, A007, A010 and A015)

4.5.3 Prototype the architecture (See CDRL, A004)

4.5.4 Test and Evaluate performance in the lab and at the test range to be identified by the

Government (See CDRLs, A016 and A017)

4.6 Optimize

4.6.1 Develop and run red team scenarios relevant to the problem space

4.6.2 Develop strategy and road map for iterative enhancements and software releases for lab and field tests (See CDRL, A004)

4.6.3 Evaluate scope of trade space variables and evolve system as scenarios continue to refine

(See CDRL, A004)

4.7 Automate

4.7.1 Identify development strategy, roadmap and timeline for incremental enhancement of a basic architecture (See CDRL, A004)

4.7.2 Evaluate alternatives and implement strategy changes as needed (See CDRL, A005)

4.7.3 Automate according to the trade space data to reduce Detect, ID, Track and Defeat timelines

4.7.4 Demonstrate system in simulation and real life relevant scenarios with a focus on autonomy techniques, their benefits and the overall C-sUAS trade space (Cost, Complexity, effectiveness, adaptability and scalability) (See CDRL, A004)

4.8 Futher Development

4.8.1 Further develop, and integrate emerging technologies and/or Commercial off the Shelf

(COTS) platforms to build upon existing C-sUAS designs. Enhancements shall conform to existing system features and provide backward compatibility.

4.8.2 Further develop capabilities, features, components, and other technologies and integrate them into approved C-sUAS systems.

4.8.3 Ensure further developments to the systems baselines maintain support for all platform and components on legacy system HCL or as directed by the Government.

4.8.4 Problem Reports and Enhancement Requests (PRs/ERs)

4.8.4.1 Present PRs/ERs during the C-sUAS monthly development Configuration Control Board

(CCB). Provide a subject matter expert to discuss the PRs/ERs at each CCB. (See CDRL, A004)

4.8.4.2 Create work plans for CCB approved PRs/ERs. Submit work plans for PRs/ERs in accordance with the C-sUAS CCB Process. Identify the work to be accomplished with AFRL

PM and COTR approval and guidance, a recommended solution, level of effort, required resources, accreditation issues, affected system components/CSCs, and estimates for updates to the documentation. Provide a scope of impact analysis of the recommended change(s). (See

CDRL, A018)

4.8.4.3 Create, test, document, and deliver software/hardware enhancements to resolve CCB approved PRs/ERs into systems baselines. Upon PR/ER work plan approval by AFRL PM, proceed with the enhancement, unit testing, and independent testing, and documentation.

Provide release notes, validation procedures, installation instructions, and removal (backout) instructions for all PRs/ERs. Conduct a schedule impact analysis to determine if any of the testing cycles have to be repeated due to the modifications made to the baselined source code.

Provide a central maintenance capability for the existing baseline software.

4.8.5 Maintain or improve existing capabilities of the currently baselined systems.

4.8.6 Update feature design documents to reflect changes made from the enhancement. (See

CDRL, A019)

4.8.7 Revise documentation to reflect approved baseline changes. Provide Version Description

Document (VDD) specific to this baseline update to reflect all changes incorporated into the baseline. Provide release notes and validation procedures for each baseline release. (See CDRL, A020)

4.8.8 Develop a technology demonstration using sound software engineering principles.

4.9 Operational Assessment

4.9.1 System Delivery and Deployment -- Complete all new deployments in accordance with process described in Paragraph 4.9.2 Deployment Process. Complete all upgrades in accordance with process described in Paragraph 4.9.2.3 Site Preparation.

4.9.1.1 Perform system deployments and installations at site facilities.

4.9.1.2 Procure hardware for customer sites and perform system deployments at approved sites.

4.9.1.3 Perform upgrades to systems operational sites.

4.9.1.4 Provide the capability to support simultaneous deployment installations at any given time.

4.9.2 Deployment Process

4.9.2.1 Conduct Site Survey

4.9.2.1.1 Location selection, Line of Site (LOS) survey, RF survey and collect other relevant information for the installation. (See CDRL, A021)

4.9.2.2 Provide an Installation Plan. The results of the site survey will be used to finalize the implementation approach for the site to include project schedule, conceptual site architecture, hardware and software recommendations, and detailed description of the system configurations.

The proposed installation shall facilitate the smallest impact possible to each site upon deployment of equipment. (See CDRL, A022)

4.9.2.3 Site Preparation

4.9.2.3.1 Plan the incorporation of the system into the individual site. Assist site with development of site specific Concept of Operations (CONOPS).

4.9.2.3.2 Provide site with guidance on creating and submitting required security documentation such as Standard Operating Procedures, System Security Plan.

4.9.2.3.3 Schedule the site for installation and conduct final site readiness review (SRR) just prior to installation to ensure all equipment, personnel and approvals are in place prior to installation.

4.9.2.4 Provide Engineering Support for system familiarization.

4.9.2.5 Coordinate and conduct site installation and integration with Site Personnel

4.9.2.6 Provide post installation quick reaction support to mitigate issues not discovered during installation.

4.9.2.7 Provide Familiarization material for prototype systems.

4.10 Testing

4.10.1 Perform thorough Verification and Validation (V&V) for each release/enhancement/baseline to ensure compliance with functional, non-functional, and security requirements.

4.10.2 Research, Development, Test, and Evaluation (RDT&E)/Developmental Test and

Evaluation (DT&E) -- For each operational release, enhancement, or new baseline development, perform thorough, multi-faceted testing, as appropriate, from the list below:

• Unit testing

• Integration testing

• System testing

• Regression testing

• Cybersecurity (security/STIG/NIST conformance) testing

• Backlog bug fix V&V

• Performance testing (stress (load)/longevity term)

• Component configuration validation

• Hardware environmental testing

4.10.3 Apply agile software development methods such as continuous integration and continuous testing.

4.10.4 Apply open systems tenets using proven but modern languages, tools, and design patterns.

4.10.5 Create test report(s) to include test cases executed, expected test results, actual test results, issues encountered, test duration, and metrics (where they can be leveraged to gain efficiencies and insight to improve the process). (See CDRLs, A023, A024, A025 and A026)

4.10.6 Flight Testing

4.10.6.1 The performer shall provide, in coordination with the AFRL PM/COTR, all necessary documentation for submission to the Flight Test Office (AFRL/DO)

4.10.6.2 Provide presentation materials and other documentation needed to support the

Technical Review Board (TRB).

4.10.6.3 Attend boards applicable to the task order with expertise covering all aspects of the testing such as electromagnetic radiation, platform or payload performance, data gathering requirements, and test resources such as STE.

4.10.7 Support Operational Test and Evaluation (OT&E) events as directed by the COTR.

4.10.8 Prepare presentation materials, documentation, and artifacts (See CDRLs A004, A023, A024, A025 and A026)

4.11 Hardware/Software Delivery

4.11.1 Deliver all software and hardware developed, assembled, or acquired to the Government.

Deliver all design documents to include, software development kits (SDKs), technical data package, hardware interface control documents, and software source and object (executable) code. (See CDRLs, A008, A015, A027, A028 and A029)

4.11.2 Acquire Government approved hardware incidental to the design and development, to support system requirements, development or demonstration of prototypes, or system development (testing, prototyping) activities. Include licensing, maintenance, and diagnostics support software and software test equipment. Arrange for delivery of hardware, software, and licenses to Government designated sites.

4.11.3 Notify the Government at least weekly of source code changes, bug reports and known issues.

4.12 Program Management (PM)

4.12.1 Determine the status of the effort and report progress towards accomplishment of the requirements. Attend weekly and/or monthly progress meetings and Program Management

Reviews (PMRs) as identified by the AFRL PM. (See CDRL, A001)

4.12.2 Determine the status of funding required for order performance. (See CDRLs, A002 and

A003)

4.12.3 Conduct oral presentations at such times and places designated by the AFRL PM.

Provide status of technical progress made to date in performance of the task order during presentations. (See CDRL, A004)

4.12.3.1 Risk Management

4.12.3.1.1 Actively and continuously identify and manage technical, cost, and schedule risks.

Keep the Government PM informed of risk status and handling plans at the weekly and/or progress meetings. Immediately inform the Government PM if any risk is realized and becomes an issue. (See CDRL, A001)

4.12.3.1.2 Identify, assess, and track issues in addition to risks. .

4.12.3.1.3 Identify, assess, and track opportunities in addition to risks. Clearly articulate and assess any risks associated with pursuing any opportunity.

4.12.3.1.4 Apply industry best practices for risk, opportunity, and issue identification, assessment, and handling.

4.12.3.1.5 Ensure risks are not accounted for at multiple levels thereby overcompensating for them (e.g., engineer provides engineering margin to account for the risk, then the PM applies additional margin accounting for the same risk). This applies to basis of estimates for risk level, time, cost, etc.

4.12.4 Integrated Master Schedule (IMS)

4.12.4.1 Create, update, and maintain an IMS. The schedule shall include Original Start and Original End dates, which will not be changed after task award; Baseline Start and Baseline

End dates, which reflect the current task baseline and shall not be changed without Government concurrence; and Actual Start and Actual End dates, which represent the actual dates the activities will or did occur. (See CDRL, A030)

4.12.4.2 Provide a detailed breakdown of all required reviews that demonstrate keen insight into the software development process. Provide projected start and completion dates for all tasks, including projected dates for all evolutionary software prototypes to be delivered to the

Government. At a minimum, the IMS milestones shall include the appropriate technical reviews, final code delivery, and document delivery dates.

4.12.4.3 Provide status of all baseline development, test, training, schedule, and sustainment activities at the regularly scheduled C-sUAS Integrated Product Team (IPT) meetings and when directed by the AFRL PM).

4.12.5 Document all technical work accomplished and information gained during performance of this task order. Include all pertinent observations, nature of problems, positive and negative results, and design criteria established where applicable. Document procedures followed, processes developed, “Lessons Learned,” etc. Document the details of all technical work to permit full understanding of the techniques and procedures used in the evolving technology or processes developed. Cross-reference separate design, engineering, or process specifications delivered to permit a full understanding of the total acquisition. (See CDRL, A032)

4.13 Security Requirements

4.13.1 Manage all aspects of security associated with performance to include personnel security access, security clearance information preparation, and liaison with Government POCs for security related items. Capture and maintain information regarding all contract personnel and security related data. The personnel information maintained and provided to the AFRL PM shall include a list of all personnel performing under the contract, security clearance levels, sponsors, dates for performance, and government identification materials (i.e. Common Access Cards

(CACs), agency badges). Provide information supporting visit requests, CACs, personnel clearance, and other security related activities. Provide softcopy and hardcopy of managed information assuring proper privacy markings and controls are utilized. Format will be

Contractor-suggested, Government-approved format.

4.13.2 Access To Private Information: Performance may require access to information covered by the Privacy Act of 1974; therefore, contractor personnel shall safeguard all such information in accordance with the Privacy Act of 1974 at all times, and shall not release such information to unauthorized persons.

4.13.3 Export Control: The Contractor may be required to carry out technical data/information exports in support of the requirements. Ensure all items have appropriate control markings to include Scientific and Technical Information (STINFO), export control and classification.

Comply with applicable International Traffic in Arms Regulations (ITAR) requirements to meet the needs of the Government. Maintain compliance with all governing directives and policies.

Prepare and submit required Export Control documentation and requests with the appropriate

Government department or agency.

4.13.4 Security Clearance: Compliance with DoD 5200.2-R, Personnel Security Program, January 1987 for access to Top Secret/Special Compartmented Information (TS/SCI) information, systems and facilities is mandatory. All contractor personnel shall be citizens of the

United States of America.

4.13.5 Safeguarding Classified Information

4.13.5.1 Comply with the DD Form 254, DoD Contract Security Classification

Specification and attachments. Potential security violations or incidents shall be reported immediately to the AFRL PM and in writing no later than the next work day after the incident occurred. Proper controls shall be utilized (i.e., secure telephone, classified fax, classified e-mail), based on the security classification of the information associated with the possible violation.

4.13.5.2 Conform to the provisions of DoD 5220.22-M, National Industrial Security

Program Operating Manual (NISPOM), for safeguarding classified information and material contained on the controlled system(s)/network(s). Ensure access is provided only to those persons who have the proper security clearance, a need to know and have been trained in proper safeguarding procedures.

4.13.5.3 Participate in the management of security access, preparation of security clearance data/forms, access requests, and coordination with Government security POCs.

4.13.6 Physical Security

4.13.6.1 Safeguard all Government property. Ensure all Government facilities, equipment, and materials are secured. Follow regulatory guidance concerning maintenance, use, and safety of Government facilities.

4.13.6.2 For Performance of Services during Emergency Conditions, local procedures shall be followed.

4.13.7 Security Violations - Potential security violations or incidents shall be reported immediately to the AFRL PM and AFRL/RIOF verbally and in writing no later than the next work day after the incident occurred or was discovered.

4.14 Safety Requirements

4.14.1 Comply with all safety and health requirements necessary for the protection of personnel, facilities and equipment including, but not limited to, the Occupational Safety and Health Act

(OSHA) (Public Law 91-596) and all applicable OSHA standards, while performing this contract at the Air Force Research Laboratory (AFRL), Rome Research Site (RRS), Rome NY. It is the contractor’s sole responsibility to make certain that all safety requirements are met.

4.14.2 Maintain a written safety program for compliance with the applicable OSHA standards, and make said program available for review by the Government upon request by the Contracting

Officer.

4.14.3 Support Government Safety Review Board (SRB) and related activities, by preparing necessary documentation or briefings. Provide detailed data to support establishment adequacy or conformance such as test platform and payload airworthiness. See section 5.1.1.6 for TRB and flight test plan information.

4.14.4 In the event of a mishap, or a “near miss” during the performance of this contract at

AFRL RRS, notify the Contracting Officer, AFRL PM, or the DET 4 Safety Office in an expeditious manner. Written notification shall be provided to the Contracting Officer (who will forward a copy to the DET 4 Safety Office) within 72 hours and shall include the following information (Air Force Form 978 Supervisors Mishap Report may be used):

• Contract, Contract number, Name and Title of Person(s) Reporting

• Date, Time and exact location of accident/incident

• Brief Narrative of accident/incident (events leading to accident/incident)

• Cause of accident/incident (if known)

• Type of injuries resulting from the accident/incident and estimated cost of accident/incident (material and labor to replace/repair)

• Nomenclature of equipment involved in accident/incident

• Personnel involved in accident/incident

• Corrective Actions (taken or proposed)

• Other pertinent information

4.15 Travel

4.15.1 Participate in technical assistance visits, integration visits, site surveys, TEM, testing events, demonstrations, and program or technical reviews as required by the AFRL PM.

4.15.2 Coordinate specific travel arrangements with the individual AFRL PM to obtain advance approval for the travel about to be conducted. The contractor’s request for travel shall be in writing and contain the dates, locations, number of people traveling, purpose, duration and estimated costs of the travel.

4.15.3 Prepare necessary visit requests and coordination needed to attend a given meeting or event (with the advanced notice prescribed by the location/site).

4.15.4 Overseas travel: Comply with all government foreign travel requirements. Additional information and/or training maybe required on a country by country basis. Possible overseas travel includes Germany, Korea, Japan, Iraq, Afghanistan, Italy, NATO countries (all Europe), CENTCOM AOR, AFRICOM AOR and PACAF AOR.

4.15.5 Unless otherwise specified by the Government, develop a Trip Report detailing, at a minimum, stakeholder positions/feedback, accomplished tasks, unaccomplished tasks, open issues, and new issues. (See CDRL, A031)

4.2.5 Prototype software, test on a variety of hardware and establish a hardware compatibility list (HCL) that should be maintained, updated and delivered to the government (See CDRLs, A006, A007, A008 and A009)

4.12.5 Document all technical work accomplished and information gained during performance of this task order. Include all pertinent observations, nature of problems, positive and negative results, and design criteria established where applicable. Do...