Acquisition Control System Design Requirement Document

Transcription

1 Project Documentation SPEC-0188 Rev A Acquisition Control System Design Requirement Document Bret Goodrich, David Morris HLSC Group November 2018 Released By: Name M. Warner Project Manager Date 28-Nov-2018

2 REVISION SUMMARY: 1. Date: October 2013 Revision: Draft 1 Changes: Created 2. Date: September 2017 Revision: Draft 2 Changes: Edits based on new discussions with scientist and engineers. Many new requirements and others edited for clarity. TAT SPEC requirements taken out, only ACS software specific requirements. Derived requirements updated. 3. Date: March-November 2018 Revision: Draft 3 Changes: Updated references to new Specification numbering and source documentation. 4. Date: 28 November 2018 Revision: A Changes: Initial formal release. SPEC-0188, Rev A Page ii

3 Table of Contents 1. INTRODUCTION DOCUMENT SCOPE RELATED DOCUMENTS VERIFICATION METHODS SOURCE OF SPECIFICATIONS DERIVED REQUIREMENTS SYSTEM OCS DHS TAS DISPLAYS OPERATION LIMITATIONS ACQUISITION CONTROL SYSTEM REQUIREMENTS GENERAL REQUIREMENTS HARDWARE REQUIREMENTS SIMULATOR REQUIREMENTS WORLD COORDINATE REQUIREMENTS ATTRIBUTES ACTIONS DISPLAY DATA INTERFACE REQUIREMENTS SPEC-0188, Rev A Page iii

4 1. INTRODUCTION 1.1 DOCUMENT SCOPE This document details all target acquisition requirements used to guide the design of the Acquisition Control System (ACS). The ACS is the software component of the Target Acquisition System (TAS), responsible for operating the camera and displaying images. 1.2 RELATED DOCUMENTS SPEC-0005, DKIST Software and Controls Requirements SPEC-0013, DKIST Software Operational Concepts Definition SPEC-0016, Data Handling System Specifications SPEC-0019, TCS Specifications SPEC-0036, Operational Concepts Definitions SPEC-0062, Target Acquisition System Specification TN-0213, World Coordinate Information and the DKIST Bulk Data Transport ICD-1.2/1.8.1, M1 Mirror Cell to Target Acquisition Telescope Interface ICD-1.8.2/4.4, Acquisition Control System to Telescope Control System Interface 1.3 VERIFICATION METHODS Included in each major numbered specification listed herein this document is a requirement verification method. These verification methods specify the minimum standards of verification required by AURA to ensure tha3t the individual requirements and specifications are met. All verification activities are the responsibility of the Contractor; i.e., the Contractor shall be solely responsible for providing any and all test equipment, analyses, inspections, and other means necessary to verify that the specifications and requirements have been met. Examples of verification methods include: Design Review. Verification by design review shall mean that the Contractor demonstrates to AURA during the appropriate design review that the equipment shall meet the specification by way of its intrinsic layout and configuration. Analysis. Verification by analysis shall mean that Contractor analytically demonstrates that the design meets the specification. Such analyses may include finite element methods, computation fluid analyses, closed form analyses, etc. All analyses shall be provided to AURA in written report form, in both electronic (e.g., MS Word) and paper copy format. Test. Verification by test and/or measurement shall mean that Contractor empirically demonstrates that the as-built equipment meets the specification. Testing may be required in the factory during factory acceptance testing and/or at the Site during Site acceptance testing. Inspection. Verification by inspection shall mean that the Contractor visually demonstrates to AURA personnel that the specification has been achieved on the as-built equipment during factory preassembly and/or during Site assembly. SPEC-0188, Rev A Page 1 of 12

5 At a minimum, the specification compliance matrix provided by Contractor as part of the Work shall be based on the verification method requirements. All analyses, test results (with calibration records) and other verification reports shall be provided to AURA in written report form, in both electronic (e.g., MS Word or Excel) and paper copy format. 1.4 SOURCE OF SPECIFICATIONS The source for all specifications may be Operations, or Engineering. Further references may also be given to specific DKIST documents or sections of documents. DKIST Systems Engineering tracks all specifications for source and references. The ACS Design Requirement Document is based on requirements stated in SPEC-0062, Target Acquisition System Specification. Operations requirements originate from SPEC-0036, ATST Operational Concepts Definitions. Engineering requirements originate from SPEC-0005, ATST Software Requirements and SPEC- 0013, ATST Software Concepts Definitions. SPEC-0188, Rev A Page 2 of 12

6 2. DERIVED REQUIREMENTS Derived requirements flow down from the top-level TAS requirements as found in the requirements for the TAS (SPEC-0062, TAS Specification). These originating requirements are based upon the scientific needs for the TAS as discovered from the Science Requirements (SRD, SPEC-0001), the operational needs as discovered from the Operational Concepts Definition (OCD, SPEC-0036), and the engineering needs as discovered from the Software Requirements (SPEC-0005) and the Software Operational Concepts Definitions (SOCD, SPEC-0013). 2.1 SYSTEM OCS The ACS shall provide images to the Observatory Control System (OCS) to be used for target selection, target adjustment, and AO lock point selection. These images shall be provided as required by the OCS design, as described in SPEC Specifically, the ACS shall provide images with the following characteristics: Data rate of 10 Hz; Image size of 2048 by 2048 pixels; DHS The TAS uses the Data Handling System (DHS) data transfer and display mechanisms. TAS images are available to the Observatory Control System (OCS) from the DHS Bulk Data Transport (BDT). Images retrieved by the OCS are used by the Operator for the solar target selection function of the OCS TAS The Target Acquisition System (TAS) consists of the Target Acquisition Telescope (TAT) and the Acquisition Control System (ACS). The TAS is used for (a) preliminary pointing selection of photospheric targets such as sunspots, pores, emerging flux and chromospheric targets such as filaments and prominences and (b) monitoring cloud passages. As such the TAT is a full-disk imager (telescope, filter, and camera) providing solar images for real-time display at a moderate spatial resolution of two arc seconds and a wavelength passband that shows both photospheric and chromospheric features. It is expected that the TAS and AO context viewer will be used in conjunction for identifying and pointing to solar targets. For example, the TAS will be used for coarse pointing the telescope to a sunspot while the AO context viewer, which has a significantly higher spatial resolution and a much smaller field-of-view, will be used to refine the pointing to its final value for science observations. 2.2 DISPLAYS ACS images are shown continuously on a dedicated display. A selectable intensity lookup table is used that can simultaneously emphasize both limb and disk features. For this capability a high dynamic range camera is required and the lookup table must operate on that full dynamic range. Displayed images include a marker indicating the center of main telescope pointing. There will be an expected offset between the center of the TAT image and the center of telescope pointing SPEC-0188, Rev A Page 3 of 12

7 since the TAT camera is positioned on the side of the main DKIST mirror. The telescope marker will give instant confirmation of the region being observed on this wide field display. This display may exceed the capability of the DHS Quality Assurance System, but remains the ACS requirement. Since the ACS uses the DHS for data transport a QAS Quick Look display is available for use. 2.3 OPERATION The ACS operates autonomously with no Operator intervention required for startup at the default frame rate, exposure, and display. It is possible for the Operator to adjust frame rate and exposure time via an engineering GUI displaying the relevant ACS parameters though this is not expected during routine operation. For ACS maintenance and engineering purposes, the Operator (or an engineer using the ACS Engineering GUI) can command the ACS to save a specified number of successive images. Such data are saved at full spatial resolution and bit depth. These images are for engineering purposes only, such as focusing the camera or initial tuning of the filter. During operations the ACS must not require any routine operator interaction. 2.4 LIMITATIONS The ACS is high level software dedicated to displaying the Sun for the telescope Operator -- it is not used for safety or for solar acquisition or pointing control by the Telescope Control System (TCS). SPEC-0188, Rev A Page 4 of 12

8 3. ACQUISITION CONTROL SYSTEM REQUIREMENTS 3.1 GENERAL REQUIREMENTS Scope The ACS shall comprise the software required to control and manage the TAS. This software includes the system controller, public control interface, and engineering GUI. The ACS shall include all computing hardware necessary to perform the required operations. Description: Camera control is an aspect of the system controller. Verification: Design Review, Inspection; Source: Engineering (SCD 2.2) Basic Requirements The ACS shall: Control the configuration and behavior of the ACS, Control the configuration and behavior of the TAT camera, Respond to commands through its common interface, Report status using the CSF facility provided for all subsystems of the DKIST. Verification: Design Review, Inspection; Source: Engineering (SCD 2.2) Best Software Practices The ACS shall conform to the DKIST software requirements. Under these requirements the ACS shall: Use the DKIST Common Services Framework for all communications, commands, events, logging, archiving, and database functions. Use the DKIST Common Services Framework to build Controllers. A controller is defined within the DKIST Common Services description in SPEC Each controller shall implement the functionality of the referenced system. Use the DKIST Common Services Framework to build the Connection and Channel to the filter thermal controller to read the status. Use the DKIST approved drivers to operate the Bobcat camera via GigE Vision. Use the Bulk Data Transport (BDT) to transmit data to the ACS display, OCS target selection tool, and to the DHS when the save flag is enabled. Use software libraries approved by DKIST for the implementation of ACS. Deliver documented source code, compiled object code, associated libraries, build and release code development environments, test software and fixtures, and any other materials necessary to edit, build, compile, link, load, run, test, and debug ACS. Deliver an ACS Users Manual, test plan/procedures document and compliance matrix. Use the High Level Software source code repository for all developed ACS software. SPEC-0188, Rev A Page 5 of 12

9 Description: General software requirements are defined in the Software and Controls Requirements document (SCR, SPEC-0005) 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. Verification: Design Review, Inspection, & Test; Source: Engineering (SCR 9) Health and Alarms The ACS shall report the health of systems under its control. The ACS shall display the health and alarms of systems under its control. The ACS shall log health and alarms of systems under its control. Description: The ACS will monitor its own controller health and the health of its camera. Source: SPEC HARDWARE REQUIREMENTS Computer The ACS shall provide a standalone computer to run the ACS. This computer shall contain: Three 1 Gb Ethernet ports (one for command, one for camera control, one for data) At least 32 GB memory Rackmount dual P/S Source: SPEC Installation The ACS shall install its computer in the Summit Computer Room. Source: SPEC Internet Connection The ACS shall have a dedicated internet connection to its camera. Source: SPEC-0062 SPEC-0188, Rev A Page 6 of 12

10 Serial Connection The ACS shall have a dedicated serial connection to the telescope filter thermal controller. Source: SPEC Monitor The ACS shall provide a 4K display for viewing the data from the TAT camera. Source: SPEC Display Computer The ACS shall provide a computer to run the 4K display. Source: SPEC SIMULATOR REQUIREMENTS Simulator The ACS shall support simulation of its functionality without need or use of any TAT hardware or camera system that contains: Data stream of one filled circle to represent the approximate size of the sun. Notation on the circle to show the cardinal directions of the sun. Shifted image based upon the position of the telescope mount. Rotated image based upon the position of the solar north pole from alt/az. Source: Engineering (SCR 9), SPEC WORLD COORDINATE REQUIREMENTS World Coordinate Information The ACS shall provide World Coordinate Information (WCI) included within the BDT header information as defined by the HLS WCI documentation. Comment: This information will include the position and rotation of the center beam line as seen by the TAT. Source: SPEC , Pointing Map The ACS shall store appropriate pointing map information to determine its WCI offset from the telescope position based upon the current telescope altitude and azimuth. SPEC-0188, Rev A Page 7 of 12

11 Comment: Information will be stored in an appropriate HLS lookup table in at least 5 degree increments and interpolated in between. Source: SPEC Pointing Map Operations The ACS shall be able to perform a pointing map operation in conjunction with the TCS. Source: SPEC TCS Information The ACS shall read the current position of the telescope and current solar rotation angle from the TCS as broadcast by the TCS status event. Source: SPEC ATTRIBUTES Default The ACS shall default to a pre-defined frame rate and exposure time upon startup. Description: The details of the pre-defined frame rate and exposure time will be determined during IT&C. Source: SPEC Data Storage The ACS shall support receipt on its common interface and setting the specification to store a single frame or a specified number of successive frames for engineering purposes. The ACS shall utilize the DHS for data storage. Source: SPEC Solar Pointing Display ACS shall provide the capability to superimpose upon images a marker indicating the current telescope pointing. Source: SPEC SPEC-0188, Rev A Page 8 of 12

12 3.6 ACTIONS Start The ACS shall commence camera operation with the current properties and attributes within one second of command reception from the OCS. Source: SPEC Cancel Upon reception of a Cancel command from the OCS, the ACS shall cease sending images to the BDT after the next complete exposure. Verification by: Test; Source: SPEC Abort Upon reception of an Abort command from the OCS, the ACS shall immediately cease sending images to the BDT. The current exposure may be lost. Verification by: Test; Source: SPEC Automatic Startup Following power up of the TAT and ACS, the ACS shall automatically enable the camera and start displaying camera images. Source: SPEC DISPLAY Image Display The ACS shall display images at rates up to 10 frames per second at 2048 by 2048 pixels. Source: SPEC Center Beam Location The ACS display shall mark the location of the telescope center beam line with a 5 arc-minute diameter circle. The ACS display shall mark the solar rotation on the image. Description: Solar rotation shall be marked by a compass overlay on the image that will rotate as the solar disk image rotates. Source: SPEC SPEC-0188, Rev A Page 9 of 12

13 Display Contrast The ACS display shall have the ability to adjust the contrast of the displayed image. Description: The ACS contrast shall implement both linear and non-linear contrast mappings (linear, logarithmic, power, and histogram equalization) Source: SPEC Display Update Rate The ACS shall allow for selectable update rates ranging from 0.1 to 10 Hz. Description: This display update rate is not the same as frame rate used by the camera. This controls how fast the displayed image is shown on screen. Source: SPEC DATA Intensity Calculation The ACS shall calculate the intensity value of the 5 arc-minute field of view before sending the data to the DHS and include the calculated value in the cstatus event, BDT metadata, and header database. Description: The intensity value will be calculated and posted to the header database for every image frame processed by the ACS. Source: SPEC Pixel Values The ACS shall calculate minimum and maximum pixel values of TAT camera images. Source: SPEC Data Reliability The ACS shall lose no more than 1% of the data it generates. Description: The ACS is responsible for publishing images via BDT. This data reliability pertains to the ability of the ACS to send a frame via the BDT. Source: SPEC Image Derotation SPEC-0188, Rev A Page 10 of 12

14 The ACS shall derotate the image captured by its camera such that solar north is always positioned at the top of the image. Description: This will be implemented as an upgrade once the system is installed and operational. The image must be derotated so that north is always at the top of the image to match images from other sources such as GONG and SDO. Source: SPEC Image Derotation Publisher The ACS shall publish the derotated solar image at a rate of 5 Hz on a dedicated BDT stream. Description: This BDT stream is different from the BDT stream running at 10 Hz that provides the raw images for the ACS Main display. Source: SPEC INTERFACE REQUIREMENTS Common Services Framework The ACS shall use the DKIST Common Services Framework for the implementation of its software structure and common interface. Description: The Common Services Framework defines three levels of implementation: (a) the containers and container managers that ACS components shall operate within; (b) the components and controllers that ACS shall implement to meet specification; and (c) the services ACS shall employ to interact with the DKIST software system. A description of the Common Services can be found in SPEC-0022, DKIST Common Services Users Manual. Verification by: Design Review; Source: Engineering (SCR 9) Engineering User Interface The ACS shall supply an engineering user interface for controlling and monitoring its behavior. The engineering user interface shall support the public TCS-ACS interface. The engineering user interface shall be capable of exercising all the functionality of TAS. The ACS engineering user interface shall include, at a minimum, the following features: A tool to support generation of camera commands with their parameters. The ability to specify, store, retrieve, and load camera specific setup parameters. The ability to specify storage of TAT camera images via BDT. The ability to monitor any TAT filter environmental characteristics such as temperature or voltage states. Verification by: Inspection, Test; Source: Engineering (SCR 9), SPEC SPEC-0188, Rev A Page 11 of 12

15 Operations User Interface The ACS shall supply an operator user interface for monitoring its behavior. Verification by: Inspection, Test; Source: SPEC Camera Interface The ACS shall support setting the following parameters through its camera interface: Frame Rate, Exposure Time, Read Status. Source: SPEC Serial Interface The ACS shall support reading the following parameters through its serial interface: Filter temperature and/or status. Source: SPEC BDT Interface The ACS shall support publishing the following data through its BDT interface: Raw camera data at 2048 by 2048 pixels, Image metadata. Comment: Image metadata described within Source: SPEC BDT Metadata The ACS shall write the following metadata through its BDT interface: WCI information, Image size and pixel depth, Start/End time of exposure, Exposure time, Frame rate, Filter status, Location of telescope mount, Rotation of solar image, Average intensity value Source: SPEC-0062 SPEC-0188, Rev A Page 12 of 12