statement of work for: feed optics control system revision ... · page 2 of 14 document: sow for...

Operated by the Association of Universities for Research in Astronomy, Inc. under a cooperative agreement to the National Science Foundation

950 N. Cherry Avenue, Tucson, Arizona 85719

Telephone: (520) 318-8108

Fax: (520) 318-8500

[email protected] http://dkist.nso.edu/

Statement of Work for: Feed Optics Control System

Revision: B

Issue Date: March 17, 2016

Name Date

Released By : J. McMullin

Project Manager 04-April-2016

Page i

Document: SOW for FOCS

Revision: B

Date: Apr 4, 2016

Change Record:

Revision Date Section(s)

Affected Description of Change

A 18 Nov 2015 All Created

B 4 Mar 2016 3.1, 3.5, 5.2 Added kickoff workshop, limited

responsibility to software performance only.

of 14


Revision: B

Date: Apr 4, 2016

Table of Contents 1. Scope & Overview of Deliverables .............................................................................. 2

1.1 Scope ........................................................................................................................................................... 2 1.2 Definitions ................................................................................................................................................ 2 1.3 Contractor Responsibilities ............................................................................................................... 3 1.4 Project Phases & Major Deliverables ............................................................................................ 3

2. Project Organization & Control ................................................................................... 4 2.1 Key Personnel ......................................................................................................................................... 4 2.2 Documentation of Changes and Communication ..................................................................... 4 2.3 Progress Reports ................................................................................................................................... 5 2.4 Meetings .................................................................................................................................................... 5 2.5 Access to Work and Information .................................................................................................... 5 2.6 Accommodation and Services for AURA Personnel ................................................................ 5 2.7 Delays ......................................................................................................................................................... 6

3. Phase 1: Critical Design Development ...................................................................... 7 3.1 Kick-Off Meeting .................................................................................................................................... 7 3.2 Project Plan .............................................................................................................................................. 7 3.3 Software Design Development......................................................................................................... 7 3.4 Software Interface Development .................................................................................................... 8 3.5 Hardware Interface Development .................................................................................................. 8 3.6 Software Development ........................................................................................................................ 8 3.7 Software Design Review ..................................................................................................................... 8 3.8 Phase 1 Close Out .................................................................................................................................. 9

4. Phase 2: Software Development ............................................................................... 11 4.1 Control Software ................................................................................................................................. 11 4.2 User Interface ....................................................................................................................................... 11 4.3 Simulator ............................................................................................................................................... 11 4.4 Factory Acceptance Test Plan ....................................................................................................... 11 4.5 Phase 2 Close Out ............................................................................................................................... 12

5. Phase 3: Factory Integration and Acceptance ..................................................... 13 5.1 Factory Integration ............................................................................................................................ 13 5.2 Factory Acceptance Test.................................................................................................................. 13 5.3 Software Development ..................................................................................................................... 13 5.4 Operations Manual............................................................................................................................. 13 5.5 Phase 3 Close Out ............................................................................................................................... 14

of 14


Revision: B

Date: Apr 4, 2016

1. SCOPE & OVERVIEW OF DELIVERABLES

1.1 SCOPE

This Statement of Work (SOW) defines the tasks, deliverables, and timelines that shall be

performed and provided by Contractor as part of ATST Contract #C22027S, Amendment 006.

1.2 DEFINITIONS

ATST – Advanced Technology Solar Telescope, which is the previous name of the

telescope project now known as the Daniel K. Inouye Solar Telescope (DKIST). This

name may be used interchangeably with DKIST.

AURA – Association of Universities for Research in Astronomy

CDD – Critical Design Definition Document, the final and approved description of the

design.

COTR – Contract Officer’s Technical Representative

CSF – Common Services Framework, the DKIST software architecture required for use

in all DKIST software systems.

DKIST– Daniel K. Inouye Solar Telescope

DRD – Design Requirements Document, SPEC-0132.

FAT – Factory Acceptance Test

FATP – Factory Acceptance Test Plan

Factory – For the purpose of this SOW, the “Factory” is the DKIST Tucson site.

FOA – Feed Optics Assembly, the complete Feed Optics hardware and software

assembly, including the FOCS, M3 and M6 hexapods, and M3, M4, and M6 thermal

control systems.

FOCS – Feed Optics Control System, the software used to controls the FOA.

ICD – Interface Control Document

Phase – a distinct stage or segment of the Work

QA – Quality Assurance; a set of activities for ensuring quality in the processes by which

products are developed.

QAS – Quality Assurance System, the DKIST plan for QA.

QC – Quality Control; a set of activities for ensuring quality in products. The activities

focus on identifying defects in the actual products produced.

RFW – Request for Waiver

SOW – Statement of Work; this document

T0 – Time Zero; the start date of the Contract Award

TAF – Test Automation Framework, the DKIST test program.

Work – The development, design, fabrication, factory assembly, and factory acceptance

testing of the Feed Optics Control System (FOCS) and all of its included subsystems and

components as specified by the Design Requirements Document (DRD, SPEC-0132).

of 14


Revision: B

Date: Apr 4, 2016

1.3 CONTRACTOR RESPONSIBILITIES

The Work is defined as the development, design, fabrication, factory assembly, and factory

acceptance testing of the Feed Optics Control System (FOCS) and all of its included subsystems

and components as specified by the Design Requirements Document (DRD, SPEC-0132).

Contractor shall be responsible for all aspects of the Work.

1.4 PROJECT PHASES & MAJOR DELIVERABLES

The Work shall be subdivided into three (3) distinct Phases as shown in Table-1, “Deliverables

Schedule”. Contractor shall perform the Work and provide the deliverables by the dates specified

in the Table. Specific information on the Phases and major deliverables is included in sections 3,

4, and 5 of this SOW. Time Zero (T0) indicates the start date of the Contract award.

Payments to Contractor shall be made at the milestones listed in Table-1 and at the percentage

amount of the cumulative amount of the award given in Table-1.

Table-1 Deliverables Schedule Schedule Payments

Phase 1: Critical Design

Kickoff Meeting/Updated Project Plan T0 + 1 week 10%

Critical Design Document & ICDs T0 + 9 weeks

Software Design Review T0 + 11 weeks

Phase 1 Close Out; Alpha release T0 + 13 weeks 30%

Phase 2: Software Development

Factory Acceptance Test Plan T0 + 16 weeks

Phase 2 Close Out; Beta release, updated CDD and

ICDs

T0 + 26 weeks 30%

Phase 3: Factory Integration and Acceptance Testing

Factory Integration Complete T0 + 28 weeks

Factory Acceptance Testing Complete T0 + 31 weeks

Phase 3 Close Out; Final release, Operations Manual,

and updated CDD, ICDs, and FATP

T0 + 36 weeks 30%

of 14


Revision: B

Date: Apr 4, 2016

2. PROJECT ORGANIZATION & CONTROL

2.1 KEY PERSONNEL

Contractor shall establish and maintain an effective project organization to accomplish the

objectives of this Contract and to carry out the Work in an efficient manner. This project

organization and its management shall be separated from other Contractor projects and operations

to the extent necessary to prevent interference with the effective and timely completion of the

Work.

Contractor’s project management office shall coordinate and control all technical and commercial

activities, project resources, and manage all disciplines required to successfully complete the

Work.

The key personnel of the project shall consist of experienced and professional personnel.

Exchange and/or replacement of the key personnel during the execution of the Contract shall be

notified to and agreed upon with AURA in a timely fashion.

Contractor shall assign a Project Manager with full authority over all personnel and resources of

the project organization as well as those of other members of their industrial team. The Project

Manager shall be assigned full authority to negotiate and conclude with their subcontractors and

suppliers for all issues related to the Contract. The Project Manager shall be assigned fully

authority to negotiate and conclude with AURA for all issues related to the Contract.

The Project Manager shall be the single point of contact with AURA for all technical and

contractual matters.

AURA will appoint a Contracting Officer’s Technical Representative (COTR) who will be the

single point of contact with Contractor via the Project Manager.

2.2 DOCUMENTATION OF CHANGES AND COMMUNICATION

No aspect of the Work may be modified by verbal or informal email communications. In order to

be binding on the parties, a modification to the Work must be formally documented by the proper

AURA representative (either ATST Contracts Manager or COTR) as provided in this Contract.

When Contractor requires technical information from AURA, the COTR will provide the

information using a standard Technical Directive form and shall sign the form. All Technical

Directives will be numbered in sequential order.

Staff from AURA and Contractor may informally communicate in order to explore issues and

ideas related to the Work, provided, however, that:

The Program Manager and the COTR must be copied on all substantive email

communications between AURA and Contractor personnel and be provided with

summaries of all meeting and discussions that they were not present at; and

of 14


Revision: B

Date: Apr 4, 2016

Once informal communications have converged on a solution to an issue the COTR will

either document the agreed solution using a Technical Directive or shall ask the ATST

Contracts Manager to prepare a Contract Amendment or Change Order, depending on the

nature of the resolution of the issue.

2.3 PROGRESS REPORTS

At the end of every month, Contractor shall submit written progress reports to AURA describing

the technical, schedule, and financial progress of the Work during that month. These reports shall

include, but not necessarily be limited to:

A brief narrative on the technical progress made to date, with particular attention paid to

the progress achieved during that month;

Action items for AURA and Contractor (both open and closed), and associated status;

A table summarizing risks and associated mitigation strategies; and

An updated schedule of work.

Progress reports shall be submitted in electronic format by email to the COTR.

Independently and in addition to the regular progress reports, Contractor shall immediately report

any event, problem, or issue that has implications to the schedule, cost, or technical performance

of the Work.

2.4 MEETINGS

In addition to the Kick-Off Meeting, the Software Design Review and the Factory Acceptance

Test, Contractor shall meet regularly with AURA personnel upon request to update them on the

status of the Work and discuss any matter related to the Work. All such meetings shall be held

either at Contractor's facility or via telephone/videoconferencing.

2.5 ACCESS TO WORK AND INFORMATION

Contractor shall grant AURA personnel and representatives access during working hours to all

places where the Work is being performed, including access to locations where Contractor’s

subcontractors are performing any part of the Work.

Upon request, Contractor shall allow AURA personnel to view and copy any design

documentation, reports, or data produced under this Contract.

2.6 ACCOMMODATION AND SERVICES FOR AURA PERSONNEL

During the project Contractor shall provide office space and accommodations, furniture, and

communication facilities for AURA personnel (maximum 2 persons) who regularly visit

Contractor’s premises during the course of monitoring the Work.

of 14


Revision: B

Date: Apr 4, 2016

2.7 DELAYS

If events occur that may cause an impact to the schedule, Contractor shall evaluate every possible

method to avoid a negative outcome (e.g., a schedule slip or a delay of achieving critical

milestones). These methods may include utilization of additional Contractor manpower and

facilities.

Contractor will promptly notify AURA in writing of any event that may result in a delay in

performance or completion of the Work.

of 14


Revision: B

Date: Apr 4, 2016

3. PHASE 1: CRITICAL DESIGN DEVELOPMENT

During this Phase, Contractor shall develop the software design for the FOCS.

3.1 KICK-OFF MEETING

By the date provided in the Project Plan, Contractor shall meet with AURA for a Kick-Off

Meeting via telephone. The Kick-Off Meeting shall include:

A presentation by Contractor on the FOCS effort proposed by Contractor in its bid

proposal and as modified during contract negotiations; and

Initial discussions regarding interfaces to other systems and the commencement of the

Work.

A workshop on DKIST Common Services Framework and associated development tools

to be attended by Contractor’s staff.

Contractor’s staff to be present at the Kick-Off Meeting shall include at least the Program

Manager and lead software engineer.

3.2 PROJECT PLAN

Contractor shall submit a Project Plan to AURA for approval. The Project Plan shall consist of:

A Work Breakdown Structure (WBS) of all of the tasks necessary to complete the Work,

including but not limited to the development, design, fabrication, factory assembly, and

factory acceptance testing of the FOCS.

A schedule based upon the task list which shows when each task will be started and

completed. This schedule shall include the milestones and key dates specified above in

section 1.4 of this SOW; and

A list of the personnel resources, equipment, space, and other resources that will be used

to complete the Work that is not otherwise noted in the WBS.

Every month Contractor shall submit an updated version of the Project Plan as a part of the

progress report. This updated Project Plan shall show both the original schedule, the percent

complete of each task, and an updated schedule based on progress to date.

3.3 SOFTWARE DESIGN DEVELOPMENT

Contractor shall develop a design for the FOCS that meets the Specifications and uses the

Common Services Framework (CSF). The design shall be documented in a Critical Design

Definition document (CDD).

FOCS software shall be designed and implemented with the DKIST CSF and associated Base

packages, and shall use the CSF pkgDevel package development system. Control software shall

be written in Java (and not C++) unless specifically authorized (this does not include TAF scripts

written in Jython).

of 14


Revision: B

Date: Apr 4, 2016

Third-party software libraries shall be used only with the written approval of AURA.

3.4 SOFTWARE INTERFACE DEVELOPMENT

Contractor shall develop interfaces between the FOCS and the Telescope Control System (TCS)

and between the FOCS and the Wavefront Correction Control System (WCCS). The interfaces

shall be documented in Interface Control Documents (ICDs).

3.5 HARDWARE INTERFACE DEVELOPMENT

Contractor shall develop interfaces between the FOCS and the Feed Optics System (FOA)

hardware. The interfaces shall be documented in the CDD.

The FOA hardware includes the following:

Two Physik Instrumente E-712 hexapod controllers used to control M3 and M6 position.

Three Thermorack 401 thermal controller used to control the M3, M4, and M6 thermo-

electric coolers, and

One Lantronix EDS4100 terminal server used to communicate with the Thermorack 401

thermal controllers via Ethernet to RS-232/USB.

Contractor shall use and modify the existing CSF software controllers for the Thermorack 401

controller.

Contractor shall be responsible for the functional and performance requirements for the FOA

hardware only to the level of software development. Deficiencies in hardware functionality and

performance shall be determined through testing and reported to AURA by Contractor. FOA

hardware issues are outside the Scope of Work.

3.6 SOFTWARE DEVELOPMENT

Contractor may choose to prototype the FOCS or otherwise develop and test some parts of the

FOCS for the purpose of design analysis. All software developed during this stage shall be

committed into the DKIST CVS repository.

Contractor shall tag in CVS the FOCS software delivered at the end of this phase as the “FOCS

0.1 alpha” release.

3.7 SOFTWARE DESIGN REVIEW

Contractor shall perform a review of the CDD and ICDs by the DKIST. AURA will approve the

CDD and ICDs within 2 weeks after the review and before further development occurs.

Contractor shall present the Software Design for the FOCS at a Software Design Review per the

following:

a) The review will be held via telephone, video conference, or other remote technology.

of 14


Revision: B

Date: Apr 4, 2016

b) Contractor’s staff to be present at all reviews shall include at least the Program Manager

and lead software engineer with additional staff as needed.

c) Contractor shall notify AURA of the date it will be ready for the review at least 2 weeks

before such date. This date shall be no later than two weeks later than the date specified

in the Project Plan for the delivery of the design documentation for that review.

d) AURA will call and conduct the review on or near the date specified by Contractor.

AURA will select a review committee.

e) Contractor shall deliver the software design documentation to AURA at least 2 weeks

before the review.

g) Within ten working days after the review, the COTR will send to Contractor a review

Report based on the review committee recommendations, questions and comments. In

this report, the COTR may direct Contractor, in writing, to make changes to the design

documentation that are required in order to make it consistent with the Requirements and

this SOW. Contractor shall promptly contact the ATST Contracts Manager if it feels that

any requested changes are beyond the scope of the Requirements and request a formal

contract modification. Within ten working days after receipt of the review Report,

Contractor shall submit a Response to the review Report with point by point responses to

each of the recommendations, questions and comments. Contractor shall promptly

comply with all directions to make changes to the design documentation and submit the

revised documents for approval. Once all requested changes have been implemented, the

COTR shall notify Contractor in writing that the Software Design Documentation is

approved.

h) The review is advisory in nature and shall not relieve Contractor of any responsibility for

the successful completion of the Work in conformity with the Requirements. Similarly,

comments or discussions during the review shall not be construed as modifying or

waiving any of the Requirements or relieving Contractor of any obligations under this

Contract. As provided elsewhere in the Contract, the Requirements may only be

modified by means of a written amendment or change order to the Contract.

3.8 PHASE 1 CLOSE OUT

Phase 1 shall be considered complete when all major deliverables in this section have been:

1) Provided to AURA;

2) Reviewed by AURA within two (2) weeks;

3) Subsequent significant corrective actions have been completed by Contractor to AURA’s

satisfaction; and

4) AURA accepts the deliverables by issuing a notice of completion stating that all conditions of

the Phase have been met. The notice will be issued by the DKIST Contracts Officer within two

weeks. Contractor may progress to subsequent phases of the Work without formal close out of

the phase, subsequent to written approval from AURA.

of 14


Revision: B

Date: Apr 4, 2016

At the completion of this phase Contractor shall have delivered:

An approved FOCS Critical Design Document;

An approved Interface Control Document between the FOCS and TCS;

An approved Interface Control Document between the FOCS and WCCS; and

A tagged software alpha release.

of 14


Revision: B

Date: Apr 4, 2016

4. PHASE 2: SOFTWARE DEVELOPMENT

During this Phase, Contractor shall develop FOCS software, test plans and test procedures.

4.1 CONTROL SOFTWARE

Contractor shall develop FOCS software to control the FOA as defined by the approved CDD and

ICDs. The software development shall utilize the DKIST CVS repository for backup, storage, and

version control.

Contractor shall tag in CVS the software delivered at the end of this phase as the “FOCS 0.2

beta” release.

4.2 USER INTERFACE

Contractor shall develop FOCS Engineering Displays using DKIST Java Engineering Screens

(JES). The FOCS Engineering Displays shall be able to perform all specified behavior of the

FOCS.

4.3 SIMULATOR

Contractor shall implement a software simulator for each FOA hardware component: M3 and M6

hexapods, and M3, M4, and M6 thermal controllers. Contractor shall implement an external

WCCS simulator to provide the wavefront error event. The software simulators shall implement

the hardware interface and the functionality of the hardware component without emulating the

performance or detailed behavior. The software simulators shall be implemented using Common

Services Framework support for simulators.

4.4 FACTORY ACCEPTANCE TEST PLAN

Contractor shall develop and submit to AURA a Factory Acceptance Test Plan (FATP) document

that describes the tests procedures needed for the Factory Acceptance Tests. The FATP shall use

the DKIST Test Automation Framework (TAF). The FATP shall test all requirements in the

DRD.

Contractor shall develop TAF scripts for all relevant procedures in the FATP.

AURA will provide a response with regard to the acceptability of the FATP within two (2) weeks

of receipt. The response will either: 1) indicate that the FATP is approved as-is, 2) approved

provided certain changes are made, or 3) must be revised and resubmitted. Contractor expressly

understands and agrees that the review and approval of the plan by AURA shall not relieve

Contractor of any responsibility under this Contract for the successful completion of the Work in

conformity with the requirements and intent of this Contract. Additionally, such a review and

approval shall not operate to waive any of the requirements or relieve Contractor of any

obligation under this Contract.

of 14


Revision: B

Date: Apr 4, 2016




2) Reviewed by AURA within 2 weeks;


satisfaction; and






An updated FOCS Critical Design Document;

An updated Interface Control Document between the FOCS and TCS;

An updated Interface Control Document between the FOCS and WCCS;

A FOCS Factory Acceptance Test Plan;

A tagged set of TAF scripts for the FATP; and

A tagged software beta release.

of 14


Revision: B

Date: Apr 4, 2016

5. PHASE 3: FACTORY INTEGRATION AND ACCEPTANCE

During this Phase Contractor shall integrate the FOCS with the FOA hardware and perform the

Factory Acceptance Testing.

5.1 FACTORY INTEGRATION

Contractor shall integrate the FOCS software with the FOA hardware located in Tucson, Arizona.

Contractor shall travel to and work in Tucson to integrate the systems successfully. AURA will

provide remote access to the hardware systems as needed by the Contractor when not in Tucson.

5.2 FACTORY ACCEPTANCE TEST

At the completion of factory integration, Contractor shall perform a Factory Acceptance Test

(FAT) in Tucson using the approved FATP. The Contractor shall capture the results of the FAT

in an AURA compliance matrix for the FOCS.

Contractor shall be responsible for meeting the specifications of the FOCS and demonstrating this

at the FAT. Deficiencies or failures in the FOA hardware shall be measured and documented by

Contractor. Contractor shall be responsible for showing any FAT issues are due to FOA hardware

issues and beyond the scope of this Work.

5.3 SOFTWARE DEVELOPMENT

Contractor shall modify the FOCS software during this phase to address any and all issues

discovered by the factory integration and factory acceptance.

Contractor shall tag in CVS the software delivered at the end of this phase as the “FOCS 1.0

final” release.

5.4 OPERATIONS MANUAL

Contractor shall develop an Operations Manual that describes all procedures necessary to operate

the FOA with the FOCS.

The OM shall include the following:

Description of the build and deployment procedures;

Description of the start-up and shut-down procedures;

Description of the procedures to operate the subsystems;

Description of the default properties and their determination;

Description of the operational error conditions and the necessary remedial action;

Description of the safety procedures to operate the unit;

A listing of the operational limits of the system; and

Description of trouble-shooting.

of 14


Revision: B

Date: Apr 4, 2016




2) Reviewed by AURA within 2 weeks;


satisfaction; and






A FOCS Critical Design Document;

An Interface Control Document between the FOCS and TCS;

An Interface Control Document between the FOCS and WCCS;

A FOCS Factory Acceptance Test Plan;

A tagged set of TAF scripts for the FATP;

A completed AURA compliance matrix showing the results of the FAT;

Any and all Requests for Waiver (RFW);

An Operations Manual; and

A tagged final release for the FOCS.