CBP NII CIP RFP 70B04C25R00000011 STATEMENT OF WORK - ATTACHMENT 1 - FRD.pdf

NII-I CIP Functional Requirements Document

Attachment 1 NII Functional Requirements Document (FRD)

Common Integration Platform (CIP) / Common Viewer (CV)

1 Purpose The purpose of this functional requirements document is to capture the functional requirements for the CIP which incorporates a CV for the viewing of meta data and image files for NII systems in the land/rail, seaport and air environments. The CIP displays the NII image data along with relevant information from other CBP applications supporting an integrated workflow to officers in the field.

The CIP will include integrated data management, and operational changes, which will improve CBP’s overall scanning throughput and detection effectiveness to interdict threats at and between land/rail, sea, and air POEs, while deterring illicit activities. Across all vector operations, the solution will include the following capabilities:

• Interoperability and Integrated Processing: NII sensor systems capable of interfacing with other CBP law-enforcement applications via secure data exchanges. Automatic correlation of data with the associative declaration/manifest data from current or planned programmed capabilities within CBP’s trade and travel operations mission space.

• Secure Data Transmission of Images in a standard Format: Secure transmission of data from the NII sensor system to CBP local area wide area networks to the CBP cloud (on Amazon Web Services (AWS) in real time; collected images stored in a uniformed/compatible format, autonomous of system type or manufacturer.

• Centralized Image Analysis: CBP law enforcement personnel capable of retrieving image files and performing real-time image analysis from a remote location/command center.

• Remote Monitoring and Maintenance: Continuous monitoring, transmitting, storing, and synthesizing system performance data in a centralized processing system.

This version of the FRD is limited to CIP requirements for multi/low energy portal (MEP/LEP) land border requirements. Updated requirements will be issued for other vectors as they are identified.

2 Assumptions and Constraints

2.1 Assumptions

CBP Wide Area Network will be available to provide sufficient bandwidth to transmit data to the

CBP Internet Connection Point and interface with analysts on CBP workstations on the CBP network.

The CIP and CV applications will be hosted on the CBP Enterprise Cloud Infrastructure (CECI) for POEs with sufficient bandwidth.

All data will be transmitted to the CBP NII data repository, Automated Radiological Data Integration System--Cloud (ARDIS-C) in real time for archival storage and analysis.

Data older than 14 days old will be archived on ARDIS-C.

Personnel levels will be appropriate to accomplish the action in this CONOPS.

Illegal traffic trends and flows will remain consistent with historical trends (or increase).

Overarching current and future capabilities will provide the operational capacities required to support the CONOPS.

International partnerships and cooperation will remain consistent with current conditions

(or improve).

A Personal Identity Verification (PIV) card will be required to logon to any workstation that accesses the NII-I systems connected to the CBP Network.

NII-I systems will not directly communicate with stakeholders outside of CBP.

The current NII Systems Program of Record remains operational.

2.2 Constraints

Systems must be compliant with the following DHS and CBP Directives:

• DHS Security Policy: DHS Security 4300A Sensitive System Handbook Version 7.0 and CBP Information Systems Security Policies and Procedures Handbook (HB 1400-05D, Version 7.0.

• Technology Maturity: To the greatest extent possible, the CIP will have a Technical Readiness Level (TRL) of 8 or greater.

• CIP will comply with DHS/CBP policy, privacy laws, and regulations.

• Upgrades to CBP Legacy NII Original Equipment Manufacturer (OEM) systems to interface with CIP shall be limited to modifications to export data in UFF format or other agreed upon standard format.

3.0 Methodology

A Model Based Systems Engineering (MBSE) approach was used to develop the FRD. CONOPS Use cases were documented using action/activity corresponding diagrams. Functional requirements and interface controls were derived from the action diagrams. Each of these action diagrams were reviewed by key stakeholders to ensure the completeness of the model. Systems analysis was performed on the integrated systems model to identify and define the Non-functional requirements.

4.0 Functional Requirements

4.1 Context Diagram

Figure 1: CIP Context Diagram

4.1.1 Internal System (White)

4.1.1.1 Common Integration Platform (CIP)

The CIP is a work-flow engine that integrates all needed data flows to support the CBP concepts of operations in a variety of domains.

4.1.1.2 Common Viewer (CV)

The CV is the User Interface of the CIP. It is a thin client web application that displays the required NII data for supporting a desired CBP operation.

4.1.2 External Systems (Grey)

4.1.2.1 SailPoint

SailPoint is the CBP application used to provide enterprise access control to CBP applications, or commonly referred to as "single sign on".

4.1.2.2 Okta

Okta is the CBP application used to authenticate users’ identification on the CBP enterprise.

4.1.2.3 LBI Sync Service

The LBI sync service matches the JSON adjudication messages sent from the CIP with the vehicle when it arrives in primary. Once the vehicle is matched, the JSON message is displayed in the CBP Simplified Arrival Vehicle (SA-V) application.

4.1.2.4 Low Energy Portal

The Low Energy Portal is the NII drive-through portal used for scanning passenger vehicles.

Some systems provide top-down images of the vehicle with some portals providing under vehicle images.

4.1.2.5 Multi Energy Portal (MEP)

The Multi Energy Portal is the NII drive-through portal for scanning trucks crossing the land border. The MEP scans the cab at a lower energy providing for driver safety while scanning the cargo conveyance at a higher energy to detect contraband. Some systems include a backscatter x-ray component. The systems provide a top down and side view transmission images of the cab and cargo conveyance. This may also include backscatter images in addition to the transmission images.

4.1.2.6 Truck Mod

The Truck Mod is a CBP application that interfaces with the CBP ACE application for managing cargo shipments into the U.S. NIID capture of QR codes, License Plates, and DTOPS RFID is passed to Truck Mod to associate the physical cargo with the trade record. The trade record in Truck Mod is updated with the NII adjudication in the command center. When the truck arrives in Primary, the record with the NII adjudication is retrieved and presented to the Primary Officer for their determination on whether to refer or clear. Truck Mod also manages admissibility requirements for the driver.

4.1.2.7 Automated Radiological Data Integration System-Cloud (ARDIS-C) ARDIS-C is the central storage repository for NII data, including sensor and associated metadata. Initially developed to support data storage from Radiation Portal Monitors (RPM) and has since been enhanced to store image data from large scale X-ray sensor systems.

4.1.2.8 Anomaly Detection Algorithms (ADA)

The ADA are algorithms to support the automated detection of anomalies. They consist of artificial intelligence object detection algorithms ensembled to provide an overall assessment of images. The ADA concept is to train from data in the cloud or on-local port servers.

4.1.2.9 NII Sensors

NII sensors includes other legacy NII systems such as RPMs connected to the PRIDE, mobile NII X-ray systems, and fixed NII systems such as gantry X-ray systems.

5 Functional Requirements

5.1 Common Integration Platform

OEM NII X-ray and ancillary systems located in Ports of Entry (POE) operate on a “private” network segregated from the CBP secure network. The OEM systems integrate radiographic imagery data with license plate and Radio Frequency Identification (RFID) data into an Integrated Data Package (IDP) defined by the World Customs Organization Unified File Format, (UFF). The IDP is transmitted over the CBP secure network infrastructure utilizing the Sweeper Interface Control Document (ICD v 1.1.1) to the CIP in the CBP cloud to facilitate parallel processing of data elements by CBP enforcement applications and ADA. CBP workstations with the CV application in Command Centers access the CIP to adjudicate images.

Radiation Portal Monitor (RPM) Alarm The CIP shall integrate RPM alarm data within the IDP.

Initial IDP The CIP shall initiate an IDP from the OEM X-ray system upon first contact with a scanned object in compliance with sweeper ICD V1.1.1.

(note: OEM X-ray systems aggregate RFID, and LPR data into a file which is in UFF format).

IDP Updates The CIP shall update the IDP for the following actions:

Addition of images Corrections to LPR or other conveyance identifier Primary and Secondary Analyst adjudication Analyst annotations

IDP Update To ARDIS-C IDP Updates shall be transmitted to ARDIS-C in sweeper ICD v 1.1.1 format upon completion of the update.

Data Aggregation The CIP shall aggregate NII IDP records at the following six levels:

Location (primary, pre-primary, secondary, mobile) Lane Type of conveyance (truck, passenger vehicle, container) Port Area port Field office National

Note: Data aggregation at the Port, Area Port, Field Office, and National levels is intended to support future command centers at various levels.

Operationally Configurable The CIP shall be configurable to segregate data at a port or field office across the following vectors:

Passenger vehicle Cargo truck Rail Sea cargo Air cargo

Early Read Data The CIP shall transmit the following minimum early-read NII system metadata to ARDIS-C in sweeper ICD v 1.1.1 format for commercial trucks:

Front License Plate Rear License Plate Western Hemisphere Travel Initiative (WHTI) ID card RFID Decal/Transponder Online Procurement System (DTOPS) RFID QR code reads

Meta Data Requirements

The CIP shall create an IDP for each scan of the available aggregated NII sensor data to include the following as a minimum:

Front license plate Passenger and commercial truck

Rear license plate Passenger and commercial truck

Western Hemisphere Travel Initiative (WHTI) ID card RFID Passenger and commercial truck

QR code Commercial truck Decal/Transponder Online Procurement System (DTOPS)

RFID

Commercial truck

Event Log for Audit Purposes The CIP shall create an event log that captures actions related to an IDP.

Automatic Assignment of Workstations The CIP shall assign IDPs to the next open analyst workstation.

Prioritization of Workstations The CIP shall support prioritizing assignment of IDPs to specific workstations to support FAST or SENTRI Concepts of Operations (CONOPS). (note:FAST and SENTRI are CBP programs for facilitating trusted traffic in Cargo and Passenger environments.

Manual Assignment of Workstations The CIP shall be configurable by the supervisor to assign specific categories (such as cargo, or passenger) of IDPs to workstations. (note: This supports command centers which may combine both cargo and passenger operations).

Sort IDPs by Category The CIP shall sort the IDPs by category upon user command.

User Defined Queries The CIP shall create user-defined queries.

User Defined Reports The CIP shall create user-defined reports.

Print Function The CIP shall print selected elements of an IDP upon user command.

5.2 Common Viewer (CV)

Common Viewer Data Quality

The CIP shall detect IDPs with degradations to radiographic Image Quality such as missing, or clipped images.

Common Viewer Data Quality Tag The CIP shall tag images with degraded data quality with the source of the degradation and the OEM system serial number that generated the image.

Common Viewer Data Quality Report The CIP shall generate a data quality report upon command which can be used to identify potential NII system failures.

Supervisor View The CV shall provide a supervisor view. (level 2 access).

User Account Management The CV supervisor view shall enable creation/deletion of user accounts.

Analyst performance monitoring The CV supervisor view shall support monitoring of an individual operator's performance.

Supervisor Oversight The CV supervisor view shall provide operational oversight for all analysts.

Supervisor Override The CV supervisor view shall provide for override capabilities on submitted adjudication.

Supervisor Batch Adjudication The CV supervisor view shall support choosing a batch (multiple records) for adjudicating as non-suspect. (note: This supports clearing the analysis wait queue if needed).

Supervisor Batch Adjudication Tag The CV supervisor view shall tag batch adjudicated IDPs as batch processed.

Supervisor Archive Retrieval The CV supervisor view shall support the retrieval of IDPs from the archive.

CV Analyst View The Common Viewer shall provide an analyst’s view.

License Plate Image(s) The CV shall display the digital image of the license plate(s) (front and rear) with the radiographic images.

Optical Character Recognition (OCR) Correction The CV shall allow the operator to correct the license plate OCR on the same page as the license plate images.

Display License Plate OCR The CV shall display the OCR of the license plates (front and rear).

Front Scene Image The CV shall display a digital front scene image of the vehicle to enable identification of the make and model of the vehicle.

License Plate Image Zoom The CV shall provide a zoom capability for the license plate digital images to facilitate reading them.

Conveyance Length The CV shall display the entire length of the radiographic image of the scanned conveyance.

Number of Images The CV analysts view shall be capable of displaying no less than five radiographic images and two license plate images on a single page. (note: not all NII will require all six images).

Analyst Tools The CV shall provide configurable image analyst toolsets encompassing the functionality of those existing within OEM systems employed in CBP NII operations.

Image Magnification The CV shall increase image magnification upon user command.

Color Palette The CV shall select different color palettes upon user command.

Image Demagnification The CV shall demagnify images upon user command.

Sharpen Edge The CV shall sharpen image edges of the radiographic image upon user command.

Smooth Edge The CV shall smooth edges of the radiographic image upon user command.

Analyst Annotation The CV shall annotate the images upon image user entry.

Bounding Box The CV shall support bounding the annotated items of interest in images upon analyst entry.

Brightness The CV shall adjust image brightness upon user command.

ADA Annotations The CV shall display ADA annotations on NII images, upon operator command.

Display UFF data The CV shall display all UFF (latest version) data per the SOW requirement.

Hot Keys The CV analyst tools shall include hot keys to enable the specific tool upon operator command.

Mouse Control The CV shall utilize mouse scroll wheel for zooming for all tools incorporating image zoom.

Analyst View Sequence The analyst view shall automatically be populated with the next IDP in a first in first out sequence upon adjudicating an IDP.

6.0 Non-Functional Requirements

6.1 Data Storage

The CIP Data Store (DS) shall provide storage for no less than 30 day’s worth of files per installed site.

6.1.1 Auto-delete Function

The CIP system DS shall provide the Administrator (level 3 access) an option for the auto delete of non-suspect files that are over 14 days old.

6.1.2 Data Retrieve Function

The CIP shall retrieve DS IDPs upon operator command.

6.1.3 Data Update Function

The CIP shall update the IDP for the following actions:

Addition of images Corrections to LPR Analyst annotations Secondary inspection result

6.1.4 Data Retrieve from ARDIS-C

The CIP shall retrieve DS IDPs older than 14 days from the ARDIS-C via the ARDIS-C interface upon operator command.

6.1.5 Manual Delete Function

The CIP shall delete records upon supervisor (level 2) command.

6.1.6 Data Store on AWS

The CIP data store shall be hosted on CECI.

6.2 Command Center

Command Centers will vary upon the location (local to a POE or regional), the physical size of a facility, and whether they combine cargo and passenger operations. The following provides the functional requirements for the command center. Command Center Hardware requirements are included in the Statement of Work (SOW).

6.2.1 Command Center Situational Wall (SW)

The CIP shall provide the minimum following configurable information to the situational wall:

Border Security Deployment Program (BSDP) Surveillance Video (note: BSDP video is via HDMI input to SW.

Analysis Status Dashboard System Health and Status RPM display NII Tunnel Camera Video

6.2.1.1 NII Tunnel Camera Video

The CIP situational wall shall display NII system tunnel video for each portal in the command center area of responsibility.

6.2.1.2 Analysis Status Dashboard

The CIP situational wall shall display an analysis status dashboard that provides the queue of IDPs waiting for assignment to an analyst.

6.2.1.2.1 Waiting Analysis Queue

The analysis status dashboard shall sort the IDPs waiting for analyst assignment by first in first out order.

6.2.1.2.1.1 Number of IDPs in the Analysis Queue

The number of vehicles displayed in the Analysis Queue shall be configured upon command by the supervisor.

6.2.1.2.2 Analysis Wait Time

The analysis status dashboard shall indicate the length of time the IDPs have been waiting assignment to an analyst by color coding a minimum of three time periods. (example: 0-15 green, 16-30 yellow, greater than 30 red).

6.2.1.2.2 Analysis Wait Time Color Configuration

The supervisor shall be capable of configuring the wait time periods to be displayed for each color.

6.2.1.2.3 Analysis Under Review Queue

The analysis status dashboard shall display IDPs assigned to analysts.

6.2.1.2.4 Analysis Review Time

The status dashboard shall indicate the length of time each IDP has been in review.

6.2.1.2.5 Configuration of the Analysis Status Dashboard

The analysis status dashboard shall be configurable to accommodate the minimum following workflows:

Land cargo vehicle Land passenger vehicle Rail cargo Air cargo Seaport cargo

6.2.1.3 Health and Status (H&S) Dashboard

The system H&S dashboard shall display the NII Radiation Operations Center (NROC) dashboard for systems within the command center's area of responsibility.

6.2.1.3.1 Configure H&S Dashboard

The CIP H&S Dashboard shall be configurable to display the following minimum six levels:

Lane Type of conveyance (truck, passenger vehicle, container) Port Area port Field office National

6.2.1.3.2 Display Area / Port Health and Status

The CIP shall aggregate health and status data for display of local POE / regional NII systems integrated with a given site/region.

6.2.1.3.3 Automated H&S Alerts

The CIP shall provide automated NII system fault alerts to CBP command center supervisors.

6.2.1.3.4 Traffic Control Status

The CIP H&S Board shall display status for each traffic control.

6.3 Interface Requirements

6.3.1 User Interfaces

6.3.2 Hardware Interfaces

6.3.2.1 ARDIS-C Health and Status Interface

The CIP shall aggregate NII system data the following data for network transmission to ARDIS- C:

System Status Fault Configuration MEP/LEP Operating/Standby/off Error code Hardware/software

LPR (Front/Rear) Operating/Standby/off Error code Hardware/software RFID Operating/Standby/off Error code Hardware/software

6.3.2.2 Command Center Workstations

The Command Center workstations shall be compliant with the latest CBP Technical Reference Model (TRM) specification.

6.3.2.3 Command Center Workstation Displays

The Command Center workstation monitors shall be a minimum of 38” in size.

6.3.2.4 Uninterruptable Power Supply (UPS)

The Command Center shall include an Uninterrupted Power Supply (UPS) to maintain power sufficient for each workstation for thirty (30) minutes.

6.3.2.5 Command Center Power Conditioning

The Command Center shall include power conditioning to protect workstations from power surges.

6.3.2.6 Situation Wall (SW)

The SW shall include a high definition, large monitor (55” or larger) for each Closed Circuit TV / Pan Tilt Zoom (PTZ) system for each Scanning system.

6.3.2.7 SW Organization

Each Scanning system display shall be collocated and organized with a designated section of the wall dedicated to each system. (Note: the intent of this configuration is so that a supervisor can view all of the activities associated with a Unit operation in one location).

6.3.2.8 SW News Feed

The SW shall include one (1) high definition, large screen TV (50” or greater) for monitoring news and weather channels.

6.3.3 Software Interfaces

6.3.3.1 Anomaly Detection Algorithm (ADA) Interface

The CIP shall provide an Application Programming Interface (API) for the Anomaly Detection Algorithm software component to aid NII analysts in the adjudication of IDP X-ray images.

6.3.3.2 Simplified Arrival Vehicle (SA-V) Interface

The CIP shall interface with the SA-V application using the NII/Land Border Integration (LBI) ICD(version 5.5 or later) that supports pre-primary passenger vehicle scanning.

6.3.3.3 ARDIS-C Interface

The CIP shall integrate with the CBP ARDIS-C utilizing Sweeper ICD (v1.1.1 or later).

6.3.3.3.1 CBP Audit Interface

The IP event log shall interface with the CBP audit application.

6.3.3.3.2 CBP Identity Authentication Interface

The CIP shall interface with the CBP identification authentication application, OKTA

6.3.3.3.3 CBP User Account Management Interface

The CIP shall interface with the CBP user account management interface, SailPoint.

6.3.4 Communications Interfaces

6.3.4.1 Export Reports

The CIP shall export reports to CBP approved removable media.

6.3.4.2 CBP Network

The CIP shall transmit the IDP to ARDIS-C hosted on the CBP AWS cloud, using virtual routing and forwarding protocol over CBP network infrastructure.

6.4 Performance Requirements

6.4.1 CV Response Time

The CV response to an operator command shall not exceed 2 (Threshold), 1 (Objective) second from operator command. (note: requirement should continue to be met as deployment is scaled).

6.4.2 IDP Analysis Queue Update Latency

The CV shall display the IDP on the IDP list with a delay of no more than 10 (Threshold), 5 (Objective) seconds upon transmission of IDP from OEM NII system. (note: assumes bandwidth is sufficient).

6.4.3 Analyst View Latency

The CIP system shall display a new IDP with a delay of no more than mean time of 5 (Threshold), 3 (Objective) seconds upon analyst adjudication of the previous IDP. (note: assumes bandwidth is sufficient and requirement is met as CIP is scaled).

6.4.4 Data Acquisition Latency

The CIP shall transmit all sweeper ICD v1.1.1 messages from the NII MEP transmission time to ARDIS-C within a mean time of 12 (Threshold), 7(Objective) seconds. (note: assumes bandwidth is sufficient).

6.4.5 CIP Scalability

The CIP shall process 675 (Threshold), 937 (Objective) IDP transactions per minute. (Note:

transaction includes all functions associated with processing an IDP).

6.4.6 CIP to ARDIS-C update Latency

The CIP system shall transmit sweeper ICD update messages to ARDIS-C from the time the operator enters the update to receipt in ARDIS-C with a mean time of 2 (Threshold), 1 (Objective) seconds or less to make informed decisions.

6.5 Security and Privacy Requirements

6.5.1 CBP Warning Banner

The CV shall display a Warning Banner on displays during user account logon, as follows:

"You are accessing a U.S. Government information system, which includes (1) this computer, (2) this computer network, (3) all computers connected to this network and (4) all devices and storage media attached to this network or to a computer on this network. This information system is provided for U.S. Government-authorized use only.

Unauthorized or improper use or access of this system may result in disciplinary action, as well as civil and criminal penalties.

By using this information system, you understand and consent to the following:

• You have no reasonable expectation of privacy when you use this information system; this includes any communications or data transiting, stored on, originated from or directed to this information system. At any time, and for any lawful government purpose, the government may monitor, intercept, search and seize any communication or data transiting, stored on, originated from or directed to or from this information system.

• The government may disclose or use any communications or data transiting, stored on, originated from or directed to or from this information system for any lawful government purpose.

• You are NOT authorized to process classified information on this information system.”

6.5.1.1 Warning Banner Acknowledgement

The CV shall prompt the user to accept the Warning Banner language before the user can authenticate with the user ID and password to access the system.

6.5.2 FIPS 140-2 Compliance

The CIP DS shall comply with FIPS 140-2 Level 2 or greater Security Requirement for Cryptographic Modules.

6.5.3 CBP Access Control

The CIP shall comply with CBP cybersecurity system access requirements.

6.5.3.1 PIV-enabled

CIP shall provide PIV-enabled single sign on access for automated identity and authentication.

6.5.3.2 Role-based Access

CIP shall provide three levels of role-based access.

Analyst (Operator 1) Supervisor (Operator 2) Administrator (Operator 3)

6.5.3.2.1 Logical Access

The CIP shall only allow Operator 3 (i.e., the Administrator) to set logical access to audit/event records.

6.5.3.2.2 Restricted Access to System Resources

The CIP shall only allow Operator 3 (i.e., the Administrator) to set logical access to system resources of the integrated components.

6.5.3.3 User Management (On-premises)

The CIP shall be capable of secure on-premises user management (access control).

6.5.3.4 User Management (Cloud)

The CIP shall be capable of secure cloud user management (access control).

6.5.4 Anti-Virus and Malware Protection

The CIP shall utilize CBP-approved security software.

6.5.5 Denial of Service Attack

The CIP shall be cyber resilient to denial-of-service (DOS) attacks; revert to stand-alone (T), no change to operations (O).

6.5.6 Degradation of Service

The CIP shall be cyber resilient to attacks that cause degradation of service.

6.5.7 Access Control

The CIP shall integrate with the CBP enterprise and utilize PIV access.

6.5.8 Malicious Incidents

The CIP shall be cyber resilient to malicious incidents; Notify (Threshold), Prevent (Objective).

6.5.9 Data Manipulation

The CIP shall be cyber resilient to data manipulation; Notify (Threshold), Prevent (Objective).

6.5.10 Non-Malicious Incidents

The CIP shall be cyber resilient to non-malicious incidents; Notify (Threshold), Prevent (Objective).

6.5.11 Exfiltration Attacks

The CIP shall be cyber resilient to exfiltration attacks; Notify (Threshold), Prevent (Objective).

6.5.12 Security Updates

The CIP shall be capable of receiving operating system security patches and updates on a regular basis.

6.5.13 Access to External Information Systems Restricted

The CIP shall be capable of executing functions without access to an external information system.

6.5.14 CBP Enterprise Security Notification Service

The CIP shall leverage CBP enterprise security notification services for network security alert monitoring.

6.5.15 DHS 4300 Sensitive Systems Handbook Compliance

CIP shall comply with the DHS 4300A Sensitive Systems Handbook.

6.5.16 CBP 1400-05D Information Systems Compliance

The CIP shall comply with CBP 1400-05D Information Systems Security Policies and Procedures guidelines for access control.

6.6 Human Systems Integration (HSI) Requirements

6.6.1 Training Platform for Analysts

The CIP shall provide an integrated common viewer training platform for CBP image analysts.

6.6.1.1 Threat Insertion

The CIP system training capability shall provide the supervisor the ability to insert NII training IDPs from actual seizures across the enterprise.

6.6.1.2 Analyst Metrics

The CIP training platform shall provide metrics for evaluating analysts in a training environment.

6.6.2 Training Platform for Maintainers

The CIP training platform shall allow an Administrator to introduce a library of commonly expected CIP maintenance failures for training maintenance technicians.

6.7 Environmental, Safety and Occupational Health Requirements The CIP shall comply with Occupational Safety and Health Administration (OSHA) regulations.

6.8 Interoperability Requirements

6.8.1 NII OEM X-ray System Interface

The CIP shall interface with OEM NII cargo X-ray systems using the UFF (e.g. UFF v3.0, or subsequent version).

6.8.2 Integration with Radiation Detection Equipment (RDE)

The CIP shall interface with RDE using N42.42, PRIDE ICD (latest version).

6.8.3 NII OEM X-ray System Interface for Passenger Vehicles

The CIP shall interface with OEM NII passenger vehicle X-ray systems using the UFF (e.g. UFF v3.0, or subsequent version).

6.8.4 Interoperability with Chemical Substance Identification Systems The CIP shall interface with Chemical Substance Identification Systems.

6.8.4.1 Chemical Substance Library

The CIP shall include a Chemical Substance Library.

6.8.4.2 Configurable Chemical Substance Library

The CIP Chemical Substance Library shall be configurable by an Administrator.

6.9 Reliability Requirements

Materiel Reliability (MR) is a measure of the probability that systems and/or key subsystems will perform without failure over a specific interval. MR must be sufficient to support the capability needed for the mission. MR is generally expressed in terms of a Mean Time Between Failure (MTBF), and once operational can be measured by dividing actual operating hours by the number of failures experienced during a specific interval. MR may initially be expressed as a desired failure-free interval that can be converted to MTBF for use as a Key Performance Attribute (KPA). Specific criteria for defining operating hours and failure criteria must be provided together with the KPA.

The Cost-Wise Readiness (CWR) MR KPA as defined for the system and/or key subsystems shall be greater than or equal to 1000 hours mean time between failure.

Material Reliability (MR) = MTBF = Total Operating Hours Total Number of Failures

6.9.1 MTBF

The following are minimum requirements for system and/or key subsystem(s) readiness drivers:

CWR METRIC ACRONYM CWR REQUIREMENT

Mean Time Between Failure MR = MTBF > 1,000 Hours

6.10 Availability Requirements

Materiel Availability (MA) is a measure of the percentage of the total inventory of the system and/or key subsystems operational (ready for tasking) and capable of performing an assigned mission over a given time. This can be expressed as the number of operationally available systems and key subsystems divided by the total population. MA also indicates the percentage of time that systems and/or key subsystems are operationally capable of performing an assigned mission and can be expressed as uptime divided by uptime plus downtime. Determining the optimum value for MA requires a comprehensive analysis of the system and/or key subsystems and their planned use, including the planned operating environment, operating tempo, reliability alternatives, maintenance approaches, and supply chain solutions. MA is largely influenced by system and/or key subsystem downtime, both planned and unplanned, requiring the early examination and determination of critical factors such as the total number of systems and/or key subsystems to be fielded and the major categories and drivers of system and/or key subsystem downtime. MA must address the total population of systems and/or key subsystems planned for operational use, including those temporarily in a non-operational status once placed into service.

The total lifecycle timeframe, from placement into operational service through the planned end of service life, must be included.

6.10.1 CIP System Availability

The CIP shall meet system availability of 99.99%.

6.10.2 CWR Materiel Availability KPM as Defined for the Inventory of Systems The CWR Materiel Availability KPM as defined for the inventory of systems and/or key subsystems shall be greater than or equal to 95%.

Material Availability (MA) = Am =

Number of Systems and/or Key Subsystems Operational ** Total Population of Systems and/or Key Subsystems

Includes spares **Operational means in a materiel condition such that the system and/or key subsystems are capable of performing an identified mission for which they were designed.

6.10.2.1 CWR Materiel Availability (Systems/Key Subsystems)

The following are minimum requirements for system and/or key subsystem(s) readiness drivers:

CWR METRIC ACRONYM CWR REQUIREMENT

Materiel Availability (systems/key subsystems)

MA = Am > 95%

6.10.3 CWR Materiel Availability KPM as Defined for IT Systems The CWR Materiel Availability KPM as defined for software/Information Technology (IT) systems, services, and functions shall be greater than or equal to 98%.

MA is a number between O and 100 that provides the average percentage of time that software/Information Technology (IT) systems, services, and functions are capable of operational use during a specified period.

An MA shall be calculated during the designated normal operating period by using the following:

Material Availability (MA) = Am =

Uptime Uptime + Downtime (includes planned and unplanned)

6.10.3.1 CWR Materiel Availability IT Systems, Services, and Functions The following are minimum requirements for system and/or key subsystem(s) readiness drivers:

CWR METRIC ACRONYM

CWR

REQUIREMENT

Materiel Availability (software/Information Technology (IT) systems, services, and functions)

MA = Am > 98%

6.11 Maintainability Requirements

6.11.1 Mean Downtime

Mean Downtime (MDT) is the average total downtime required to restore a system and/or key subsystems to their full operational capabilities. MDT includes the time from reporting of a system and/or key subsystems being down to the system and key subsystems being given back to operations for use. MDT includes administrative time of reporting, logistics and materiel’s procurement, and lockout/tag out of equipment, etc. for repair.

The CWR Materiel Mean Downtime KPA as defined for the system and/or key subsystems shall be less than or equal to 24 hours.

Mean Downtime = MDT

Total Downtime for All Failures (corrective and preventive) Total Number of Failures (corrective and preventive)

6.11.1.1 CWR MDT

The following are minimum requirements for system and/or key subsystem(s) readiness drivers:

CWR METRIC ACRONYM CWR REQUIREMENT

Mean Downtime MDT < 24 Hours

6.12 Mobility Requirements

6.12.1 Mobile Operations

The CIP CV shall operate on a tablet that meets CBP TRM requirements.

6.13 Survivability Requirements

6.13.1 Indoor Environment

The CIP hardware shall operate without degradation in its intended indoor environment.

6.13.2 Outdoor Environment

The CIP hardware shall operate without degradation in its intended outdoor environment.