Observatory Control System Specification · Steve Wampler, Bret Goodrich Software Group August 2016...

Project Documentation Document SPEC-0015

Revision E

Observatory Control System

Specification

Alexandra Tritschler

Science Group

Steve Wampler, Bret Goodrich

Software Group

August 2016

Name Date

Released By : Joseph McMullin

Project Manager 01-Sep-2016

Observatory Control System Specification

SPEC-0015, Revision E Page ii

DOCUMENT APPROVAL HISTORY


SPEC-0015, Revision E Page iii

REVISION SUMMARY:

1. Date: August 30, 2006

Revision: Draft 1

Changes: Created.

2. Date: December 30, 2008

Revision: Draft 2

Changes: Updated source identification terminology, cleaned up requirements

3. Date: March 9, 2009

Revision: Draft 3

Changes: Reorganized structure, adjust requirements to match new use cases

4. Date: March 23, 2010

Revision: Draft 4

Changes: Updated for clarity, added David Elmore as principal author.

5. Date: May 10, 2010

Revision: Draft 5

Changes: Add requirement for simultaneous control of multiple instruments and for multiple

simultaneous experiments

6. Date: July 14, 2010

Revision: Draft 6

Changes: Significant re-write for clarity

7. Date: July 21, 2010

Revision: Draft 7

Changes: Revisions based upon input at 14 July Sunspot meeting


Revision: Draft 8

Changes: Revisions based upon 21 July teleconference


Revision: Draft 9

Changes: Revisions based upon 2 August teleconference from Wampler, Tritschler, and Elmore.

Many SCD sources changed to SCR. Trace back to OCD expanded.


Revision: Draft 10

Changes: Flow down from SRD and ISRD included, using SPEC-0096 as a guide and revised

sections in source documents. ISRDs cited are either under revision control or submitted for revision

control. Added requirement for units of parameter sets for observations.

11. Date: November 8, 2010

Revision: A

Changes: Remote Operations from the ROB and Remote Participation are clarified. They are

written to encompass the simplest implementation and to avoid policy.

12. Date: May 23, 2012

Revision: A1

Changes: Editorial changes as a consequence of the OCS/DHS/ICS PDR. Remote operation

allowed but NSO policy required. Added Experiment Tracking following Science Team discussions.

Clarifications from HLS included. Many updates to requirement source numbers throughout.


SPEC-0015, Revision E Page iv

13. Date: June 5, 2012

Revision: A2

Changes: Clarification of 0115 following wording by Bret. Deleted format change balloons and

addressed comments.

14. Date: July 2, 2012

Revision: A3

Changes: Added notification of instruments dropping and opportunity to allow instruments to re-

join. Following OCS show and tell added run-time parameter limitations and AO lock point selection

requirements. Made revisions to experiment preparation, experiment control, and target selection.

Now using ‘experiment program’ term throughout. Updated references to 27 June 2012 OCD.

15. Date: July 26, 2012

Revision: A4

Changes: Discussions with Thomas, Friedrich, and Joe in Belgium, email from Thomas, and

discussions with Joe, Ali, Friedrich, and David in Sunspot led to a change in the interface between

OCS and Experiment Database. All experiment generation is outside the prevue of the OCS, which

becomes an operator-only system. Figure 1 modified to eliminate experiment creation. Typos fixed

16. Date: September 12, 2012

Revision: A5

Changes: Changes to address conclusions from OCS Discussions to align terminology, scope, and

concepts of experiment management through the OCS. Terminology now uses, Experiments

composed of Observing Programs that have Observing Program Scripts and Observing Program

Script Parameters. These Observing Programs contain Observing Blocks that are sent to sub-systems

and these Observing Blocks contain Observing Block Scripts and Observing Block Script Parameters.

Captured in Figure 2. Tweaking of Adjustment-enabled parameters eliminated. Requirement to log

Operator entries and automatically log start, end and % completion of Observing Programs added.

Ensemble of OCS controlled databases is called the Engineering Database. The OCS must provide a

tool to query this database. Pause/Resume eliminated. Dropout/Re-join eliminated Clarifications

made throughout. Formatting corrections made throughout.

17. Date: October 22, 2012

Revision: A6

Changes: OCS Operator Log specified

18. Date: November 5, 2012

Revision: A7

Changes: When not executing an experiment the OCS is in Free-run. All capabilities required

during free-run have been added or moved to -0500 requirements. Status of sub-systems must be

visible. These have been added as -0600 requirements.


Revision: A8

Changes: Data disposition for test and free-run added. Specifics of what must be provided for

remote participation added. Non-solar targets clarified. Instrument fields of view added to solar

target selection display. Interactive driving of the telescope position added. Multiple simultaneous

screens added.


Revision: A9

Changes: Typos fixed. Requirement 0410 now has the ability to fetch INTERNET served weather

data such as Sky Brightness.


SPEC-0015, Revision E Page v


Revision: A10

Changes: Introduction of Operational Modes to clarify behavior of system when executing

Observing Programs. Removed requirement of OCS to “manage” Experiments; Experiment

management job transferred to the Experiment Management Tool. Added requirement for OCS to

save modifications to parameters when executing in Manual mode. Added requirement for OCS to

save data (if desired by the Operator) when executing in Manual mode. Removed restriction to not

transfer any data from Test mode execution to the data archive; such data may be transferred if

desired by any DKIST actor. Removed the description of Observing Program structure (Figure 2) and

all references to “Observing Blocks”. Introduced the concept of Ready state as the state into which

the OCS places the facility after the Start-up and Opening operations. Clarified that the OCS reads

from a “Summit Experiment Database” which is a subset of the full Experiment Database and is read

in across the firewall on a daily basis. Added the requirement for the OCS to display the daily “As

Planned” observing queue or “Timeline” created by the RA. Added the requirement for the OCS to

output to the Summit Experiment Database data necessary to create the “As Run” Timeline by the

RA.


Revision: A11

Changes: Change “Operational Modes” to “Program Modes” and “Program Mode” to “Automatic

Mode” to reflect that the OCS only runs programs and to avoid confusion with earlier uses of the

terms “operational” or “observing” modes.

23. Date: February 16, 2013

Revision: A12

Changes: ‘Test’ changed to a selection rather than a Mode throughout to match OCD. The OCS

does not create the Operators Log, but is responsible for collecting and archiving all manual,

triggered, and acquired entries such as from the weather station. Cancel and Abort are available in

Manual and Automatic on a per instrument basis. Facility activities of startup, opening, closing, and

shutdown made more explicit as separate from experiment execution to match OCD. Sun centering

moved to opening from Ready. Environmental status display is tied to Daily Log Requirements.

24. Date: March 1, 2013

Revision: A13

Changes: Final editing before CR submission. Added requirement 4.2-2002 in Sec. 2.11 to ensure

single Operator control of facility at any time.

25. Date: March 4, 2013

Revision: A14

Changes: Comments of S. Wampler addressed (see email to B. Goodrich 3/4/13). 4.2-0160

clarified. Extensive modification of 4.2-0170 Target Selection Tool and 4.2-180 TST Image data. 4.2-

0270 also touched.

26. Date: March 14, 2013

Revision: A15

Changes: major changes in response to meeting at Sunspot on 12—14 March with Rimmele,

McMullin, Goodrich, Berger, Elmore, Tritschler, and Woeger.

- Reorganized table of contents.

- Introduction extensively re-worded and cross-referenced to requirements.

27. Date: April 18, 2013

Revision: A17

Changes: Renumbered everything. Removed -0235 on remote participation.


SPEC-0015, Revision E Page vi

28. Date: April 22, 2013

Revision: A18

Changes: Cancel and Abort clarified for Instrument Programs and Observing Programs. Dozens of

run on words corrected.

29. Date: April 25, 2013

Revision: A19

Changes: Typos and deletion of obsolete term “Observing Program Parameters”. 4.2-0610 Target

selection tool added req’ts: display cursor at Operator specified coordinates and report coordinates at

cursor click position.

30. Date: 17 June, 2013

Revision: B

Changes: SEIC requested a review by Friedrich and Ali and their comments were discussed with

Tom and David. Terminology clarified with the addition of a glossary, responsibility of OCS for data

bases clarified as well as details of OCS responsibilities for Manual and Automatic modes. Other

clarifications added throughout.

31. Date: 9 January 2014

Revision: B1

Changes: Added more information to 4.2-0720 to describe the flow down of pointing offset from

the science requirements to the TCS and WCCS, per CR-0448.

32. Date: 13 March 2014

Revision: C

Changes: Removed requirements based upon SPEC-0005 (SCR) and SPEC-0013 (SCD) that apply

to systems in general and not specifically to the OCS. Added the ability to write modified

Experiments, Observing Programs, and targets to the Experiment Database at the ROB. Logging

percent completion removed. The OCS has no way to know IP completion or timing of observing

programs.

33. Date: 5 December 2014

Revision: D

Changes: Changes in response to readiness review, discussions during Boulder 2014 Workshop,

discussions with Steve Berukoff and Steve Wampler, and the Science Team. Edits include:

clarifications to manual and auto mode, addition of requirements and more detailed information of

logging, format of logging, tagging of Observing Programs, Instrument Programs and data itself in

order to assure proper tracking of activities for operational purposes, addition of requirements to

display and log and archive information from the FCS and GIS, some changes to capabilities of the

target selection tool, addition of requirements for default state, default operational mode, and

operational modes. Changes per CR-0594.

34. Date: 17 November, 2015

Revision: D.

Changes: Changes in response to HLS FDR 2015: removal of the term and all references to

“observables”, removal of all phrases “at a minimum but not limited to”, and shortening/clarifying the

introduction bringing it into line with other HLS documentation. Other changes (as a consequence of the


SPEC-0015, Revision E Page vii

TCHP specification): removed requirement for OCS to support AO field steering mirror via analog input

device as this will not be a functionality of the analog input device to begin with; removed requirement

for OCS to support target orientation via the analog input device as this will not be a functionality of the

analog input device to begin with. Other changes (as a consequence of a better understanding of the

DHS): added requirement for OCS to support the display of Operator-DHS interaction information

(similar to the Operator-AO interaction information). Other changes: removed requirement to display

progress of OP execution in manual mode: there is no OP execution in manual mode and as such this

requirement is obsolete; added requirement for OCS to support telescope mosaicking; added requirement

to support the operator in making changes to allowable instrument parameters prior OP execution Other

changes (as a consequence of clarification on the OCS-Operations interface): added requirement to

support completion assessment of OPs by operations. Clarified definition of percent complete. Deleted

“Contribution to the Error Budget” requirement.

35. Date: August 2016

Revision: E

Changes: Update of SPEC-0015 as a response to the HLS-FDR; see CR-0726.


SPEC-0015, Revision E Page viii

Table of Contents

1. Introduction ...................................................................................... 1

1.1 OCS RESPONSIBILITIES.................................................................................. 1

1.2 DEFINITIONS .................................................................................................... 2

1.3 RELATED DOCUMENTS .................................................................................. 3

1.4 ACRONYMS ...................................................................................................... 4

1.5 SOURCES ......................................................................................................... 4

1.6 VERIFICATION .................................................................................................. 4

2. Functional Requirements ................................................................. 6

2.1 BASIC ................................................................................................................ 6

2.2 FACILITY CONTROL ......................................................................................... 8

2.3 EXPERIMENT CONTROL ............................................................................... 12

2.3.1 AUTOMATIC OPERATIONAL MODE ........................................................................ 16

2.3.2 MANUAL OPERATIONAL MODE ............................................................................. 17

2.3.3 OPERATOR TOOL REQUIREMENTS ....................................................................... 19

2.3.4 OTHER OCS PROGRAM EXECUTION REQUIREMENTS ............................................ 22

2.4 OCS LOGGING REQUIREMENTS .................................................................. 24

2.5 STATUS REPORTING REQUIREMENTS ....................................................... 26

2.6 SECURITY REQUIREMENTS ......................................................................... 26

2.7 SAFETY REQUIREMENTS ............................................................................. 26

2.8 VALIDATION .................................................................................................... 26


SPEC-0015, Revision D Page 1 of 27

1. INTRODUCTION

This document defines the design specifications for the DKIST Observatory Control System

(OCS). The OCS is one of the four principal software systems of the DKIST, along with the Data

Handling System (DHS), Telescope Control System (TCS), and Instrument Control System

(ICS). Together, these systems provide end-to-end control of experiments at the DKIST facility.

The OCS coordinates experiments, their observations and user interactions with them. The DHS

manages the on-site flow, storage, processing, and display of image data. The TCS operates the

mechanical and optical structures. The ICS coordinates actions of the instruments and their

associated mechanisms and cameras. All four software systems are built on top of the DKIST

Common Services Framework (CSF).

1.1 OCS RESPONSIBILITIES

The major purpose of the OCS is to provide centralized control and monitoring of those DKIST

systems that are under the operator’s control. Furthermore, the OCS has important resource

management responsibilities.

The basic functions of the OCS can be summarized as follows:

Provision of DKIST systems control: TCS, TCS sub-systems, ICS, FCS, and DHS [0020-1

– 0020-4, 0270, 0400, 0500, 0590, 0600].

Provision of user interfaces for DKIST systems control: graphical and command line user

interfaces for observatory operations [0270, 0550, 0560, 0630, 1200].

Provision of two operational modes:

Automatic Operational Mode (Execution Mode) [0500, 0510]: Observing Programs are

either executed or tested automatically, i.e. the Observing Program and its Observing

Program Script control the TCS, TCS sub-systems, ICS, Instruments, and DHS, and data

is stored by Experiment ID. Data storage when testing is optional.

Manual Operational Mode [0540, 0550, 0560]: Instrument Programs are executed,

created or tested manually, i.e. the Operator manually controls the TCS, TCS sub-

systems, Instruments, and DHS. Data storage in manual mode is optional.

Facilitation of the transfer of Experiments and their Observing Programs by Experiment

between Operations and summit data bases [0410].

Facilitation of resource monitoring, notification and reporting services [0020-3, 0020-5,

0020-7, 0210].

Management of summit databases: for Observing Programs, observing program scripts,

Instrument Programs, target tables, facility task scripts, and engineering data [0020-8, 0200,

0210, 0240].

Management of CSF and its services [0010, 0020-6, 0020-7, 0210, 0230, 0260].



The OCS acts as the primary interface between operators and the DKIST software systems

during normal operation. The OCS allows operators to view lists of Experiments, select

Experiments and Observing Programs, choose targets for Observing Programs, test Observing

Programs, execute Observing Programs, and monitor and control Observing Programs during the

execution.

Experiments, Observing Programs, and Instrument Programs are created by an Operations Tool,

external to the OCS, and stored in an Operations Database. The OCS will import lists of

Experiments, their Observing Programs and Instrument Programs on a likely daily basis into the

summit databases for testing, modification, and execution.

An Observing Program (OP) is the fundamental scheduling unit that the OCS ingests and

executes. Observing Programs and their scripts coordinate the actions of the telescope systems

with the instrument systems to accomplish a science or calibration observation. The structure and

format of an Observing Program is outlined in the Operational Concepts Document (OCD)

[SPEC-0036] and detailed in the ICD between Operations and the OCS. An Observing Program

is tailored to a specific Observing Task; there are Observing Programs for the “observe” task and

several “calibrate” tasks (e.g. “polarization calibration” task, “dark” task, “gain” task, etc.)

Observing Tasks are defined in the OCD. Each Observing Program has detailed instructions for

obtaining appropriate data from one or more of the Facility Instruments. Observing Programs

(may) also contain instructions for telescope movements, e.g. in the case of creating large mosaic

images or in obtaining sequenced data at a pre-defined number of solar disk positions (for center-

to-limb studies for example). Observing Program execution is the sole responsibility of the OCS,

which communicates the details required for the other principal systems to carry out each step of

the observation including the coordination and parallel operation of multiple instruments.

Furthermore, the OCS serves as the system with which the operator interacts to accomplish daily

Facility Tasks such as Startup, Solar-Open, Non-Solar Open, Close, Standby, and Shutdown.

The OCS also has managerial responsibilities for the DKIST software systems. The TCS, ICS

and DHS (as well as the OCS itself) are resources that are managed by the OCS. The OCS

provides for direct operator control of these systems as needed while still supporting automatic

performance of routine tasks. The OCS manages the Common Services Framework (CSF), its

services (e.g. event, alarm, log,) and its summit databases The OCS provides tools to examine

system diagnostic information, handle alarm conditions, monitor safety systems, and support

routine engineering tasks.

1.2 DEFINITIONS

Experiment An Experiment is the implementation of an approved DKIST Proposal. It

encompasses all activities (automated and non-automated) and all products that

may result from those activities (e.g., parameters, programs, collected data).

Experiments are built from a sequence of Observing Programs, each tailored to

accomplish a given Observing Task.

Observing Program Observing Programs are the building blocks of an Experiment and the basic

scheduling units for the OCS. The OCS executes Observing Programs. Observing

programs contain information pertaining to subsystems relevant for the specific



Observing Task. For each Observing Task, the OCS executes an Observing

Program Script that specifies (1) all relevant telescope, AO, and PA&C

information, (2) all instrument information, and (3) the appropriate DHS

information.

Observing Task An Observing Task is a specific work element that takes place in an ordered

manner during an observing day. For example, the main science observations take

place during the “Observe” Task. Similarly, there are a number of calibration

Observing Tasks that must be completed depending on the instruments being used

and the e they are obtaining.

Instrument Program For each Facility Instrument in an Observing Program there is at least one

associated Instrument Program that encodes the actions to be taken for that

particular Observing Program. For example, for the Observe Task, the OCS

Observing Program contains Instrument Programs for each participating Facility

Instrument that encodes the desired sequence of Observables to run during science

observations. Observing Programs include sequences of one or more Instrument

Programs for each requested instrument.

Pacing Instrument A Pacing Instrument is an instrument that has been designated in a particular

Observing Program as an instrument that takes the longest to complete the

observing sequence. The pacing instrument is not to be confused with the must

complete instrument.

1.3 RELATED DOCUMENTS

SPEC-0009, DKIST System Error Budget.

SPEC-0016, Data Handling System Specifications.

SPEC-0021, Telescope Control System Software Design Description.

SPEC-0022, Common Services Framework Users’ Manual.

SPEC-0064, Observatory Control System Design Document.

SPEC-0123 Facility Instrument Definition.

ICD 3.1.4-4.2, ICS to OCS.

ICD 4.2-4.3, OCS to DHS.

ICD 4.2-4.4, OCD to TCS.

ICD 4.2-4.5, OCS to GIS.

ICD 4.2-6.7.4, OCS to FCS.



1.4 ACRONYMS

AO Adaptive Optics

ASI A Simple Instrument

ATST Advanced Technology Solar Telescope

DKIST Daniel Ken Inouye Solar Telescope

CEP Common Engineering Practice

CLUI Command Line User Interface

CSF Common Service Framework

DHS Data Handling System

FCS Facility Control System

GIS Global Interlock System

GUI Graphical User Interface

ICD Interface Control Document

ICS Instrument Control System

JES Java Engineering Screen

LAN Local Area Network

OCD Operational Concept Definition

OCS Observatory Control System

PA&C Polarimetry Analysis and Calibration

ROB Remote Operations Building

SCD Software Concepts Definition

SCR Software and Controls Requirements Document

SRD Science Requirements Document

TAS Target Acquisition System

TCS Telescope Control System

WCS Wavefront Correction System

WCCS Wavefront Correction Control System

1.5 SOURCES

This document derives requirements from the DKIST Science Requirements Document (SPEC-

0001, SRD), the DKIST Operational Concepts Definition (SPEC-0036, OCD), the DKIST Data

Model (SPEC-0122), and the DKIST Software and Controls Requirements Document (SPEC-

0005, SCR). Some requirements are considered common engineering practice (CEP).

1.6 VERIFICATION

Included in each major numbered specification listed in this document is a requirement

verification method. These verification methods specify the minimum standards of verification

required to ensure that the individual requirements and specifications are met. Examples of

verification methods include:

Design Review. Verification by design review means that it is shown during an appropriate

design review that the system meets specification by way of its intrinsic design and

configuration.



Analysis. Verification by analysis demonstrates that the design meets the specification

through use of performance modeling metrics.

Test. Verification by test and/or measurement means that it is demonstrated that the as-built

system meets the specification through measurements of its operation performance. Testing

is performed during acceptance testing and/or as part of a pre-ship readiness review.

Inspection. Verification by inspection means that visual inspection verifies that the

specification has been achieved on the as-built system during preassembly and/or during Site

assembly.



2. FUNCTIONAL REQUIREMENTS

2.1 BASIC

4.2-0010 Scope

The OCS shall comprise the software and hardware systems required to control the DKIST

principal systems, TCS, DHS, ICS, FCS, and OCS itself.

The OCS shall manage experiment control.

The OCS shall manage CSF resources.

The OCS shall manage operator interactions.

Verification: Design Review, Inspection.

Requirement Origin: Operations (OCD 7.1, 2.3.6).

4.2-0020-1 Telescope Control System

The OCS shall control the configuration and behavior of the telescope and its subsystems

through the Telescope Control System.

The OCS shall obey the interface defined between the TCS and the OCS.

Verification: Design Review, Test.

Requirement Origin: Operations.

4.2-0020-2 Instrument Control System

The OCS shall submit instrument programs and monitor completion of those programs via the

Instrument Control System.

The OCS shall obey the interface defined between the ICS and the OCS.



4.2-0020-3 Facility Control System

The OCS shall be responsible for logging and archiving all FCS state changes and alarms.

The OCS shall monitor and display all FCS state changes and alarms.

The OCS shall be responsible for sending configurations to the FCS.

The OCS shall obey the interface defined between the FCS and the OCS.


Requirement Origin: Operations

4.2-0020-4 Data Handling System

The OCS shall configure camera lines, detailed display processing, and display data flow and

volume for the Data Handling System.

The OCS shall obey the interface defined between the DHS and the OCS.





4.2-0020-5 Global Interlock System

The OCS shall be responsible for logging and archiving all GIS state changes and alarms.

The OCS shall monitor and display all GIS state changes and alarms.

The OCS shall obey the interface defined between the GIS and the OCS.



4.2-0020-6 Common Services Framework

The OCS shall control the DKIST Common Services Framework [0200].



4.2-0020-7 Software Resources

The OCS shall manage the observatory software resources, including CSF services, containers,

and lifecycles [0200].



4.2-0020-8 Databases

The OCS shall manage summit databases [0210].

The OCS shall log and/or archive information to summit databases according to a predefined,

configuration-controlled format, to include, but not be limited to:

Time: UTC Time stamp accurate to the millisecond.

Source of the message: Name of the system producing the message or doing the

archiving.

Category of the message: default, star, flow, event, alarm, health, connect, command,

lifecycle, DB, archive, property, script, parameter set, action.

Mode of the message: note, debug, severe, warning.

Level: level if mode is debug.

Message: arbitrary string.

UID: serial field to allow messages coming out faster than once per millisecond to be

ordered (set by the DB).

Name and Value of attributes.


Requirement Origin: Engineering.



4.2-0030 Best Software Practices

The OCS shall adopt the software practices specified in the SCR.

Description: General software requirements are defined in the SCR along with other general

specifications for DKIST Systems and Assemblies. These place uniform requirements upon all

Assemblies to promote conformity and ease of operations and maintenance. The software

standards defined in this document fall into two areas: functional requirements of the DKIST

software infrastructure and implementation requirements of the System. For the former, the

requirements define how a system should interface and interact with the DKIST infrastructure

and other DKIST software systems. For the latter, the requirements define standards for source

code, documentation, maintenance, and interfaces.


Requirement Origin: Engineering (SCR 6, 9).

4.2-0030-1 Default State

The default state of the OCS shall be running.


Requirement Origin: Engineering (SCR 6, 9).

4.2-0030-2 Operational Modes

The OCS shall support a minimum of two operational modes: manual and automatic.


Requirement Origin: Operations (OCD).

4.2-0030-2 Default Operational Mode

The default mode shall be the manual operational mode.



2.2 FACILITY CONTROL

4.2-0200 Software Facility

The OCS shall manage the software facility control necessary to operate the facility.

The OCS shall be the controller and sole owner of all facility software systems. Facility

software systems shall be defined as: the Common Services Framework (CSF), its services and

databases, and all CSF software containers at the DKIST facility.

Note: Software facility control shall be defined as: the deployment and lifecycle management of

the software containers and the software controllers loaded into the containers, the starting and

stopping of CSF services, and the initialization and management of CSF databases.

Verification by: Design Review, Inspection

Requirement Origin: Engineering (SCR 9)



4.2-0210 Services Control

The OCS shall control and monitor all control software framework services.

The OCS shall control the starting, stopping, initialization, resetting, and diagnostic activities of

all services.

The OCS shall control the following:

Connection service—locating and connecting distributed components.

Event service—registering, sending, and receiving asynchronous events.

Experiment service—managing the summit databases including but not limited to those

needed to store experiments, observing programs, engineering data [0240], and target tables.

Property service—storing and delivering component properties.

Log service—storing and writing log information.

Health service—checking the health of system components.

Alarm service—notifying the operator of any unusual conditions.

Verification by: Design Review, Test.

Requirement Origin: Engineering (SCR 9).

4.2-0220 Database Access

The OCS shall provide an interface to summit databases under its control and/or management,

and shall provide a query tool into those databases to allow searching for the following and any

combination thereof:

UTC time.

UTC time period.

Source.

System or other Identifiers.

Category.

Mode.

Level.

Message or comment types.

Names of Attributes.


Requirement Origin: Engineering (CEP).

4.2-0230 Deployment Control

The OCS shall control the deployment of subsystems, their software containers and components,

and their lifecycles.



The OCS shall have direct control over all CSF containers at the facility, and be able to start and

stop them and their associated services.

The OCS shall be able to deploy components into containers and monitor and control the

lifecycle states of components and containers.

Verification by: Design Review, Test

Requirement Origin: Engineering (SCR 9)

4.2-0240 Engineering Archive

The OCS shall manage and operate the CSF engineering archive as one of its databases.

The OCS shall use the engineering archive to store all log, command, and event activity at the

observatory.

The OCS shall be capable of writing commands sent by the OCS to the TCS, ICS, DHS and FCS

to the engineering archive, along with the name or identifier for the current Observing Program

and the Experiment name or identifier the Observing Program belongs to.

The OCS shall maintain an online record of the engineering archive for at least one week.

The OCS shall export all engineering archive data into offline storage saved at the summit.

Description: The engineering archive is a persistent store of log messages generated by the

DKIST software systems. Depending upon the configuration of each software system the

engineering archive may receive debug and diagnostic information, warnings and error reports,

alarms, event activity, operator comments, and any other information written to the engineering

archive interface by CSF applications.


Requirement Origin: Engineering (SCR 2), Operations (OCD6.2.1).

4.2-0260 Simulation Control

The OCS shall allow simulation of the functionality of components under its control.

The OCS shall manage the use of simulation and simulators.

Description: Major DKIST software subsystems such as the telescope mount, M1 assembly, etc.,

are required to provide simulators for their internal components. These simulators are used to

both test the system interfaces and replace non-operational real components. The OCS is

required to manage the use of simulators during operations so that failed or missing hardware

can be replaced by a simulator.



4.2-0270 Facility Operations Task Properties

The OCS shall execute individually selectable facility programs from a GUI for Startup,

Opening, Shutdown, and Closing operations of the enclosure, telescope and associated sub-

systems.

These tasks shall support a mixture of fully automated and interactive activities with the operator

being prompted.



It shall be possible for the operator to execute facility tasks stepwise with a facility operations

script for each step. The OCS shall be able to execute Observing Programs after any facility

operations task.

The facility operations GUI shall be separate from observing program control.

Note: Activities during Startup, Opening, Closing, and Shutdown are guided by safety. Exact

procedures will be developed during IT&C. It is expected that initial programs for these Tasks

will be highly interactive with the Operator frequently prompted by the OCS. Activities may

become more automated as procedures and safety activities are clarified. Once developed it is

expected these facility operations tasks will be unchanged from day to day. The stepwise

capability allows for opening up to the state where the enclosure and M1 are awaiting suitable

weather conditions meanwhile the operator is selecting targets or testing observing programs.

The following list of FO Tasks is a minimum; additional FOTs may be added during or after

IT&C as needed for proper operation of the facility.


Requirement Origin: Operations (OCD, 4.2.2, 8.2.6).

4.2-0280 Facility Operations Task – Startup

The OCS shall instruct all sub-systems under its control to power up and come on line or inform

the operator to perform these actions.

The OCS shall be updating and displaying health status of sub-systems throughout startup.

At the completion of Startup the OCS shall be in its default state and operational mode.



4.2-0290 Facility Operations Tasks – Solar Open

The OCS shall provide the functionality to open the facility, i.e. to acquire the sun, open the

enclosure shutter, open the M1 cover, put in the 2.8 arc-minute field stop, perform a sun-center

algorithm, return to sun center, calibrate the AO and return to sun center afterwards.



4.2-0300 Facility Operations Tasks – Close

The OCS shall provide the functionality to close the facility, i.e. close the M1 cover, close the

enclosure shutter, and park the telescope.



4.2-0310 Facility Operations Tasks – Shutdown

The OCS shall inform appropriate sub-systems under its control to go offline and power down or

inform the operator to perform such actions to arrive at the nighttime facility operating condition.





4.2-0320 Facility Operations Tasks – Non-Solar Open

The OCS shall provide the functionality to open the facility, i.e. to open the enclosure shutter,

open the M1 cover, and put in the 2.8 arc-minute field stop.

Note: Non-solar Open does NOT imply observations at a particular time of the day. It is

expected that after non-solar open the operator has full control over the TCS and sub-systems

that the operator has access to via the OCS.



4.2-0330 Facility Operations Tasks – Standby

The OCS shall provide the functionality to close the enclosure shutter and M1 cover during

daytime while continuing tracking the Sun and after non-solar open [0320].



2.3 EXPERIMENT CONTROL

4.2-0400 Observing Program Execution

The OCS shall execute Observing Programs associated with Experiments at the OCS level

[0510].

After Observing Program execution, the OCS shall return into its default operational mode.

The OCS shall display time to complete for Observing Programs as reported by the OCS script

and from instruments via the ICS.

The OCS shall support Testing of Observing Programs through their full execution:

At night with a limited TCS functionality where the TCS is not actively tracking but can

be pointed in elevation if necessary, the GOS and the coudé rotator are accessible, and

no operator interactions are required (TCS Passive=True).

During the day with either the limited TCS functionality or the full TCS functionality

where the TCS is tracking the Sun, operator interactions may be required, and data can

be optionally stored (TCS Passive=False).

Note: It is expected that Observing Programs are implemented as scripts that are executed by the

OCS. Furthermore, the ability to test observing programs whether solar pointed or not provides

for testing of programs during the day when observations conditions are not sufficient for science

observations or for testing at night. It is recognized that operator actions preparing for observing

program testing may differ from actual operations since the TCS may not be actively tracking the

sun. It is anticipated that most Engineering data produced when Test is selected will be deleted

from the Summit data system and not transferred to the data archive at the ROB or to the NSO

Data Center. However, transfer of Test data to these external sites will be at the discretion of the

Operator or RA.




Requirement Origin: Engineering (SCR 9), Operations (OCD 5.3).

4.2-0410 Interaction with Operations

The OCS shall import customized lists of Experiments, Experiments, Observing Programs,

targets and AO lock-points associated with these targets from Operations to summit databases.

The OCS shall export modified Observing Programs, targets and AO lock-points associated with

the targets from summit databases to Operations.

Note: A customized list is a list of Experiments that all belong to the same category. Notorious

examples include but are not limited to: (1) list of all Experiments planned for execution on the

next day, (2) list of all Experiments where the calibration Observing Programs still need to be

performed, (3) list of Experiments that are of technical nature like Observing Program based

engineering Experiments or Experiments for characterization of the polarization properties of the

telescope, (4) list of all Experiments that are of type Target of Opportunity, etc. The

customization is performed by Operations. The OCS is expected to be able to differ between

these different lists.



4.2-0415 Obey OCS/Operations Interface

The OCS shall obey the interface defined between Operations and the OCS.


Requirement Origin: Engineering (CEP).

4.2-0420 Interaction with Summit Databases

The OCS shall tag Observing Programs with, log, and report to summit databases the following

Observing Program status information with the Observing Program:

Successfully/unsuccessfully canceled.

Successfully/unsuccessfully aborted

Successfully/unsuccessfully executed.

The OCS shall tag Observing Programs with, log and report independent of Observing Program

status the Observing Program start time, end time, total wall-clock run-time, the lapse time,

percent complete, and the Experiment ID the Observing Program was run under, to summit

databases.

The OCS shall tag Instrument Programs with, log and report to summit databases the following

Instrument Program status information on a per instrument basis via the ICS:

Successfully/unsuccessfully canceled,

Successfully/unsuccessfully aborted.

Successfully/unsuccessfully executed.

The OCS shall tag Instrument Programs with, log and report independent of Instrument Program

status the Instrument Program start time, end time, wall-clock run-time, percent complete, and



the Observing Program ID and Experiment ID the Instrument Program was run under, on a per

instrument basis to summit databases via the ICS.

Percent complete shall be defined as the ratio between lapse time and a reference time defined by

Operations.

The OCS shall tag Observing Programs with, log and report to summit databases the following

Observing Program test status information:

Successfully/unsuccessfully tested.

TCS Passive (True/False).

Data Save (True/False)

The OCS shall write and annotate modified Observing Programs and Instrument Programs to

summit databases.

The OCS shall write modified target information on a per Observing Program basis to summit

databases.

The OCS shall write modified AO-lock point information on a per target basis to summit

databases.



4.2-0500 Experiment and Observing Program Control

The OCS shall provide the DKIST operator with interactive tools to

Display and select customized lists of Experiments and their associated Experiments. For

each list display:

o List Identifier.

o List name.

o Associated Experiments.

Display and select Experiments and their associated Observing Programs. For each

selected Experiment display:

o Experiment Identifier.

o Experiment Name

o Title of Experiment.

o Type of Experiment (Standard, Synoptic, Survey, Target of Opportunity).

o Coordination and time window.

o Description of Experiment/Proposal

o Associated Observing Programs and their Observing Task

o Experiment status information (simulated, tested, scheduled, executed).



Display and select Observing Programs and their associated Instrument Programs. For

each selected Observing Program display:

o Observing Program Identifier.

o Observing Program Name.

o Associated Instrument Program Sequences and Instrument Programs.

o Observing Task.

o Instrument set.

o Must-complete instruments.

o AO-optimized instrument.

o Number of required targets.

o Pointing requirements on a per target basis.

o Mosaicking requirements.

o Required observing conditions (Fried parameter range, light level range, sky

brightness range).

o Light-beam configuration.information.

o Operator-AO interaction (passive or interactive).

o DHS configuration information.

o Description of Observing Program.

o Observing Program status information (simulated, scheduled,

successfully/unsuccessfully tested, cancelled, aborted, or executed).

Display and select Instrument Program Sequences and their associated Instrument

Programs. For each selected Instrument Program display:

o Instrument Program Sequence Identifier.

o Instrument Program Sequence Name.

o Instrument Program Identifier.

o Instrument Program Name.

o Instrument Program Parameters.

Search for the following and a combination thereof:

o Experiment Identifiers and Names.

o Observing Program Identifiers and Names.

o Instrument Program Sequence identifiers and Names.

o Instrument Program Identifiers and Names.

o Instruments.

o Observing Tasks.



Select Test and TCS Passive (True/False) for an Observing Program.

Select optional data storage when Test is selected.

Select execution of an Observing Program.

Make changes to allowed instrument parameters.

Manually override tagging and reporting to summit databases that an Observing Program

was successfully/unsuccessfully tested.

Note: An Instrument Program Sequence contains all Instrument Programs that are supposed to be

executed in sequence by one instrument. The Instrument Program Sequence is part of a Task

Group.


Requirement Origin: Engineering (SCR 5), Operations (OCD, 4.2.2, 8.2.6).

2.3.1 Automatic Operational Mode

4.2-0510 Automatic Observing Program Execution

When the Observing Program execution is started, the OCS shall

Execute the Observing Program script automatically, i.e. with no operator interaction

required except when encoded and advised in the Observing Program Script.

Pass Observing Program Parameters extracted from the Observing Program to the TCS to

configure the TCS and its sub-systems.

Pass instrument related information to the ICS.

Notify instruments via the ICS that the TCS is configured.

Display time when Observing Program was started.

Display Observing Program time to complete.

Allow the operator to cancel or abort an Observing Program.

Allow the operator to select cancel or abort on a per instrument basis.

Allow operator interaction for target selection on a per Observing Program basis at

defined locations in the Observing Program Script.

Allow operator interaction for AO lock-point definition on a per target basis and a per

Observing Program basis at defined locations in the Observing Program script.

Display and inform the operator about what interaction (passive/interactive during or

before Observing Program execution as encoded in the Observing Program and

Observing Program script) related to AO-lock point definition and adjustment as is

required.

Note: Details on this behavior can be found in SPEC-0064. Cancel and abort on a per instrument

basis are supported by instrument status screens. Submit is not allowed on a per instrument basis

in automatic mode.




Requirement Origin: Engineering (SCR 2), Operations (OCD 6.2.4).

4.2-0520 Observing Program script status display and recording

The OCS shall display progress of Observing Program scripts run in Automatic mode.

Note: it is envisioned that this requirement is satisfied at a minimum by displaying the start and

finish (end/cancel/abort) of a script. However, some scripts can and will include periodic status

messages to the Operator to inform them of key progress points in the script.


Requirement Origin: OCD (SPEC-0036).

4.2-0530 Observing Program elapsed time and time-to-complete

The OCS shall display the “time to complete” of all Observing Programs run in Automatic mode

and whose scripts include an estimated “total time for completion” metric included in the script.



4.2-0535 Telescope Mosaicking Support

The OCS shall support the execution of OP’s requiring telescope mosaicking.



2.3.2 Manual Operational Mode

4.2-0540 Manual Operational Mode Observing

The manual mode shall provide the operator with full control over all sub-systems the operator

has access to.

The manual mode shall be independent from an initial choice of Experiment or Observing

Program by the operator on startup. In particular, the OCS shall return to its default operational

mode after Observing Program execution has ended in the Automatic Mode regardless of the

completion status (successfully/unsuccessfully executed, aborted or cancelled).

The manual mode shall support the execution of Instrument Programs.

The manual mode shall support modifying and saving of Instrument Programs.

The manual mode shall support saving of data.

Any change back from the automatic mode into the manual mode shall be opaque to the

operator.


Requirement Origin: Engineering (SCR 2.2.5), Operations (OCD 6.2.4).

4.2-0550 Manual Operational Mode Systems Control

The OCS shall provide operational GUIs to control actions of the OCS itself, ICS, DHS, TCS,

and sub-systems of the TCS.

The control actions shall be those described in SPEC-0036.



Explanation: For example, the OCS shall provide the operator the capability of manually

controlling the position of PA&C mechanisms, focusing of M2 and selection of continuous or

random telescope movement patterns.

Note: It is expected that the functionality provided by operational GUIs that is derived from

functionality provided by sub-system Engineering GUIs.


Requirement Origin: Operations (OCD, 4.2.2, 8.2.6, 8.2.7).

4.2-0560 Manual Instrument Control

The OCS shall provide selectable operational GUIs for each instrument.

The OCS shall allow the operator to submit individual IP’s for execution on a per instrument

basis.

The OCS shall allow the operator to modify instrument programs and save those modifications

without impact on the host Observing Program, i.e. without changing the host Observing

Program including the Observing Program script.

The OCS shall allow the operator to select cancel or abort on a per instrument basis.

Note: Instruments adhering to the Facility Instrument Definition support these capabilities.

When they receive parameter sets distributed from the ICS tagged as manual, no action is taken

other than populating the instrument GUI with parameters. Instruments support submit, cancel,

and abort actions of instrument sequences (specified by unique parameter sets) and modifying

their associated parameters. The GUIs display the sequence of instrument actions (observation

steps) to be executed by the particular parameter set loaded from the chosen Observing Program.

The GUI supports the ability to submit parameter subsets to the instrument via the ICS that will

run a single observation step in the sequence. These parameter subsets may have Operator-

modifiable parameters within them, such as camera exposure time. The GUI supports adjusting

parameters for that sequence. Adjusted parameters do not take effect until explicitly submitted.

The GUI supports initiation of data saving while in manual mode. Data stored while in manual

mode will be stored with appropriate metadata and a default Experiment and Observing Program

Identifier (as in manual mode the OCS is independent from Experiments and Observing

Programs).

It is expected that these GUI capabilities are a proper subset of those actions available at the

instrument Engineering GUI. In other words, the Instrument GUIs provided by the OCS will

likely not include every parameter available to the Engineering GUI but will consist of an

intelligently specified subset of modifiable parameters within any given instrument parameter

set. The requirement to define this “intelligently specified” subset for any given Observing

Program parameter set is placed on the Instrument teams, not on the OCS.





2.3.3 Operator Tool Requirements

4.2-0580 Experiment Operations Tool

The OCS shall provide the Operator with an Experiment Operations Tool GUI that implements

the actions specified in 4.2-0500.



4.2-0590 Operator Telescope Control Tools

The OCS shall provide the Operator with the capability to acquire analog input that will be used

by the OCS to control TCS functions.

Using this input, the OCS shall be capable controlling the pointing functions of the Telescope,

the orientation of the,Coudé rotator, the selection of PA&C targets including artificial light

sources, and the Lyot stop and occulting devices. AO field steering mirror offset.



4.2-0600 Operator Target Selection Tool

The OCS shall provide a “target selection tool” that works with solar images to

Automatically display targets associated with a selected Observing Program as symbols

in the display, in the order (displayed) as identified from the Observing Program.

Reveal details associated with each target in a text display when selected by the Operator.

Allow the operator to redefine any information associated with a pre-existing target

(name, comments, etc.) by, e.g., right-clicking on the target and selecting a “Change”

function.

Allow the operator to redefine the solar location of an existing target either through a

click on a display or through driving the telescope to a location and selecting the current

coordinates.

Allow the operator to define new solar targets either through a click on a display or

through driving the telescope to a location and selecting the current coordinates.

Allow the operator to save redefined targets into the same database location as the

original – supplanting the original target for later observations or to save new targets into

new locations in the database.

Allow the Operator to select a pre-defined target from the table.

Allow the operator to change the details associated with a target

Support designation of targets by text entry of pre-defined solar coordinates.

Support non-solar pointing tools (e.g. a sky map) in the target selection tool.

Allow specification of a non-solar target by ephemerides.



Allow to associate Observing Program related targets with non-Observing Program

associated defined targets.

Allow the operator to define for any target the type of tracking to enable. For solar

observations the choices are (1) Fixed pointing at a specified heliographic point (Default)

or (2) solar differential rotation tracking. For non-solar observations the choices are (1)

sidereal rotation tracking (Default. Fixed Right Ascension/Declination/Epoch) or (2)

Fixed telescope pointing (az/el coordinates).

Allow the operator creating and modifying an ordered list of targets and associating it

with an Experiment Observing Program.

Support the ability for an executing Observing Program to enable the target selection tool

to edit defined targets and their properties.

Any changes made to a target or targets shall affect the currently selected Observing Program

only.


Requirement Origin: Engineering (SCR 2), Operations (OCD 6.2.3, 6.3).

4.2-0610 Target Selection Tool Image Data:

The OCS shall be capable of displaying solar image data available in World Coordinate System

format.

The OCS shall by default display live solar image data from the TAS.

The OCS shall support display of live images from the WCS context viewer.

The OCS shall support selection and retrieving solar images from approved remote internet

locations and displaying these images in the target selection tool.

The OCS shall be capable of extrapolating target positions to the current time.

The target selection tool display shall support Operator-selectable display of nominal instrument

fields of view and, if appropriate, nominal slit position.

The target selection tool shall annotate any defined target in live or still images with circles of 5

arc-minute and 2.8 arc-minute in diameter with the center of the circle at the pointing position of

the defined target.

The target selection tool shall be capable of taking operator input of heliographic coordinates in

both (x, y) arc seconds from disk center and in latitude/longitude format, and displaying a cursor

at that input position.

The target selection tool shall be capable of reporting the heliographic coordinates of an Operator

selected point on any solar image (with WCS information included) in both (x, y) arc seconds

from disk center and in latitude/longitude formats.

The OCS shall update target selection tool images at 5Hz or as available.

Description: Solar image data from other sources (such as satellite data, etc.) are desirable for

target selection. DKIST may work with providers of these images to ensure a compatible data

format. It is understood that the network bandwidth to external sources may be limited.




Requirement Origin: Engineering (SCR 2), Operations (OCD 6.2.3, 6.3)

4.2-0620 Adaptive Optics Lock Point Identification

When pointed to a defined target, the OCS shall provide as part of the target selection tool and

using the joystick, the ability to offset point in order to locate AO Lock Points.

When the current offset position is selected by the operator, the OCS shall associate this offset

with the defined target.

The operator shall be able to enable and disable AO lock from the Target Selection Tool.

The default lock points shall be the telescope pointing location for the defined target (bore-sight

of the WFC context viewer).

Description: Lock points can be defined in advance of an Experiment such as when the center of

the target pointing is desired. It is often the case that the selected targets on the day of an

experiment will be surveyed and the most appropriate locations within the field of view

identified as the AO lock points. It is understood that lock points may need adjustment during

execution of an Observing Program.


Requirement Origin: Engineering (SCR 2), Operations (OCD 6.2.3).

4.2-0630 Environment Monitoring

The OCS shall provide a GUI for displaying environmental conditions.

The environmental display GUI shall support a numerical and evolving graphical presentation of

current environmental measurements for monitoring including but not limited to:

Wind speed.

Wind direction.

Temperature.

Relative humidity.

Dew point.

Barometric pressure.

Light level.

Sky brightness.

Fried Parameter.

The environmental display shall update every 3 seconds or faster.

The evolving graphical presentations shall:

Plot any of the current environmental measurements versus UT time with an adapting X-

axis (default 2-hour span but user selectable up to 12 hours) to show the most detail

starting at the time the OCS display was opened.



Upon user selection automatically scale the Y-axis of the graphs to show the most detail.



2.3.4 Other OCS Program Execution Requirements

4.2-0640 Data Association

The OCS shall export metadata to the DHS as specified in the Data Model.


Requirement Origin: Operations (OCD 2.3.6), Engineering (Data Model).

4.2-0660 Remote Operations Building Capabilities

Staff at the Remote Operations Building shall be able to operate the OCS with all the capabilities

of the OCS at the summit.


Requirement Origin: Engineering (SCR 2), Operations (OCD 3.3).

4.2-0680 Multi-Instrument Operations

The OCS shall enable the operation of various post-focus instruments by simultaneously sending

scripts for all instruments participating in the experiment to the ICS upon a start signal being

received at the OCS.


Requirement Origin: Science (SRD 2.7), Engineering (SCR 2), Operations (OCD 2.2.1, 2.3.6)

4.2-0690 Synchronized Data Acquisition

Commands shall be submitted to cameras within 1 second of a start command being issued at the

OCS.

Note: The OCS, ICS, and ASI must coordinate to meet this requirement. There is no

requirement here for the camera to perform any activities.

Verification by: Test including OCS, ICS, and ASI.

Requirement Origin: Operations (OCD 2.2.1).

4.2-0700 Pacing Instruments

The OCS shall support specifying an instrument or instruments as pacing instruments.

The OCS shall submit this list of pacing instruments to the ICS at the time of execution of an

Observing Program.

Note: An Observing Program is not complete until those pacing instruments complete their

particular observations. The ICS is responsible for tracking completion of pacing instruments,

taking into account instrument faults.


Requirement Origin: Engineering (SCR 2), CEP.



4.2-0710 Non-Solar Targets

The OCS shall be able to execute Observing Programs for an Experiment that utilizes non-solar

targets.

Non-solar targets shall be specified by Right Ascension, Declination, and Epoch or any named

object supported by the TCS or by entering ephemeris data.

The OCS shall provide for non-solar targets the option of sidereal rotation tracking (Default) or

fixed telescope pointing (az/el coordinates).

Explanation: It is necessary to survey a list of stellar targets when characterizing telescope

pointing. Use of polarization standard stars for polarization calibration and the ability to move

from star to star while executing a calibration is appropriate for coronal polarimeters. It must be

possible to follow a planet as it approaches the solar limb within the solar field of view and

transits the solar disc while executing an Observing Program. Finally, fixed or sidereal rotation

pointing near the Sun (but outside the heat stop exclusion circle) may be useful in imaging Sun

grazing comets.



4.2-0720 Pointing Accuracy

The OCS shall support pointing offset updates by coordinating the actions of the Operator, TCS,

and WCCS. The OCS shall be capable of initiating collection of pointing offset data from the

WCCS Context Viewer upon user request, using the TCS to position the telescope. The accuracy

of the collected pointing offset data shall be sufficient to progressively achieve the required

telescope pointing accuracy listed in TMA SPEC-0010. The OCS shall perform the entire

pointing offset operation within two minutes under normal observing conditions.

Description: In order to maintain pointing accuracy without a guider, it will be necessary for the

Operator to periodically update pointing offsets between Observing Programs. At the current

time this will require the Operator to interact with the TCS and WCCS to iteratively arrive at the

correct offset. The OCS will point to various limb positions on the sun and request the WCCS to

perform a limb finding calculation. The results of these calculations will be stored in the TCS as

the new pointing offset. A pointing offset will be performed at the start of every day’s

observations, and then as required by the telescope’s pointing performance and the science

program.


Requirement Origin: Science (SRD 5.6).

4.2-0730 Data Tagging

The OCS shall tag data with:

OCS Operational Mode.

Test (yes/no).

TCS Passive (True/False) if Test was selected.





4.2-0740 Completion Assessment Support

The OCS shall provide the following information pertinent to the Observing Program to assess,

diagnose and determine completion of an Observing Program by Operations as early as directly

after Observing Program execution and Observing Program testing:

Associated Experiment ID under which the Observing Program was executed or tested.

Manual operator log entries pertinent to the Observing Program.

Operator changed parameters on a per instrument basis.

Observing Program and Instrument Program statuses.

Override information pertinent to the Observing Program.

Observing Program start time and end time.

Observing Program lapse time.

Observing Program percent complete.

Data save.

Manual and test.

TCS passive TRUE/FALSE.

Fried parameter during OP execution.

Note: Operations will perform a manual completion confirmation for each Observing Program

executed. In order to perform this confirmation as early as possible allowing for planning of the

next day possibly already in the afternoon of the current observing day, the information needed

to accomplish this task is required to be available as soon as possible and not just at the end of

the day with transfer of the summit database information.



2.4 OCS LOGGING REQUIREMENTS

The following requirements result in archiving of all entries needed for later generation of a daily

Operator Log (OCD 4.4).

4.2-1100 Triggered Log Entries

Upon notification or change of state the OCS shall archive and time tag the following

information:

Experiment ID, when selected by the operator.

Observing Program ID, when an Observing Program is executed by the operator.

Status information of Observing Programs.

Percent complete of Observing Programs.



Status information of Instrument Programs via the ICS.

Percent complete of Instrument Programs via the ICS.

Status information shall include but not limited to:

Successfully/unsuccessfully cancel.

Successfully/unsuccessfully abort.

Successfully/unsuccessfully execute.



4.2-1105 Periodic Log Entries

The OCS shall periodically log continuously changing items. Time-tagged entries include but are

not limited to

Environmental measurements as listed in 4.2.-0630.

Wavefront correction system Fried parameter.

External entries available as numeric values through a programmatic connection to the

internet including sky brightness.

Entries shall be archived at least every 3 seconds.

TCS entries shall be current to within one second.

Weather station entries shall be current to within 3 seconds.

External entries shall be current to within 3 seconds or as provided.



4.2-1110 Manual Log Entries

The OCS shall provide a tool for the operator to enter structured comments with a pre-defined

schema and vocabulary into the OCS Operator Log by comment type.

Comment types shall include: weather, solar conditions, operations, optical configuration, and

health.

The list of comment types shall be configuration controlled and easily expandable.



4.2-1120 Log Review

The OCS shall provide an Operator tool to review log entries listed in 4.2-1000 and 4.2-1005.


Requirement Origin: CEP.



2.5 STATUS REPORTING REQUIREMENTS

4.2-1200 Sub-system Status

The OCS shall support operational GUIs for monitoring and presenting the status of all DKIST

sub-systems controlled by the OCS.

OCS status shall be available for selection at all times.

The OCS shall provide for monitoring the status of multiple sub-systems simultaneously.

Note: It is expected that status GUIs are a proper subset of that provided by sub-system

Engineering GUIs.



2.6 SECURITY REQUIREMENTS

4.2-2000 Authorized Access

The OCS shall provide a mechanism to authenticate and authorize Operators.

The OCS shall log and report to summit databases the time-tagged authentication information.

Authorized Operators shall have access to all OCS command interfaces and operations.


Requirement Origin: Engineering (SCR 7), Operations (OCD 8).

4.2-2005 IT Infrastructure Reliance\

The OCS shall not implement security policies other than unauthorized access (Requirement

4.2-2000). The OCS shall rely upon the IT infrastructure for external security. Any external OCS

user has been authorized through the IT policies (e.g., VPN).


Requirement Origin: Engineering (SCR 7), Operations (OCD 8).

2.7 SAFETY REQUIREMENTS

2.8 VALIDATION

4.2-4000 Compliance Matrix

These requirements shall be listed and tracked via a compliance matrix.

Verification by: Design Review.


4.2-4010 Acceptance Test Plan and Procedure

The OCS shall develop an Acceptance Test Plan for showing conformance to these

specifications.

The OCS shall develop a procedure for executing the steps outlined in this plan.



Verification by: Review of the acceptance test plan and execution of the procedure.


Observatory Control System Specification · Steve Wampler, Bret Goodrich Software Group August 2016...

Documents

Transcript of Observatory Control System Specification · Steve Wampler, Bret Goodrich Software Group August 2016...