Exhibit B CMP.pdf

MOBILE SENSORS

CONFIGURATION

MANAGEMENT

PLAN

AFTAC/SYSTEMS DEVELOPMENT (SDBB)

25 NOV 2020

MOBILE SENSORS

CONFIGURATION

MANAGEMENT

PLAN

AFTAC/SYSTEMS DEVELOPMENT (SDBB)

25 NOV 2020

Document Approved By:

Timberlyn M. Harrington Tech Sensor PM Nuclear Materials Systems Air Force Technical Applications Center

1. Introduction

1.1. Purpose and Scope

2. Applicable Documents

3. Configuration Management Authority and Responsibility

4. Configuration Management Process

4.1. Initiate Change Requests

4.2. Evaluate Change Requests

4.3. Plan Project

4.4. CCB Change Request Approvals

4.5. Project Execution

4.5.1. O&M Contractor Interface

4.6. Test Readiness Review

4.6.1. Demonstrate Readiness to Deploy and Test Software

4.6.2. Software Version Description Document (SVDD)

4.6.3. Demonstrate Readiness to Deploy and Test Hardware

4.6.4. Information Assurance (IA)

4.7. Conduct Formal Testing

4.8. Close the Project and Accept Baseline Change

4.8.1. Configuration Audits

4.9. Emergency Version Release (EVR) Process

4.10. Emergency Hardware Change Process

5. Configuration Identification

5.1. Specifications

5.2. Engineering Data

5.3. Hardware Configuration Items (HWCIs)

Appendix A

5.4. Computer Software Configurations Items (CSCIs)

5.4.1. Utility Programs

5.4.2. System Adjustable Parameter (SAP) Files

5.4.3. Operating Patches

5.4.4. Engineering Tools

5.4.5. Operational Adjustable Files

6. Baseline Change Records

Appendix A: Configuration Items for USNS INVINCIBLE

Appendix B: Configuration Items for USNS HOWARD O. LORENZEN

Appendix C: Configuration Change Request

Appendix D: Definitions

Appendix E: Acronyms and Abbreviations

Figure 1: Configuration Management Process

1. Introduction Mobile Sensors (MS) is comprised of the RADAR and support equipment aboard the United States Naval Ship (USNS) INVINCIBLE and RADAR and support equipment aboard the USNS HOWARD O. LORENZEN. This Configuration Management (CM) plan establishes configuration control procedures for system software (SW) and hardware (HW) changes that affect MS Mission Equipment and MS Mission Support Equipment. CM control also extends to the MS RADAR simulator equipment which exists at stateside facilities such as Patrick Air Force Base (PAFB), FL and Wright Patterson AFB (WPAFB), OH.

1.1. Purpose and Scope

The purpose of CM is to maintain the integrity of the MS RADAR, communication and support systems, to control changes to the baselined requirements, design, SW, testing, and documentation, and to make these technical artifacts available to concerned parties upon Government release. The plan assigns responsibility and authority for performing the CM tasks, and indicates the steps to follow on the Air Force Technical Applications Center (AFTAC) MS program to:

1. Identify and document configuration controlled items

2. Control changes to the physical or functional characteristics of controlled items

3. Record and report change processing and implementation status

This plan is effective upon signature and supersedes previous plans.

2. Applicable Documents The following list of regulations, manuals, standards, and reference documents are used in support of the CM effort of the Mobile Sensors:

a) Performance Work Statement (PWS) for the Operations and Maintenance (O&M) of Mobile Sensors, June 2020

b) Military Handbook MIL-HDBK-61A, Configuration Management Guidance, 07 Feb 2001

c) Technical Order 00-35D-54, USAF Deficiency Reporting, Investigation, and Resolution. Air

Force Materiel Command, 1 Sept 2015

d) Air Force Instruction 33-114, Communications and Information-Software Management, 13

May 2004

e) Mobile Sensors Operating Procedures (MSOP) 00-01, April 2017

f) RADAR Ops User Guide (Details Deficiency Report format and website use) 27 Aug 2018

g) Transportation Alteration Process (See section 4.2 for details)

3. Configuration Management Authority and Responsibility CM is the responsibility of all MS contractors and Government organizations. Specific authority and responsibilities are outlined below.

Mobile Sensors Management Office (MSMO) is the prime contractor to AFTAC responsible for the O&M of the Mobile Sensors. The MSMO is responsible for maintaining the operational baseline, which consists of all the technical artifacts associated with MS Mission Equipment and Mission Support Equipment SW and HW.

Mobile Sensors Program Office (MSPO) is under the direction of AFTAC/Systems Development (SDBB) and responsible for program management of the Mobile Sensors’ radars. The Mobile Sensors System Managers (MSSM) are the Government representatives within the MSPO responsible for day-to-day management of the MS. There is typically one MSSM for each operating platform. One Mobile Sensors Program Engineer (MSPE) supports HW and SW engineering for all MS systems.

Configuration Control Board (CCB) is comprised of the following members: MSPE (Chair) and MSSM’s, an AFTAC MS Operations representative (usually a Mission Commander (MC)), mission partners and technical representatives, and others as determined by the CCB and approved by the CCB Chair. The CCB authorizes work on proposed baseline changes, approves recommended SW builds, project milestones, costs and implementation schedules, and validates that CM processes are completed before each project is closed out. Changes to the milestones, schedule extensions, or cost overruns may be approved by the MSPO. The CCB gives final approval of baseline changes to any HW or SW changes to the mission equipment or mission support equipment. If a recommended change has potential to interfere with another mission, the CCB is responsible for notifying the appropriate mission representative and coordinating approvals as needed, or rejecting the configuration change.

Configuration Control Working Group (CCWG) is an action officer (AO)-level body led by the MSMO, and comprised of relevant technical and mission representatives. Government attendance is optional. The CCWG discusses each change request, and recommends disposition (implement, defer, reject), as well as the priority of the request. In addition, the CCWG may suggest implementation actions or specific technical concerns for the developer to consider. The CCWG recommends the content for each SW release.

Concerned Parties are any user, technical advisor or stakeholder.

4. Configuration Management Process The CM Process outlines the steps for identifying, documenting, implementing, and maintaining changes to all MS Configuration Items. The process in Figure 1 indicates how changes are requested, prioritized, approved for development, tested, and accepted.

4.1. Initiate Change Requests

Any user or stakeholder may propose configuration changes or new requirements by submitting a Configuration Change Request (CCR), or a Deficiency Report (DR). Other requests for requirements not directly related to mission shall be coordinated through AFTAC/XPZ for approval. A detailed description of the problem, and a preliminary assessment of criticality of the problem, and risks are required. A proposed solution is optional. DR’s will be tracked on a classified website by the MSPO, while CCRs are recorded by the MSMO. Reference the RADAR Ops Users Guide for a DR template and details, and Appendix C for the current CCR template.

CC

B

(M

SP

E Ch ai r)

M

SM

O o r C on tr ac to r

M

SM

O C

M

CC

W G

(M

SM

O C ha ir)

Configuration Management Process (Hardware and Software)

4.1 Initiate DR/CCR

• ID Problem

• ID Priority

• ID Risk

• Propose Solution

(Optional)

4.4 CCB

Proceed to

Development?

4.5 Execute project

• Present Milestone reviews to MSPO

• CONUS Testing

• Update documentation

• Develop TRR package

Update Baseline Log CCR and update status in Data Base

4.3 Plan project

• Scope / SW build

• Schedule

• Milestones

• Documentation

• Cost

4.7 Conduct formal test

• Install / Integrate

• Conduct Site Testing

• Conduct TP

• Finalize test report

• Report deficiencies

4.8 Close Project

• Physical Audit

• Adjudicate Action

Items

• Finalize

Documentation

4.2 Evaluate change requests

• Recommend priorities

• Recommend SW build

• Recommend projects for implementation

• Recommend 3-5 year roadmap for deferred projects (Optional)

4.6 TRR

Ready for Install

& Site Test?

4.7 DRB

Deficiencies mitigated?

4.8 CCB

Baseline change approved?

No

YesYes

Yes

Yes

No No No

Figure 1: Configuration Management Process

4.2. Evaluate Change Requests

The CCWG will meet as needed via telecom or in person, or more often as required to evaluate, prioritize, and recommend disposition of new and deferred change requests. The MSMO will send out meeting notices prior to each meeting, and will chair the meeting. Mission and technical representatives are encouraged to participate and provide clarification of problem reports they have submitted. This forum provides all mission representatives the opportunity to offer technical solutions and support.

The CCWG recommends acceptance or rejection of each new change request. A recommendation to reject a change may be due to an ill-defined problem, implementation concerns, or the potential for undesirable secondary effects. If a recommended change has potential to interfere with another mission but is still recommended, the change request will be annotated for CCB coordination with the appropriate mission representative.

For all new and deferred change requests, the CCWG will recommend immediate or deferred implementation, and recommend a priority for approval by the CCB. The CCWG relies on MSMO and technical representative input. Change proposal categories are based on the USAF Deficiency Reporting, Investigation and Resolution documentation (T.O. 00-35D-54), and are described below.

Priority refers to the impact to the mission and to safety, but does not imply the order in which changes are to be addressed. Lower priority changes may be addressed before higher priorities due to time, cost or risk considerations.

Priority 1/ HIGH: If uncorrected, the problem may cause personal injury/death, a major loss of mission data, damage to mission equipment, or significant decrease in technical performance.

The problem prevents the accomplishment of critical mission requirements and/or mission essential functions, as determined by the CCB. A work around is either not known or if one exists is considered unacceptable to the CCB.

Priority 2/MEDIUM: If uncorrected, adversely effects mission essential capabilities, or ability to maintain the equipment. A work around is either not known or if one exists it is not acceptable to the CCB. Or, any deficiency deemed by the CCB as “Priority 1/HIGH”, but a temporary and acceptable work around exists.

Priority 3/LOW: If uncorrected, adversely effects mission capability or maintenance but a work-around, acceptable to the CCB, is known. Or, it causes a minor reduction in technical performance or supportability, but can be tolerated with little or no impact on mission accomplishment. A work around may or may not, exist.

Priority 4/ROUTINE: Does not affect mission essential capability, but causes user/operator inconvenience.

The CCWG may provide inputs or advice on sequencing deferred projects, for inclusion on a long term project roadmap.

The CCWG will recommend DR content for upcoming SW builds, and may offer specific technical advice or guidance for developing or testing specific DR’s. For example, the CCWG may recommend risk reduction measures such as the development of incremental SW Engineering Builds for cases where continental United States (CONUS) based testing will be inadequate.

For HW or other system changes, the CCWG may recommend specific project milestones for tracking development of a solution, or the use of phases for very large efforts. The developmental effort will be planned by the developer (see Section 4.3), and project milestones are tailorable. The proposed project may be tracked using formal engineering milestones (SRR, PDR, CDR, TRR, DT&E, OT&E), or may be very streamlined for less complex tasks.

Another consideration for the CCWG is the possible requirement for a Transportation Alteration (TRANSALT). The TRANSALT process is outside the scope of this CM plan but must be considered and accounted for in regards to any HW change that does not involve a one to one replacement of an identical HW unit. The TRANSALT approval process is run and coordinated by the Military Sealift Command (MSC) and outside the control of the CCWG or CCB. Consideration of the TRANSALT process and requirements must be done for any HW changes as this process can take up to a year or more. Coordination with the MSC lifecycle engineer and the MSPE is needed to ensure HW changes are documented and provided for the TRANSALT process. Lack of TRANSALT approval for a HW change will stop any support or approval from MSC to conduct the work on any MS platform.

TRANSALT status is documented on the CCR form.

Once the CCWG review is complete, the MSMO will generate and distribute minutes of the meeting to all attendees.

4.3. Plan Project

The developer will define the project at a high level, proposing cost, a project schedule, proposed milestones, a timeframe for conducting Developmental Test and Evaluation (DT&E) on the ship, and required documentation. Note that DT&E may be tied to a planned Maintenance Repair Availability (MRA) or Regular Overhaul (ROH) rather than to a specific date. For SW, the project is typically planned around developing a SW build with defined content. For all projects, the developer will propose appropriate milestones for tracking execution of the project. Complex modifications or those requiring wide coordination may benefit from more frequent milestones, with separate reviews for requirements, preliminary design, critical design, etc. The developer may recommend a significantly streamlined process with little outside tracking or review for less complex projects.

A Test Readiness Review (TRR) is milestone that will typically be required for all projects. The purpose of the TRR is to for the Government to approve the readiness to implement and test the modification of the baseline configuration on the mission or mission support equipment. The format of the TRR is tailorable, and may be as complex or as simple as the project requires. Multiple projects may be encompassed in a single TRR, which would be expected prior to an MRA or ROH. The TRR must be approved by CCB prior to implementing the configuration change on the ship. Note that maintenance activities that do not change the configuration baseline and are not part of this process.

4.4. CCB Change Request Approvals

The CCB meets every six months or as needed via telecom or in person. The CCB will approve or disapprove CCWG recommendations to accept or reject change requests. The CCB will approve SW build content. The CCB will review the estimated costs, schedule, and milestones presented by the developer for new projects, and will approve or disapprove the initiation of each project.

Supporting materials will be distributed to the CCB Chair and the CCB members by the MSMO no later than five duty days prior to the CCB. The CCB forum provides all mission representatives the opportunity to offer final inputs and vote on proposed builds, changes, and enhancements. The MSMO will serve as advisor to the Government during the CCB, will record and distribute minutes of the meeting.

4.5. Project Execution

The HW or SW developer will execute the project, and update the MSPO on progress in accordance with the milestones approved when initiating the project. The MSPO has the authority to approve the completion of major milestones such as Preliminary Design Review (PDR) and Critical Design Review (CDR). At a minimum, mission partners will be appraised of progress at the TRR, and upon CCB approval to close the project.

4.5.1. O&M Contractor Interface

The MSPO has responsibility to ensure compatibility of proposed fixes or modifications to MS that may be accomplished by other project contractors employed by the US Government. MSMO will assist MSPO in the determination of any compatibility issues. The MSPO will typically be included in project milestone reviews and provide assessments of the proposed change to the MSPO to ensure:

a) There will be no impact to mission requirements,

b) The change will not induce prolonged or unnecessary system downtime.

c) The change is compatible with existing interfacing HW or SW

4.6. Test Readiness Review

A TRR will be held no later than 30 days prior to deployment of a SW build or a HW modification.

The developer will demonstrate readiness to implement the baseline change at site and to conduct formal test. The MSPE will chair the meeting. Materials will be presented by the development team.

4.6.1. Demonstrate Readiness to Deploy and Test Software

The MSPE is responsible for ensuring SW change milestones are complete, or captured as action items, that the SW has been adequately prepared, with successful code reviews, successful regression and progression testing, and satisfactory documentation via the SW Version Description Document (SVDD) to address DR’s and CCRs. The SVDD includes the rationale for all implemented changes, documentation updates and test results. The MSPE also ensures that DT&E plans for ship-based testing are sufficient to test all affected Computer SW Configuration Items (CSCIs). The MSPE and MSSM are responsible for validating the expected impact of the build on the multi-mission functionality of the Mobile Sensors, and communicating this with technical and mission representatives.

4.6.2. Software Version Description Document (SVDD)

An SVDD for a SW Version Release is prepared by the developer, and will include the following:

• Suggested SW Version release number if applicable

• Description of each DR in the build, including o Detailed description of the problem and how it could be reproduced (if applicable) o List of missions used to help diagnose the issue o Detailed description of the SW modification to correct the deficiency o CSCIs affected by the modification o List of interface changes resulting from the modification o List of Logical Record Identifier (LRID) modifications resulting from the modification o List of related documents updated for this modification

Detailed code comments for all operational SW Updates to training documentation needed for maintainers or operators

• Test Procedures and test Methodology (Inspections, Analysis, Demonstration, and/or test) developed for each DR, including the identification of the standard suite of regression tests used for the build. The test procedure should list the steps performed by the operator, pertinent details about the scenario and mission profile, the analysis script that was executed (if applicable), and details about the pass/fail criteria.

4.6.3. Demonstrate Readiness to Deploy and Test Hardware

A TRR will be held no later than 30 days prior to deployment to the ship. The MSPE will chair the review meetings. Materials will be presented by the development team.

The MSPE is responsible for ensuring system and/or HW change milestones are complete, or captured as action items, that the baseline modification requirements have been reviewed, successfully unit and factory tested, and the change satisfactorily documented via drawings, manuals, and technical documentation to address the CCR. The MSPE must also ensure that DT&E plans for ship-based testing are sufficient to test all affected requirements for HW Configuration Items (HWCIs) and CSCIs. The MSPE and MSSM are responsible for validating the expected impact of the build on the multi-mission functionality of the Mobile Sensors, and communicating this with technical and mission representatives.

4.6.4. Information Assurance (IA)

Any change made to commercial or potentially IA controlled SW or HW, such as the operating system (OS) or servers, used by the MS RADAR systems may require AFTAC IA approval. In these cases, the MSPE will work with the AFTAC IA Manager (IAM) to determine if any further documentation or approvals are needed. A System Security Authorization Agreement (SSAA) exists for each MS RADAR controller system and may require MSMO updates and approval by AFTAC IAM.

4.7. Conduct Formal Testing

The O&M contractor or developer will conduct formal DT&E activities to verify the SW or HW changes, witnessed by the Government or its representative, the Technical Sensor RADAR Support (TSRS) contractor. DT&E testing includes the necessary progression test cases to verify SW changes work as intended, as well as regression tests to verify legacy performance is not compromised.

Regression testing will be performed for every SW version and/or engineering release, regardless of whether or not the release includes SW functional changes. HW testing will validate existing or updated requirements. Test results will be documented in a Test Report, showing that the deficiency has been resolved. During formal testing, all deficiencies will be documented as an action item (AI) or a Deficiency Report (DR), and may only be closed at a DR Board (DRB).

At the successful completion of DT&E, and upon acceptance of full regression test analysis showing pass/fail criteria by the MSPE or MSMO, a 30-day operational Trial Period (TP) will begin. The MS MC will provide written confirmation to the MSPO of the beginning of TP in the Daily Status Report (DSR), and the MSPO will notify mission partners of the start of TP. If at any point during TP, the modification is believed to cause an undesired side effect or cause mission interference, the change will be rolled back until the problem is suitably resolved. Observed problems will be formally documented as a DR.

After the TP, test results are presented to the CCB at a DRB along with recommended disposition of all DR’s. The CCB has the authority to stop the configuration change, ask the developers to resolve the deficiency and re-test, or to log the new DR into the DR database.

4.8. Close the Project and Accept Baseline Change

4.8.1. Configuration Audits

Before requesting the CCB close a project, a Physical Configuration Audit (PCA) will be conducted by the MSPO or an appointed representative. Delivered SW source code will be checked in, and executable copies of the previous and latest version of the SW will be kept on the ship via electronic storage media. The audit will check SW disk files, verify physical inventories of program HW, and validate a complete documentation package as indicated in the project initiation.

To close the project, the project owner will demonstrate to the CCB that all documentation updates are complete, and action items adjudicated. After the MSMO resolves any outstanding issues, the MSMO will request the CCB approve the baseline configuration change, authorizing the new baseline for continuous mission operation. The MSPE and MSSM will sign the CCR and/or close the DR. The CCB chair will communicate the change to all stakeholders, and the MSMO will update the baseline.

4.9. Emergency Version Release (EVR) Process

Special provisions, if needed, are available to accommodate urgently needed updates using the EVR process. The EVR process should be reserved for baseline changes affecting mission critical performance or safety. Mission impact or safety concerns must be substantiated. The MSPO approves deployment of an EVR, after either the MC or the MSMO Site Operations Manager (SOM) certifies the change is ready for implementation. After the EVR is deployed, all steps of the SW development process will be followed to ensure the change is documented and tested. The configuration baseline change will only be approved when all steps in the process are complete.

4.10. Emergency Hardware Change Process

Special provisions, if needed, are available to accommodate urgently needed HW updates using an emergency process. The emergency HW change process should be reserved for baseline changes affecting mission critical performance or safety. Mission impact or safety concerns must be substantiated. The MSPO approves use of the emergency HW change process, after either the MC or the MSMO SOM officially states the change is ready for implementation. After an emergency HW change is implemented, all steps of the HW development process will be followed to ensure the change is documented and tested. The configuration baseline change will only be approved when all steps in the process are complete.

5. Configuration Identification Configuration identification is based on approved technical documentation that defines the functional characteristics of the MS Mission Equipment, communication and support systems, subsystems, or items.

5.1. Specifications

The A-Spec defines the System Requirements and the framework for the functional Baseline. Various B-level System/subsystem Specifications, Interface Requirement Specifications, Interface Design Description and SW Requirements Specifications define the requirements applied to Configuration Items.

5.2. Engineering Data

Engineering data with assigned numbers are controlled. These include, but are not limited to drawings, specifications, plans, and SW deliverables. Revisions will be identified. At a minimum, marking will include a document number, a revision letter, a page number, classification, and date. Engineering drawings will show part number, Manufacturer’s Code Identification, Serial Number (as applicable), and functional markings and part orientation as required.

5.3. Hardware Configuration Items (HWCIs)

Appendix A lists applicable HWCIs for USNS INVINCIBLE, and USNS HOWARD O. LORENZEN HWCIs are listed in Appendix B. In general, all RADAR, RADAR support, and communication systems are under CM control.

5.4. Computer Software Configurations Items (CSCIs)

CSCIs for the MS equipment are typically associated with specific subsystems or SW functions.

Appendix A lists applicable CSCIs for USNS INVINCIBLE, and USNS HOWARD O. LORENZEN CSCIs are listed in Appendix B. In general, all SW and firmware that resides on MS mission equipment, communications, and support equipment falls under configuration control except for Operational Adjustable Files.

5.4.1. Utility Programs

Utility programs are separate programs (Sierra, TMW, PNM GUI, and other engineering tools that support operations and diagnostics) which are used to run in the background on the secondary mission computers (SMC) to automate repetitive tasks and to assist with data reduction batch processes, mission planning, post-mission data analysis, and data dissemination to the users. These are under CM control and must go through the CM process for updates.

5.4.2. System Adjustable Parameter (SAP) Files

Some System Adjustable Parameters (SAPs) are rarely changed, while others require frequent adjustments. A change in specific SAPs could have a major impact on mission performance. A list of which SAPs that should be under CM control, and which should be permitted to be changed has not been vetted in the community. Therefore, the developer or site should check with the MSPE for direction on whether each particular SAP is under CM control until a formal delineation is made. If CM is determined, then a DR should be submitted requesting SAP changes, and modifications must go through the CM process for updates when directed by the MSPE.

5.4.3. Operating Patches

Operating patches require configuration baseline control approval, and often require IA updates as well. Patch updates should follow the CM process flow for starting, monitoring and finalizing the change.

5.4.4. Engineering Tools

Some Engineering Tools are regularly used to perform operations, while others are used for specific or limited troubleshooting or testing. Some Engineering Tools could have a major impact on mission performance. A list of which Engineering Tools that should be under CM control, and which should be permitted to be changed has not been vetted in the community. Therefore, the developer or site should check with the MSPE for direction on whether each particular tool is under CM control until a formal delineation is made. If CM is determined, then a DR should be submitted requesting SAP changes, and modifications must go through the CM process for updates when directed by the MSPE.

5.4.5. Operational Adjustable Files

There are several categories of SW and input data files that do not fall under the configuration control procedures described by this plan. These files must be maintained and updated on the ship by the O&M contractor to support daily operations and in response to changing collection objectives of the different system user communities. The ship must support last minute changes in technical direction for a given mission. The SW and data items that may need to be changed on the ship to support operations include: (1) search volumes or parameters: (2) mission profiles (USNS HOWARD O.

LORENZEN)/mission decks (USNS INVINCIBLE); (3) RADAR calibration and replica files; (4) satellite database rebuild configuration files; (5) specifically identified SAP files, and (6) specifically identified Engineering Tools.

5.4.5.1. Search Volume Definition Files

Search fence definition files are stored in the fence directory and must be modified, sometimes with little advanced notification, in accordance with current mission data collection objectives and defensive requirements. It is sometimes necessary to adjust the fence positions to mitigate the effects of clutter, or search returns from meteor showers. Such changes need not be reported by CCR or Equipment Status Report (ESR).

5.4.5.2. Mission Profiles/Mission Decks

Mission profiles and Mission decks are stored in the profile directory and must occasionally be updated. These updates are sometimes needed with little advanced notification based on current user requirements and collection opportunities. All profiles are subject to change at the request or action of WPAFB or MIT/LL.

5.4.5.3. RADAR Calibration Files

RADAR calibration files store system calibration constants that are read by the mission SW and updated manually or automatically as needed. Such files include the current ship position coordinates, array orientation, RADAR cross section (RCS) corrections for narrowband and wideband waveforms, and other calibration specific parameters. Many calibration constants are updated automatically in the course of completing daily satellite calibration passes. However, some files require infrequent manual updates such as wideband RCS corrections, ship position, and array orientation. Replica files are a type of calibration file that is infrequently updated, should be stored, but is not under configuration baseline control.

5.4.5.4. Satellite Database Rebuild Configuration Files

It is standard operating procedure on USNS INVINCIBLE to update the Satellite Database with Two- Line Element Sets (TLE) received via SIPRNET. The TLEs are transferred into the RADAR Open Systems Architecture (ROSA) Calibration Workstation (COW). When the rebuild process is commanded, a satellite configuration file is edited with current ship’s position. See GSM-24 for more details on this process. This process is done almost daily when underway and does not require CM control.

5.4.5.5. System Adjustable Parameter (SAP) Files

Like calibration files, many SAP’s change frequently, and others are rarely changed. After the developer or site receives permission from the MSPE that a particular SAP does not need CM control, the site may make a change. The MSPE will periodically update a published list of configurable and non-configurable SAP settings to add clarity. All SAP changes should be documented and stored, whether or not they are under Configuration Baseline control.

6. Baseline Change Records The following records are tracked/maintained by the MSMO in association with this CM plan:

a) A CCR Folder or Database (includes a complete volume of open and closed CCRs)

b) CCWG Meeting Minutes with recommendations

c) CCB minutes

d) TP and Version Acceptance letters (may be formal letters or email messages)

e) CCR-ESR cross reference Equipment Status Request database

f) A cross reference of CCRs and ESRs

g) SVDD’s and HDDs for all baseline changes

h) Test reports

The contractor will provide MSPO access to the records database as requested.

Appendix A: Configuration Items for USNS INVINCIBLE

HWCI

• S/X-Band RADAR Antenna

• S-Band Transmitter

• X-Band Transmitter

• S/X-Band Receivers

• Back-End Processing Equipment

• Data Processing Systems

• Digital Simulation String @PAFB

• Digital Simulation String @WPAFB

• External Mission Communications

• Marine Systems

CSCI

• Real-Time Program (RTP)

• Subsystem Real-Time Program (SRTP) o Master Timing System (MTS) SW o Digital Sampling System (DSS) SW o Antenna Control System (ACS) SW

• Calibration and Diagnostic SW o ROSA COW

• Operator Graphical User Interface SW

• Playback SW

• GRAY STAR Catalog Recording System (GSCRS)

• Transmitter Control and Monitor Program (TCMP)

Appendix B: Configuration Items for USNS HOWARD O. LORENZEN

HWCI

• CBE Communications Subsystem

• CBE Weather Equipment

• CBE Processing Equipment (PE)

• SFE Antenna

• SFE Power System

• SFE Receiver/Exciter

• SFE Pedestal

• SFE Cooling System

• XFE Antenna

• XFE Power Distribution System (PDS)

• XFE Power Supply Assembly (PSA)

• XFE Beam Steering Controller (BSC)

• XFE Receiver/Exciter

• XFE Pedestal

• XFE Cooling Equipment Unit (CEU)

• Mission SW Support System (MSSS) @ PAFB

• Mission SW Support System (MSSS) @ WPAFB

• Mission Communications Suite (MCS)

• Marine Systems

CSCI

• Mission Applications Program (MAP)

• Signal Processing SW (SPS)

• Display and Control Processing (DCP)

• RADAR Simulation SW (RSS)

• Operating System Augmentation (OSA)

• Pre/Post Mission Processing SW (PPS)

• External Communications Processing (XCP)

• RADAR Test Control Program (RTCP)

• SFE Antenna SW

• SFE Power System SW

• SFE Receiver/Exciter SW

• XFE Beam Steering Controller SW

• XFE Receiver/Exciter SW

Appendix C: Configuration Change Request

Mobile Sensors Configuration Change Request

1. Title 2. Originator: 3. Date: 4. Control No:

5. System or Mission Support:

6. Requirement

7. Justification

8. Systems Affected:

9. Technical Disposition & Approach (Attachment A):

10. TRANSALT

CCR Check List Yes No Attachment Close-out Date

11. Documentation � � B, J

12. Spare Parts � � C

13. Purchased Materials & Services � � D

14. Test Equipment � � E

15. O&M Procedures � � F

16. Training � � G

17. Tempest Requirements � � H

18. System Security Authorization

Agreement � � I

19. Verification Test Method: Test: Inspection: Analysis:

20. Required Completion Date

21. Responsible Person:

22. Approvals

CCB Approval to initiate project:

MSPO Program Engineer:

Date:

MSPO System Manager: Date:

MSMO Configuration Control Engineer:

Date:

CCB Approval to Accept the baseline change

MSPO Program Engineer:

MSPO System Manager: Date:

23. Configuration Change Close-Out:

MSMO Configuration Control

Engineer:

Figure 2: Mobile Sensors Management Configuration Change Request (CCR) Form

Appendix D: Definitions Frequently referenced terms are defined below.

a) Configuration Change Request (CCR): The primary tracking record used for processing proposed modifications, fixes, and documentation updates to SW and HW. Attachments may be provided to supplement technical details or conditions under which the problems were originally encountered or found to re-occur. CCR’s are recorded and updated by the MSMO. A CCR can reference one or more DR’s and ESR’s.

b) Configuration Management (CM): Technical and administrative process for identifying, documenting, implementing, and maintaining changes to configuration items of a defined system.

c) Deficiency Report (DR): A DR refers to a noted deficiency to the normal operational baseline of the MS. A DR can be either in SW or HW, but most are SW related. A DR can later be qualified as an enhancement if the issue is determined to not be part of the original system capability. DR’s can be proposed by the MSPO, MSMO, technical representatives or mission partners and are approved/disapproved by the CMB. The MSPE is responsible for co-ordination of status and updates of all MS DR’s. Currently all MS DR’s are stored on a central classified website, located on SIPR, which is maintained by the MSPO.

d) Developmental Test and Evaluation (DT&E): Developmental test and evaluation is conducted both on-ship and off-ship, as required, to demonstrate that the proposed change or design is complete, performs as intended, and meets system performance specifications. DT&E will normally consist of progression tests that are specifically devised to verify correct functionality of introduced changes, and regression tests that verify properly retained functionality of pre-existing capabilities. DT&E is to be conducted as much as possible on non-mission equipment, such as off-ship test string or simulator, before any testing on mission equipment.

e) Hardware Design Description (HDD): A HW modification approved for testing by the CCB must have a HDD. The HDD is usually produced by the developer or the MSMO.

f) Mission Representatives: Mission partners of the Mobile Sensors RADARs.

g) Progression Testing: Testing of new SW functional changes (Deficiency Reports, DR) or enhancements to SW builds which require additional testing and implementation other than what the current regression suite allows. Upon successful integration of additional SW functional changes, progression test scenarios will be implemented into the current regression test suite.

h) Regression Testing: SW testing that uncovers potential issues with SW functionality or system performance, in existing, legacy functional and non-functional areas of a SW build release after enhancements, patches or configuration changes have been made.

i) Software Version Description Document (SVDD): A SW change approved for testing by the CCB must have an SVDD. The SVDD is usually produced by the developer of the SW and provides the proposed build name or number, the reason for the SW change, details of the exact code being changed, and a test plan to include regression testing. An SVDD may reference DR’s, ESR’s and CCR’s. The final SW build name or number will be determined by the CCB.

j) Technical Representatives: Representatives of the MS O&M contractor (MSMO), mission partners, and technical support groups such as MIT/LL, Riverside Research (RR) and any applicable SW developer sub-contractors.

k) Trial Period (TP): Also called "Soak Period", lasting at least 30 days, in which new system HW and SW are placed under normal day-to-day operations prior to final acceptance of SW and HW changes. The trial period is also needed for changes to a system specifically covered by an IA plan. This would include system OS or server HW that has specific IA compliance.

Appendix E: Acronyms and Abbreviations

ACS Antenna Control System AFTAC Air Force Technical Applications Center AO Action Officer CCB Configuration Control Board CM Configuration Management CMB Configuration Management Board CCR Configuration Change Request CCWG Configuration Control Working Group CSCI Computer Software Configuration Item CUDIXS Common User Digital Information Exchange System DAMA Demand Assigned Multiple Access DLT Digital Linear Tape DR Deficiency Report DRB DR Review Board DT&E Developmental Test and Evaluation ESR Equipment Status Report EVR Emergency Version Release HVAC Heating, Ventilation, and Air-Conditioning HW Hardware HWCI Hardware Configuration Item LOS Line of Sight MC Mission Commander MIT/LL Massachusetts Institute of Technology/Lincoln Laboratory MRA Maintenance Repair Availability MS Mobile Sensors MSC Military Sealift Command MSOP Mobile Sensors Operating Procedures MSPE Mobile Sensors Program Engineer MSPO Mobile Sensors Program Office MSSM Mobile Sensors System Manager MTSS Master Timing System S-Band MTSX Master Timing System X-Band O&M Operations and Maintenance OSA Operating System Augmentation OT&E Operational Test and Evaluation PAFB Patrick Air Force Base PCA Physical Configuration Audit RCS RADAR Cross Section RIC RADAR Instrumentation Center ROH Regular Overhaul RR Riverside Research SMC Secondary Mission Computer SSR Solid State Satellite Receiver SVDD Software Version Description Document SW Software TCC Transmitter Control Center TP Trial Period TRANSALT Transportation Alteration TSRS Technical Sensor RADAR Support USNS United States Naval Ship UPS Uninterruptible Power Supply

WPAFB Wright Patterson AFB