70T04018R9CAP1094_-_Addendums_A_-_F.pdf

Addendum A: List of Applicable Documents

The following specifications, handbooks, orders, standards, and drawings form a part of the contract SOW and are applicable to the extent specified herein. The latest version of these documents as of the contract date shall apply, unless a specific date for the document is specified below.

Reference Document Location

DD Form 254 Contract Security Classification Specification http://www.dtic.mil/whs/direct ives

49 CFR Parts 15 and

Protection of Sensitive Security Information http://ecfr.gpoaccess.gov

Department of Homeland Security (DHS) Management Directive (MD) 11042.1

Safeguarding Sensitive But Unclassified (For Official Use Only) Information http://www.dhs.gov/xfoia/gc_1 254501589035.shtm

DHS MD 11044 Protection of Classified National Security Information Classification Management http://www.dhs.gov/xfoia/gc_1 254501589035.shtm

DHS SCG TSA-002

July 2, 2014

DHS Explosives Detection Systems Information and Data, Security Classification Guide

Available upon request

OST-Configuration Management Plan (Rev D)

Transportation Security Administration Office of Security Technology Configuration Management Plan, 14 June 2011

Available upon request

OSC Configuration Management Guidance Version 1

TSA Configuration Management Guidance, 30 Jun 2015

Available upon request

29 CFR, Part 1910.1096 January 1, 2007

Occupational Safety and Health Standards: Ionizing Radiation, Available upon request

29 CFR, Part 1910.97 Occupational Safety and Health Standards: Nonionizing Radiation

Available upon request

(ANSI/HPS) N43.17-

August 2009

American National Standard Radiation Safety for Personnel Security Screening Systems Using X-Ray or Gamma Radiation

Available upon request

Title 21 CFR 1002.20 Reporting of accidental radiation occurrences

Available upon request

IEEE C95.1-2005 Safety Levels with Respect to Human Exposure to Radio Frequency Electromagnetic Fields, 3 KHz to 300 GHz, Available upon request http://www.dtic.mil/whs/directives http://www.dtic.mil/whs/directives http://ecfr.gpoaccess.gov/ http://www.dhs.gov/xfoia/gc_1254501589035.shtm http://www.dhs.gov/xfoia/gc_1254501589035.shtm http://www.dhs.gov/xfoia/gc_1254501589035.shtm http://www.dhs.gov/xfoia/gc_1254501589035.shtm http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=1002.20

Addendum A: List of Applicable Documents

Reference Document Location revision of C95.1-1991 (Active)

ICNIRP Guideline April 1998

Guidelines for Limiting Exposure to Time- Varying Electric, Magnetic, and Electromagnetic Fields (Up to 300 GHz) Health Physics 74 (4): 494-522

Available upon request

Title 21 CFR 1003.10

Discovery of defect or failure of compliance by manufacturer; notice requirements.

Available upon request

Title 21 CFR 1020.40 Cabinet x-ray systems Available upon request Cybersecurity Requirements

Outline Summary of Cybersecurity Requirements for TSE Vendors

Available upon request

IA Requirements for TSA Government Acquisitions

Baseline Cybersecurity Requirements for Transportation Security Equipment, 7 Jan 2015 version 1.0

Available upon request http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=1002.20

Addendum B: Inspection and Acceptance Supplement

The following information is a supplement to FAR 52.214-4(a) Inspection/Acceptance:

General

Inspection and acceptance of all work and services performed under this contract will be in accordance with the appropriate FAR clauses and SOW sections, as applicable. Final acceptance of all deliverables and or services performed as specified in the SOW.

Scope of Inspection

All deliverables will be inspected for content, completeness, accuracy and conformance to SOW requirements by the COR. The Government requires a period not to exceed thirty (30) calendar days after receipt of final deliverable items for inspection and acceptance or rejection unless otherwise specified in the relevant SOW section.

Basis of Acceptance

The basis for acceptance shall be compliance with the requirements set forth in the Statement of Work, as well as other terms and conditions of this contract.

Reports, documents and narrative type deliverables will be accepted when all discrepancies, errors or other deficiencies identified in writing by the Government have been corrected.

Non-conforming products or services will be rejected. Any rejected deliverable items shall be corrected in accordance with the applicable clauses. Unless otherwise agreed by the parties, deficiencies will be corrected within 30 calendar days of the rejection notice. If the deficiencies cannot be corrected within 30 days, the Contractor will immediately notify the Contracting Officer of the reason for the delay and provide a proposed corrective action plan within 10 working days.

Review of Deliverables

The Government will provide written acceptance, comments and/or change requests, if any, within thirty

(30) business days, from receipt by the Government of the deliverable unless otherwise stated in the relevant SOW section.

Addendum B: Inspection and Acceptance Supplement

Upon receipt of the Government comments, the Contractor shall have up to 30 business days (timeframe is indicated on CDRL) to incorporate the Government's comments and/or change requests and to resubmit the deliverable in its final form.

If written acceptance, comments and/or change requests are not issued by the Government within 30 calendar days of submission, the draft deliverable shall be deemed acceptable as written and the Contractor may proceed with the submission of the final deliverable product.

Contract # TBD Addendum C: CDRLs List

Below is the list of CDRLS for this contract, and the corresponding section of the SOW the CDRL relates to:

CDRL/DID SOW: Description Due C001 3.5.1.1 Personnel List With Proposal and as necessary when a change in Key Personnel occurs.

C002 3.5.1.1 Meeting Minutes Within 5 days of meeting C003 3.5.1.1 PMR Presentation 5 days prior to PMR C004 3.4.1.2 Factory Acceptance Test Plan 30 days after exercise of CLIN C005 3.4.1.3 Factory Acceptance Test Procedures 30 days after exercise of CLIN C006 3.4.1.3 Factory Acceptance Test Report 30 days after exercise of CLIN C007 3.4.1.3

3.5.3.2 Quick Look Report

10 days after report is run

C008 3.5.2 Site Assessment and Survey Report 30 days after authorized Site Visit C009 xx Reserved C010 3.5.3.1 Site Acceptance Test Plan 30 days after exercise of CLIN C011 3.5.3.2 Site Acceptance Test Procedures 30 days after exercise of CLIN C012 3.5.3.2 Site Acceptance Test Report 10 days after SAT C013 xx Reserved C014 xx BHS Integration Test Report (ITR) Not Required C015 xx BHS Interface Control Document Not Required C016 xx Multiplex Network Acceptance Test

Report Not Required C017 3.5.7 Training: Participant Guide 30 days prior to training C018 3.5.7 Training: Classroom Presentation 30 days prior to training C019 6.2.1 DD254 With Proposal and updates as necessary C020 6.3 Physical and Communications Security

Breach/ Incident Report As necessary.

C021 6.2.5 Security Program Plan (SPP) Draft SPP Due with Proposal D001 3.4.1 Operator Manual 30 days after exercise of CLIN D002 3.4.1 Installation Manual 30 days after exercise of CLIN D003 3.4.1 Integration Manual 30 days after exercise of CLIN L016 3.6.2 Warranty Implementation Plan (WIP) With Proposal L017 3.6.3 Parts Obsolescence Management Plan Upon Request of TSA L018 3.6.3 Parts Obsolescence Report Upon Request of TSA L020 3.6.8 Hard Drive Sanitization Upon Request of TSA L021 3.6.9 Radiation Survey Submittal (RSS) As necessary.

Contract # TBD Addendum D: Delivery Schedule

Below is a Notional Delivery Schedule, and the correlating Equipment quantities desired:

Airport Code/

Address

Date to be delivered

CLIN

RSEDS

CLIN

PVS

CLIN

SVS

CLIN

SMK

CLIN

BCR

CLIN

PTR

CLIN

UPS

CLIN

SA

Logan Intl (BOS) 04/8/2019 2 2 2 2 2 2 2 N/A Baton Rouge Metro (BTR) 04/15/2019 2 2 2 2 2 2 2 N/A Des Moines Intl (DSM) 04/22/2019 1 1 1 1 1 1 1 N/A Houston Hobby (HOU) 05/6/2019 2 2 2 2 2 2 2 N/A Houston Intl (IAH) 05/13/2019 1 1 1 1 1 1 1 N/A McCarran Intl (LAS) 05/20/2019 2 2 2 2 2 2 2 2 Chicago-O-Hare Intl (ORD) 06/3/2019 1 1 1 1 1 1 1 N/A Miami Intl (MIA) 06/10/2019 1 1 1 1 1 1 1 N/A New Orleans Intl (MSY) 06/17/2019 2 2 2 2 2 2 2 N/A Fort Meyers (RSW) 06/24/2019 1 1 1 1 1 1 1 N/A

TSA-TSALC TBD 19 18 18 18 18 18 18 N/A

TOTAL: 34 34 34 34 34 34 34 2

Integrated Logistics Support (ILS) Part D – Contract Documents, Exhibits, or Attachments Contract No. HSTS04-17- Attachment D-3 – TSE Metrics Terms and Definitions & RMA Metrics

Addendum E:

Transportation Security Equipment (TSE)

Metrics Terms and Definitions

Reliability, Maintainability & Availability (RMA) Metrics

March 2018

Metrics Terms and Definitions & RMA Metrics March 2018 i

1. Purpose

2. Scope

3. Maintenance Types

3.1 Preventive Maintenance

3.2 Corrective Maintenance

4. Maintenance Activity Collation Process

4.1 Maintenance Elements

4.2 TSE Failure Criticality

4.3 TSE Failure Relevancy

4.4 Maintenance Action Time Points

4.5 Maintenance Action Low-Level Metrics

4.6 Maintenance Action Repair Cycles

4.6.1 No Parts Replacement

4.6.2 Recursions

4.6.3 Time to Repair (M10) Development

4.7 Low-Level Metrics Counting

4.7.1 Closed-Ticket Accounting

4.7.2 Open-Ticket Accounting

5. Operational RMA Metrics

5.1 TSE Reliability Metrics

5.1.1 Mean Time Between Critical Failures

5.1.2 Mean Uptime

5.2 TSE Maintainability Metrics

5.2.1 Mean Downtime

5.2.2 Mean Time to Repair

5.3 TSE Availability Metrics

5.3.1 Operational Availability

6. Average Depot Turn Around Time

Appendix A: List of Definitions

Appendix B: Acronyms

1. Purpose

This document has three purposes:

• To define the process the Transportation Security Administration (TSA) will use to identify, collect, record, and report each preventive and corrective maintenance activity conducted on Transportation Security Equipment (TSE).

• To establish the process for developing the Reliability, Maintainability, & Availability (RMA) metrics that TSA will use to evaluate the performance of TSE during the Operation and Maintenance (O&M) phase of its life cycle. An effective RMA metrics program for operational TSE will provide TSA management with technical insight into the quality of the development and fielding of TSE.

• To support the process TSA uses to develop metrics to evaluate the performance of TSE contracted maintenance service providers (MSP). Contractor performance metrics requirements are delineated in each applicable TSA contract document.

2. Scope

This document delineates the maintenance elements that TSA uses to document the preventative and corrective maintenance activities conducted on TSE. It identifies the requirements for recording these maintenance elements in the TSE Database, including time points and the low-level metrics from those time points associated with each corrective maintenance action. While individual TSA contracts will dictate the requirement for both types of maintenance, this document is focused on unscheduled corrective maintenance actions and the accurate recording of them in a TSE Database. It also provides the process TSA uses to develop RMA metrics from the low-level metrics for evaluating and analyzing the operational performance of deployed TSE throughout its life cycle.

3. Maintenance Types

TSA identifies two types of maintenance activities to support TSE: preventive and corrective.

3.1 Preventive Maintenance

Preventive maintenance improves the reliability of TSE and is scheduled according to the Original Equipment Manufacturers (OEM) manual. All preventive maintenance documentation includes start and end times and a description of the preventative maintenance performed.

Preventive maintenance records are used to demonstrate compliance with contract requirement but are not included in calculations for low-level or RMA metrics.

3.2 Corrective Maintenance

Corrective maintenance is unscheduled and is performed to repair and restore TSE to full mission capability. Corrective maintenance can be performed either on site or at a depot facility.

TSA defines three discrete levels of corrective maintenance as described below.

• Level I Corrective Maintenance (CM) – This is corrective maintenance that is performed as needed to effect minor repairs to TSE that do not require Field Service Technicians (FST) (e.g., some bag jams, reboots, etc.). These activities are normally performed by TSA personnel or their designees and are not addressed under this document.

• Level II Corrective Maintenance (CM) – This is unscheduled corrective maintenance activities performed as needed to effect repairs that always require FSTs.

o Field Service – These activities are performed on site by FSTs with the TSE in Level II CM status. Level II Corrective Maintenance – Field Service will be referred to as CM in this document.

o Telephone Customer Support (TCS) – These activities are performed via telephone consultation with an FST. Level II Corrective Maintenance – Telephone Customer Support (TCS) will be referred to as TCS in this document.

• Level III Depot Maintenance (DM) – This is unscheduled corrective maintenance that requires shipping TSE to a depot facility for repair. Level III Depot Maintenance will be referred to as DM in this document.

4. Maintenance Activity Collation Process

Each TSE corrective maintenance activity must progress through a repair cycle from the initial notification of TSE failure to the return of the TSE to fill mission capability. The process identified in this document will ensure proper recording and reporting of the TSE maintenance activity required by TSA to successfully validate TSE and contractor performance.

4.1 Maintenance Elements

Each corrective maintenance activity begins with the identification of a TSE maintenance requirement. It is important to identify the following maintenance elements in each repair cycle to properly document the corrective maintenance elements:

• TSE failure criticality

• TSE failure relevancy

• Maintenance action time points along the repair cycle

• Maintenance action low-level metrics derived from the maintenance action time points

All maintenance elements identified in this document, as well as other required maintenance activity information identified in Contract Data Requirements Lists (CDRL) and associated Data Item Descriptions (DID), must be collected and recorded for each corrective maintenance activity in the TSE Database. Other information would include, but is not limited to, failure mode indicators and parts replacement information as outlined in individual contracts.

4.2 TSE Failure Criticality

The criticality of a maintenance activity must be validated by the Contractor as soon as possible to ensure the prompt return of TSE to full mission capability and must be documented in the TSE Database. The definitions below are used to determine whether a TSE failure is identified as a critical failure or a non-critical failure.

• Critical (Priority 1 (P1)) – Failures where TSE is unable to perform its required mission and requires immediate corrective maintenance to restore the TSE to full operational condition. Events that TSA Security Officers (TSO) can correct via system resets, simple removal of obstructions, etc., are not categorized as critical failures during the TSA O&M phase.

• Non-Critical (Priority 2 (P2)) – Failures where TSE needs corrective maintenance but still operates at full mission capability until the minor repair is completed.

CM and TCS can be associated with either critical or non-critical failures. Criticality of CM and TCS maintenance activities affect how other maintenance elements are measured. DM is always associated with critical failures.

4.3 TSE Failure Relevancy

For each TSE failure, the relevancy of the failure must also be determined and documented in the TSE Database. The definitions below are used to determine whether a TSE failure is a relevant or non-relevant failure. Both relevant and non-relevant failures can be critical or non-critical.

• Relevant – Failures attributable to the TSE’s inherent performance reliability. This could include such things as wear and tear or part failure. In this case, the inherent reliability of the TSE is directly related to the failure.

• Non-Relevant – Failures verified to be caused by an unintentional or intentional external occurrence in the operational environment not related to the inherent performance reliability of TSE. This could include baggage processing irregularities or operator mishaps that physically damage the TSE. In this case, the inherent reliability of the TSE is unrelated to the failure.

CM, DM, and TCS maintenance activities can be either relevant or non-relevant depending on the cause of the failure.

4.4 Maintenance Action Time Points

TSA relies on the collection of specific maintenance action time points (T-Values) along a corrective maintenance repair cycle to track its progress. Table 1 identifies and defines the 12 T-Values that must be recorded, as applicable, for each repair cycle to document CM, DM, and TCS maintenance actions. These T-Values must identify the date and time of each maintenance action and be provided in real clock times in the TSE location’s local time based on a 24-hour day, seven-day week.

Table 1: Measurement Time Points (T-Values)

ID Description

T1 Call Center Contacted: Time when the Dispatch Contact Facility is initially contacted after a TSE failure occurs.

T2 Technician Dispatched: Time when a FST is contacted to perform the repair.

T3 Technician Starts Diagnostics: Time when the FST begins to diagnose the TSE problem.

T4 Technician Diagnostics Complete: Time when the FST completes the diagnosis and is ready to request any part(s) from the supply chain or start the repair if parts are not required.

T5 Parts Begin Shipment: Time when the supply chain indicates that the part(s) are en route to the FST.

T6 Parts Delivered to Location: Time when the part(s) are delivered locally. Note that this is not necessarily when the part(s) are in the hands of the FST but rather when they are delivered from the supply chain locally; there may be additional time to get the part(s) to the FST to begin the repair.

T7 Technician Begins Repair: Time when the FST is at the TSE location and ready to begin the repair (has all necessary parts and tools).

T8 Technician Begins Testing: Time when the repair has been completed and the FST is ready to verify completion of the repair.

T9 TSE Ready for Signoff: Time when the FST has successfully completed the verification testing and the TSE is ready for the TSA signoff.

T10 TSA Signoff: Time when TSA signs off on the TSE repair and the TSE is ready to be returned to service.

T11 TSE Ready for Setup at the Location: Time when the TSE has returned from the depot or storage or completed depot repair at the site (TSE was in DM status).

T12 Start of Telephone Customer Support: FST decides that phone support is sufficient to resolve the failure.

4.5 Maintenance Action Low-Level Metrics

The T-Values provide the start and end times that are used to derive low-level metrics (M-Values) that measure the duration of discrete maintenance actions along the repair cycle.

The M-Values are derived as the difference between two specific T-Values, resulting in M-Values that must be recorded as applicable for a repair cycle.

Table 2 shows the 13 M-Values that are derived from the T-Values in Table 1 in a straight linear progression. An explanation of each M-Value development process is identified below Table 2.

Note in Table 2 that some T-Values and M-Values can be applicable when a TSE is in either a CM, DM, or TCS repair cycle. Section 4.6.2 explains known deviations in the development of M-Values when a repair cycle is not in a straight linear progression.

Table 2: Low-Level Metrics Summary

Maintenance Path

Low-Level Metric Start Time End Time

ID Description ID Description ID Description

CM & DM M1

Initial Call Center Interaction Time T1 Call Center Contacted T2 Technician

Dispatched

CM & DM M2

Technician Dispatch Time T2 Technician

Dispatched T3 Technician Starts Diagnostics

CM & DM M3

Technician Diagnosis Time T3 Technician Starts

Diagnostics T4 Technician Diagnostics Complete

CM M4 Part(s) Request Time T4 Technician Diagnostics Complete T5 Parts Begin Shipment

CM M5

Part(s) Fulfillment Time T5 Parts Begin Shipment T6 Parts Delivered to

Location

CM M6 Local Logistics Time T6 Parts Delivered to Location T7 Technician Begins

Repair

CM M7

Technician Repair Time T7 Technician Begins

Repair T8 Technician Begins Testing

CM & DM M8

Technician Testing Time T8 Technician Begins

Testing T9 TSE Ready for Signoff

CM & DM M9 TSA Signoff Time T9 TSE Ready for Signoff T10 TSA Signoff

CM M10 Time to Repair T3 Technician Starts

Diagnostics T4 Technician Diagnostics Complete

T7 Technician Begins Repair T9 TSE Ready for

Signoff

DM M11

Depot Turn Around Time (DTAT) T4 Technician

Diagnostics Complete T11 TSE Ready for Setup at the Location

DM M12

Uncrate/Setup at Location Time T11 TSE Ready for Setup at the Location T8 Technician Begins Testing

TCS M1

Initial Call Center Interaction Time T1 Call Center Contacted T12 Start of Telephone

Customer Support

TCS M13

Telephone Customer Support T12 Start of Telephone

Customer Support T9 TSE Ready for Signoff

• M1 – Initial Call Center Interaction Time. This metric measures how long it takes the

Dispatch Contact Facility to gather the initial information about the TSE problem(s) and assign a FST to conduct the repair. It is measured as the time between when the Dispatch Contact Facility is initially contacted after the failure occurs (T1) and the time the FST is contacted to perform the work (T2).

• M2 – Technician Dispatch Time. This metric measures how long it takes for the FST to respond to the service call and arrive at the TSE ready to diagnose and repair the TSE. It is measured as the time between when the FST is initially contacted by the Dispatch Contact Facility to perform the work (T2) and the time that the FST arrives at the failed TSE and begins the diagnosis of the problem (T3).

• M3 – Technician Diagnosis Time. This metric measures how long it takes the FST to diagnose the problem(s) with the TSE. It is measured as the time between when the FST begins the diagnosis of the problem (T3) and when the FST completes the diagnosis and is ready to request any part(s) from the supply chain (T4) or is ready to begin repair if no parts are required (T7). See Section 4.6.1 for this explanation.

• M4 – Part Request Time. This metric measures how long it takes to request the part(s) from the supply chain required for the repair of the TSE. It is measured as the time between when the FST completes the diagnosis and is ready to request any part(s) from the supply chain when parts are required (T4) until the time the supply chain identifies that the part(s) are en route to the local delivery point (T5).

• M5 – Part Fulfillment Time. This metric measures how long it takes the supply chain to deliver (or fulfill) the part(s) required for the repair of the TSE. It is measured as the time between when the supply chain identifies the part(s) are en route to the local delivery point (T5) until the time the part(s) are in fact delivered (T6). Note that this is not necessarily when the part(s) are in the hands of the FST but rather when they are delivered locally from the supply chain; there may be additional time to get the part(s) to the FST at the TSE location to start repairs that would be included in M6.

• M6 – Local Logistics Time. This metric measures any delays incurred where parts have been delivered locally but additional time is required to get the part(s) into the hands of the FST to start the repair of the TSE. It is measured as the time between when part(s) are delivered locally (T6) until they are in the hands of the FST at the TSE location and the FST is ready to begin the repair (T7).

• M7 – Technician Repair Time. This metric measures the repair time for a TSE. This is defined as the time between when the FST has all necessary tools and parts and begins the disassembly of the TSE for repair to when the TSE is reassembled and is ready for verification testing of a successful repair. It is measured as the time between when the FST has all necessary part(s), if required, and tools at the TSE and is ready to begin the repair (T7) until the time the TSE is repaired and ready for verification tests (T8). See Section 4.6.3 for deviation to development of M7.

• M8 - Technician Testing Time. This metric measures the verification testing time for the TSE. It is measured as the time between when the TSE is ready for verification tests (T8) until the time the verification testing is successfully completed and the TSE is ready for the TSA signoff process (T9).

• M9 – TSA Signoff Time. This metric measures the TSA signoff time for the TSE and is the last step before the TSE is placed back into service. It is measured as the time between when the verification testing is successfully completed by the FST and the TSE is ready for the TSA signoff process (T9) until the TSE repair is signed off by TSA and the TSE is ready to be returned to service (T10).

• M10 – Time to Repair. This metric measures the actual repair time for a TSE, including the time required for diagnostics and testing. It is measured as the sum of M3 (T3 to T4), M7 (T7 to T8), and M8 (T8 to T9) (i.e., M10=M3+M7+M8), which ends when the TSE is reassembled and is ready for TSA signoff (T9).

• M11 – Depot Turn Around Time. This metric measures how long a TSE remains away from its designated location for repair at the depot or is put in depot repair status at the site to complete a repair. It is computed as the time between when the diagnosis has been completed and DM decision (T4) has been made until the time the TSE is ready for setup at its designated location after the completion of depot repair (T11).

• M12 – Uncrate/Setup at Location Time. This metric measures how long it takes the TSE to be prepared for re-installation at the airport’s designated location after it has returned from the depot or storage, or has completed depot repair at the site. It is measured as the time between when the TSE has returned from the depot or storage or completed depot repair at the site (T11) until the time the TSE is ready for testing after re-installation at the installed location (T8).

• M13 – Telephone Customer Support Time. This metric measures the time duration of diagnostics and maintenance where the FST directs the airport personnel over the phone (T12) to resolve the failure successfully without an FST visit to the TSE site. It is measured as the time between when TCS begins (T12) and the TSE is ready for TSA signoff (T9).

4.6 Maintenance Action Repair Cycles

Each corrective maintenance activity involves a repair cycle that starts from initial notification until the repair is completed successfully. T-Values must be recorded and applicable low-level metrics (M-Values) derived from the T-values of each maintenance action to quantify the repair cycle and to ensure consistent accurate performance metric development.

These T-Values and M-Values must also be accurately captured in the TSE Database for each corrective maintenance activity in accordance with the TSE CDRL and DID. Therefore, the Contractor should identify any other deviations that would preclude the documentation of T-Values and M-Values as identified above, and should make sure the TSE Database clearly identifies the T-Values used to derive an M-Value. As previously mentioned, it is also important that these T-Values and derived M-Values identify the actual date and time of each maintenance action and be provided in real clock times in the TSE location’s local time based on a 24-hour day, seven-day week.

Some maintenance time points and associated low-level metrics will depend on whether the repair is being accomplished as a CM, DM or TCS repair. Figure 1 below shows an example of three paths (CM, DM or TCS) that TSE can progress through in a repair cycle in a straight linear progression. It identifies the maintenance time points (T-Values, i.e., T1, T2, etc.) and low-level metrics (M-Values, i.e., M1, M2, etc.) along a repair cycle, and illustrates the type of data points and low-level metrics that will be included in the TSE Database.

Figure 1: Repair Cycle Paths

Table 3 shows the standard low-level metrics (M-Values) that will be measured from the T-Values for each failure type in a repair cycle’s linear progression. The dark shaded blocks with no M-Values in the table indicate that the associated low-level metric should not be applicable to that failure type in its repair cycle.

Table 3: Failure Types Failure Type

Low-Level Metrics Level Criticality Relevancy

CM Critical Relevant M1 M2 M3 M4 M5 M6 M7 M8 M9

CM Non-Critical Relevant M1 M2 M3 M4 M5 M6 M7 M8 M9

CM Critical Non- Relevant M1 M2 M3 M4 M5 M6 M7 M8 M9

CM Non-Critical Non- Relevant M1 M2 M3 M4 M5 M6 M7 M8 M9

DM Critical Relevant M1 M2 M3 M11 M12 M8 M9

DM Critical Non- Relevant M1 M2 M3 M11 M12 M8 M9

TCS Critical Relevant M1 M13 M9

TCS Non-Critical Relevant M1 M13 M9

TCS Critical Non- Relevant M1 M13 M9

TCS Non-Critical Non- Relevant M1 M13 M9

Normally, a repair is achieved by progressing through the T-Values and low-level metrics in a straight linear progression as shown in Table 3. However, below are known deviations from the normal linear progression that should be identified and measured accordingly.

4.6.1 No Parts Replacement

The repair cycle previously illustrated in Figure 1 assumes the need for spare parts to complete the repair. In a CM where parts are not required to complete the repair, the T-Values associated with parts replacement would not be recorded, some low-level metrics would not be derived, and other low-level metrics would be ended and started with different T-Values. Following is the progression of a repair cycles without a parts replacement requirement:

• T1 through T4 recorded, and M1, M2 and M3 derived

• T5, T6 and T7 not recorded, and M4, M5 and M6 not derived

• T8 and T9 recorded, M7 derived (from T4 to T8), and M8 and M9 derived normally

4.6.2 Recursions

As a repair cycle progresses, there may be a need to repeat some T-Values or a need to change the type of repair cycle. This is referred to as recursion in the TSA maintenance collection process and can occur in the forms identified below. Each recursion event and the applicable maintenance time points and derived low-level metrics must be captured in the TSE Database for a corrective maintenance activity.

• The first form of recursion occurs when events result in the repetition of maintenance actions in a repair cycle and consequently the repetition of some T-Values and derived M-Values. An example would be the delivery of defective or incorrect parts, which would cause the repeat of M4 and M5, or failure of FST Testing (M8), which would require the repeat of some portion of the repair cycle. A repair cycle that includes this type of recursion is represented in Figure 2, with the repair timeline path going back and forth, starting at M1 and eventually ending at M9. In this case the repair cycle would stay the same but repeat the necessary T-Values and derived M-Values and document them in the TSE Database.

Figure 2: Timeline Recursion - Repeated Maintenance Actions

Repair Activity Low-Level Metrics

CM M1 M2 M3 M4 M5 M6 M7 M8 M9

• The second form of recursion occurs when a repair starts as CM (repair in place) and is switched to DM because of the complexity of the needed repair. This is represented in Figure 3 with the repair timeline path starting in M1 and eventually ending in the DM row at M9 because the repair required depot maintenance. In this case the maintenance cycle would be changed to DM.

Figure 3: Timeline Recursion - CM Becomes DM

Repair Activity Low-Level Metrics

CM M1 M2 M3 M4 M5 M6 M7 M8 M9

DM M1 M2 M3 M11 M12 M8 M9

• The third form of recursion occurs when a repair starts as TCS and is switched to CM or

DM because of the complexity of the needed repair. In this situation, the TCS was attempted but failed, and therefore a FST must travel to the location to diagnose the failure. In this case, there would be no M13 (Telephone Customer Support Time) measured. The repair follows the standard Corrective Maintenance (CM)/Depot Maintenance (DM) repair cycle paths. These situations are represented by the TCS(1) and TCS (2) rows in Figure 4 with the repair timeline path starting with TCS repair but changing to CM or DM respectively.

Figure 4: Timeline Recursion - TCS Becomes CM or DM

Repair Activity Low-Level Metrics

TCS(1) M1 M9

CM M1 M2 M3 M4 M5 M6 M7 M8 M9

TCS(2) M1 M9

DM M1 M2 M3 M11 M12 M8 M9

• Another situation occurs when TCS is attempted and the FST determines which parts are needed for the repair during the phone conversation with the airport. This is when TCS fails but the Telephone Customer Support Diagnostic is accomplished. In this case, there would be no M13 (Telephone Customer Support Time) or M2 (Technician Dispatch Time) since the ticket was forwarded to the Technician who was able to assist with the diagnosis over the phone to order parts without being physically dispatched. T4:

Technician Diagnostics Complete is reported after T12: Start of Telephone Customer Support. The low-level metric created from T1: Call Center Contacted to T12: Start of Telephone Customer Support is M1: Initial Call Center Interaction time. The lower-level metric M3: Technician Diagnosis Time is from T12: Start of Phone Triage to T4:

Technician Diagnostics Complete. This type of maintenance activity with Telephone Customer Support Diagnostic results in no low-level metric of M2: Technician Dispatch Time. Then repair follows the standard CM/DM repair cycle paths. This situation is represented in Figure 5 with the recursion from TCS to CM with Telephone Customer Support Diagnostic.

Figure 5: Timeline Recursion - TCS Identifies Parts Needed

Repair Activity Low-Level Metrics

TCS M1 M9

CM M1

M3 M4 M5 M5 M7 M8 M9

• Another situation of Telephone Customer Support Diagnostic is when FST identifies that

DM is required for the failure. Then the low-level metrics are created from T12: Start of Telephone Customer Support to T4: Technician Diagnostics Complete is M3: Technician Diagnosis time. The next T-value is T11: TSE Ready for Setup at the Location for the DM and follows the DM activity path. This situation is represented in Figure 6 with the recursion from TCS to DM with Telephone Customer Support.

Figure 6: Timeline Recursion – TCS Becomes DM

Repair Activity Low-Level Metrics

TCS M1 M9

CM M1

M3 M11 M12 M8 M9

4.6.3 Time to Repair (M10) Development

As shown previously in Table 2 (Section 4.5), in a straight linear progression M10 consist of the sum of (from T3 to T4) and (from T7 to T9). If parts are not required there is no T7. Therefore, when parts are not required in a repair cycle, the maintenance repair action will be the sum of (from T3 to T4) and (from T4 to T9).

4.7 Low-Level Metrics Counting

TSA uses the low-level metrics previously defined to develop all performance metrics required to evaluate the performance of TSE and to evaluate Contractor maintenance support under TSA contracts. This requires consistency in the counting of the low-level metrics in the development of each type of high-level metric. This section describes the normal process TSA will use to develop the time and failure counts from a repair cycle. Any deviations from process will be identified in the specific high-level metric calculations or the individual TSA contract. The high-level RMA metrics and other high-level metrics that TSA calculates are defined in Section 5 of this document.

Note: Not all high-level metrics used for performance evaluations are defined in this document.

The Service Level Agreement document for each contract will specify what will be measure for each contract. Refer to individual contractor’s Service Level Agreement document to determine how each high-level metric is affected.

All high-level metrics will be calculated for the period and quantity of TSE specified by TSA, should include maintenance actions conducted during that reporting period, and should only include installed operational units in the calculations. The normal TSA reporting period is monthly through the last day of each calendar month unless identified otherwise in the TSA contract, and can be for an individual TSE unit, or grouped in accordance with the contract requirements.

4.7.1 Closed-Ticket Accounting

All high-level metrics will use a closed ticket accounting method except for Operational Availability (Ao) metrics, which are discussed in Section 4.7.2. For all counting other than Ao, if a ticket is open during two reporting periods, the entire downtime will be reported in period 2 and one failure counted in period 2. Figure 7 shows an example of a maintenance cycle that started in one reporting period and continued into another reporting period.

Figure 7: Closed-Ticket Reporting Period Determination

4.7.2 Open-Ticket Accounting

For Operational Availability (Ao) metrics only, the portion of the repair cycle time completed during a reporting period will be counted in the Ao metric calculations for that reporting period.

Using Figure 8 below as an example:

Figure 8: Open-Ticket Reporting Period Determination

• Times associated with M1, M2, M3, M4, and part of M5 that were conducted during reporting period 1 will be counted as downtime for metric calculations in reporting period 1.

• Times associated with M6, M7, M8, and the portion of M5 that were conducted during reporting period 2 will be counted as downtime for high-level metric calculation for reporting period 2.

• M9 will not be included in any high-level metric calculations since the TSE should be operational at T9 awaiting TSA acceptance/signoff.

Also, for Ao high-level metric development only, TSA considers a system’s downtime (when TSE is not in a condition to perform its required mission) during an airport’s operational hours, which will be provided in the TSA contract. Therefore, the counting of low-level metric times will be based on the TSE operating time and TSE operational downtime as defined below, unless specifically identified in the particular metric.

• TSE Operating Time – The period of time a system is available to perform its required mission during the operational hours of a facility. During the Operations & Maintenance (O&M) life cycle phase, TSE operating time will be equal to the airport’s operational hours (period of time within 24-hour day that an airport is operational) unless the TSE experiences any operational downtime.

• TSE Operational Downtime – The period of time during an airport’s operational hours that TSE is not in a condition to perform its required mission. This includes all times that a system is not available due to applicable onsite Corrective Maintenance (CM), Depot Maintenance, and Telephone Customer Support (TCS) Low-Level Metric times in Table 1 during the airport’s operational hours. The determination of the operational downtime is made after all low-level metrics are recorded against the 24-hour day and measured against the airport’s operational hours.

Low-level metrics times that accrue TSE downtime and occur within an airport’s operational hours will be counted in an operational downtime calculation; however, TSE downtime that occurs during an airport’s non-operational hours would not be counted in an operational downtime calculation. Figure 9 shows an example of a repair cycle that has operational downtime recorded from T1 for a critical CM maintenance activity that starts during an airport’s operational hours, does not require spare parts for the repair, and completes the repair after the airport’s operational hours. (Note that M7 in this example is from T4 to T8 since there is no parts replacement. See Section 4.6.1 for the explanation). The M-Value times will be counted as follows:

Figure 9: Operational Downtime Determination

• Times associated with M1, M2, M3, and M7, or portion thereof, were conducted during the airport’s operational hours, and will be counted as operational downtime.

• Time associated with M8 will not be included in the calculation of operational downtime for that maintenance activity since it was performed after the airport’s operational hours.

• Although M9 must be derived and recorded, M9 times will not be included in any high-level metric calculations since the TSE should be operational at T9 awaiting TSA acceptance.

• This corrective maintenance activity would generate one failure or occurrence for the metric calculations if there is operational downtime >0 for the failure.

If a repair cycle and M-Values were to continue into an airport’s next operational hours within the same reporting period, the operational downtime from both operational periods would be counted in the same operational downtime calculations.

M1 M2 M3 M7 M8 M9

Airport Operational Hours

Record in TSE Database

TSE Operational Downtime 1 Failure

T1 T2 T3 T8T1 T2 T3 T4 T9 T10

5. Operational RMA Metrics

TSA will use the RMA metrics identified in this section to evaluate the operational performance of TSE during its operational life cycle. No averaging will be used to calculate downtimes. The first day of the designated reporting period will always start at 12:00 AM and end at 11:59 PM on the last day of the reporting period.

Each TSE RMA metric identified in Sections 5.1 through 5.3 identifies the applicable low-level metrics to count in a particular failure type and repair cycle.

5.1 TSE Reliability Metrics

5.1.1 Mean Time Between Critical Failures

Mean Time Between Critical Failure (MTBCF) will evaluate the reliability of TSE in relation to all critical relevant failures. MTBCF is the average uptime TSE is available to perform its mission between critical relevant failures. MTBCF will be calculated for a single TSE or grouping of TSE in accordance with the contract RMA reporting requirements as follows:

1. Multiply daily uptime hours as defined in the contract by the number of TSE units in the TSE calculation population (one or more units) and the number of days in the reporting period;

2. Subtract the sum of the downtime associated with all critical relevant failures from the TSE calculation population (one or more units) during the reporting period;

3. Divide the difference by the total number of critical relevant failures.

MTBCF will be calculated for a specific reporting period (e.g., one month) and TSE combination (one or more units) based on the following formula:

One or more TSE units:

MTBCF =

(Uptime Hours x Number of TSE Units x Number of Days) – (Sum of TSE

Critical Relevant Downtime) Total Number of Critical Relevant Failures

Where:

• TSE Critical Relevant Downtime = Period of time during which a TSE is not in a condition to perform its mission due to a critical relevant failure.

• Uptime = defined as the period of time TSE is available to perform its required mission.

For the failure types listed in Table 4, the low-level metrics (M-Values) identified are counted toward the TSE downtime for MTBCF.

Table 4: MTBCF Low-Level Metrics Count Failure Type

Low-Level Metrics Level Criticality Relevancy

CM Critical Relevant M1 M2 M3 M4 M5 M6 M7 M8

DM Critical Relevant M1 M2 M3 M11 M12 M8

TCS Critical Relevant M1 M13

When a maintenance repair cycle continues into a new reporting period, the downtimes and failure count will be calculated in the new reporting period as defined in Section 4.7.

5.1.2 Mean Uptime

Mean Uptime (MUT) will evaluate the reliability of TSE in relation to all critical relevant and non-critical relevant failures. MUT is the average time TSE is available to perform its mission between all relevant failures (critical and non-critical). MUT is equivalent to Mean Time Between Failures (MTBF). MUT will be calculated for a single TSE or grouping of TSE in accordance with the RMA reporting requirements as follows:

1. Multiply daily uptime hours as defined in contract by the number of TSE units in the TSE calculation population (one or more units) and the number of days in the reporting period;

2. Subtract the sum of all downtime associated with all critical relevant and non-critical relevant failures from the TSE calculation population (one or more units) during the reporting period;

3. Divide the difference by the total number of critical relevant and non-critical relevant failures with downtime.

MUT will be calculated for a specific reporting period (e.g., one month) and TSE combination (one or more units) based on the following formula:

One or more TSE units:

MUT =

(Uptime Hours x Number of TSE Units x Number of Days) – (Sum of all TSE

Relevant Failures Downtime Total Number of Relevant Failures

Where:

• TSE Relevant Failure Downtime = The period of time during which TSE is not in a condition to perform its mission due to any relevant failure (critical and non-critical).

For the failure types listed in Table 5, the low-level metrics (M-Values) identified in the non-shaded blocks are counted toward the TSE downtime for MUT. Note that, by definition, non-critical failures do not have downtime in M1 through M6.

Table 5: MUT Low-Level Metrics Count Failure Type

Low-Level Metrics Level Criticality Relevancy

CM Critical Relevant M1 M2 M3 M4 M5 M6 M7 M8

DM Critical Relevant M1 M2 M3 M11 M12 M8

CM Non-Critical Relevant M1 M2 M3 M4 M5 M6 M7 M8

TCS Non-Critical Relevant M1 M13

5.2 TSE Maintainability Metrics

5.2.1 Mean Downtime

Mean Downtime (MDT) will evaluate the downtime of TSE in relation to all relevant failures.

MDT is the average TSE downtime associated with all relevant failures. MDT will be calculated for a single TSE or grouping of TSE in accordance with the RMA reporting requirements as follows:

1. Sum the TSE downtime associated with all relevant failures from the TSE calculation population (one or more units) during the reporting period;

2. Divide by the total number of relevant failures from the TSE calculation population (one or more units) during the reporting period.

MDT will be calculated for a specific reporting period (e.g., one month) and TSE combination (one or more units) based on the following formula:

One or more TSE units:

MDT = Sum of TSE Relevant Failures Downtime Total Number of Relevant Failures

Where:

• TSE Relevant Failure Downtime = The period of time during which TSE is not in a condition to perform its mission due to any relevant failure (critical and non-critical).

For the failure types listed in Table 6, the low-level metrics (M-Values) identified in the non-shaded blocks are counted toward the TSE downtime for MDT. Note that, by definition, non-critical failures do not have downtime in M1 through M6.

Table 6: MDT Low-Level Metrics Count Failure Type

Low-Level Metrics Level Criticality Relevancy

CM Critical Relevant M1 M2 M3 M4 M5 M6 M7 M8

DM Critical Relevant M1 M2 M3 M11 M12 M8

CM Non-Critical Relevant M1 M2 M3 M4 M5 M6 M7 M8

TCS Non-Critical Relevant M1 M13

5.2.2 Mean Time to Repair

Mean Time to Repair (MTTR) will evaluate the downtime required to diagnose and repair TSE due to all relevant failures. MTTR will be calculated for a single TSE or grouping of TSE in accordance with the RMA reporting requirements as follows:

1. Sum the TSE downtime associated with Time to Repair (M10) for all relevant failures from the TSE calculation population (one or more units) during the reporting period;

2. Divide by the total number of relevant failures from the TSE calculation population during the reporting period.

MTTR will be calculated for a specific reporting period (e.g., one month) and TSE combination (one or more units) based on the following formula:

One or more TSE units:

MTTR = Sum of TSE Relevant Corrective Maintenance Downtime (M3 + M7 + M8 = M10) Total Number of Relevant Failures

Where:

• TSE Relevant Corrective Maintenance Downtime = Duration of corrective maintenance actions associated with diagnosis, repair, and testing of TSE relevant failures.

For the failure types listed in Table 7, the low-level metrics (M-Values) identified in the non-shaded blocks are counted toward the TSE downtime for MTTR. When a maintenance repair cycle continues into a new reporting period, the downtimes and failure count will be calculated in the new reporting period as defined in Section 4.7.

Table 7: MTTR Low-Level Metrics Count Failure Type

Low-Level Metrics Level Criticality Relevancy

CM Critical Relevant M1 M2 M3 M4 M5 M6 M7 M8

CM Non-Critical Relevant M1 M2 M3 M4 M5 M6 M7 M8

Note that M11 (Depot Turn Around Time) and M13 (Telephone Customer Support Time) are not included in MTTR calculation. This is because MTTR measures the average on-site repair time.

Thus, no DM or TCS failures’ repairs will be included into the MTTR calculations.

5.3 TSE Availability Metrics

5.3.1 Operational Availability

Operational Availability (Ao) will evaluate the availability of TSE to perform its required mission during airport operational hours in relation to failures of any type. It is the percentage of time during an airport’s operational hours that TSE is available to perform its required mission during a specified reporting period. Ao will be calculated in accordance with the RMA reporting requirements as follows:

1. Multiply daily airport operational hours as defined in contract by the number of TSE units in the contract TSE calculation population (one or more units) and the number of days in the reporting period;

2. Subtract the sum of the operational downtime from all failure types within the TSE calculation population (one or more units) during the reporting period;

3. Divide the difference by the daily airport operational hours multiplied by the number of TSE units within the calculation population (one or more units) and the number of days in the reporting period.

Ao will be calculated for a specific reporting period (e.g., one month) and TSE combination (one or more units) based on the following formula:

One or more TSE units:

Ao =

(Airport Operational Hours x TSE Units x Number of Days) – (Sum of TSE all relevant critical (P1) and relevant non-critical (P2) failures Operational

Downtime) (Airport Operational Hours x TSE Units x Number of Days)

Where:

• Airport Operational Hours = Period of time within a 24-hour day that an airport is…