atst ecs software design description · enclosure design services for the advanced technology solar...

Enclosure Design Services for the Advanced Technology Solar Telescope (ATST)

Enclosure Control System Software Design Description

IDOM Doc. N.: 15812-SPEC-076 Issue: 5.1 Date: August 9th 2013

Contract No: C22019N

Name Signature Date

Written Alastair Borrowman

Aug. 9th 2013

Revised Lander de Bilbao

Aug. 9th 2013

Project Manager Gaizka Murga

Aug. 9th 2013

Principal Tom Lorentz

Aug. 9th 2013

File: 15812-SPEC-076-5_1_ECS_SDD Pages: 115

15812-SPEC-076-5_1_ECS_SDD; August 9th 2013 2/115

CHANGE RECORD

Issue Date Affected Paragraph(s) Reason/Initiation/Remarks

1 March 25th 2011 First issue of document for Enclosure PDR.

2 December 15th 2011 All Enclosure FDR issue of document.

3 January 27th 2012 Enclosure FDR RIX responses added.

4.2 ECS Deployment Diagram

RIX #166 – add information about spec. of PC required by ECS. RIX #167 – add more information about how ECS shall obtain time from CSF. RIX #168 – add information about the JES screens being stateless. RIX #169 – add references to individual requirements of SPEC-0082. (Done not only in this section but throughout document.)

4.5 Overall Use of ATST Common Service Framework

RIX #170 – add information regarding Linux, Java and CSF versions/releases to be used during ECS development. RIX #171 – correct reference to reference TN-0088.

5.2 Relationship with TCS

RIX #172 – add information about latency. RIX #173 – add information about difference of cPos and cStatus event contents.

5.3 Relationship with EMCS

RIX #174 – add reference to document section containing information about connections opened to EMCS PLC. RIX #175 – add information regarding source of ECS cPos data.

6.4.7 Submit RIX #176 – replace list of submit response codes with reference to CSF Users’ Manual.

6.6 ATST Base Technical Architecture Blocks

RIX #177 – simplify the information about use of TABs to better explain how they are used in the ECS.

6.7 ECS Controllers RIX #178 – specify that the aux controller is only responsible for monitoring the status of the TEOA access platform not the complete TEOA.


6.10 Health and 6.11 Alarms

RIX #181 – add sentence to each section describing the difference between what will cause health to go ill/bad and what will cause an alarm to be raised. In section 6.10 Health add description of health categories to be used.

6.11 Alarms RIX #183 – remove reference to zenith blind spot alarm. RIX #184 – add TCS trajectory loss alarm. RIX #185 – add miss-matched modes alarm. RIX #193 – add TCS trajectory produces position out of mechanism range alarm.

6.13 Engineering Screens

RIX #186 – add examples of the maintenance procedures that it will be possible to carry out using the engineering screens.

6.14.1 ECS and EMCS Tracking Modes

RIX #187 – add information about the attributes accepted/rejected when in active and tracking modes.

6.14.2 Tracking Control RIX #188 – add information that all tunable parameters used in the switching between EMCS tracking modes shall be stored in the property DB. RIX #189 – add information about EMCS actions if communication is lost to ECS while tracking.

6.14.4 Change of ECS Mode to Tracking

RIX #190 & #191 – improve description of use of track identifier and its relationship with the setting of the inPosition status.

6.16 Hardware Limits RIX #192 – add information regarding moving out of axis limit.

7.6 Use Case: TCS Receives New Target

RIX #194 – updated Use-Case to include information about behavior when TCS trajectory and configuration .trackIds do not match.

7.8 Use Case: Interlock Event

RIX #195 – add information regarding ECS behavior if enclosure interlock occurs but it is not notified of active interlock by the GIS.

8.2 PLC Tag Information in the Property DB

RIX #196 – add more information and give examples of controllers using properties described.

4 February 8th 2013 All Enclosure Control System Beta release issue of document.

5 June 28th 2013 All Enclosure Control System Final release issue of document.


5.1 August 9th 2013 1 Scope Update to reference ECS Final release version 1.1.

6.4.10 Cancel Update to align with cancel behavior requested at ECS FAT and implemented in ECS release 1.1.

6.11 Alarms In point #7 add details of ECS_Mode_Mismatch health category.

7.2 Use Case: Startup In steps 7 and 8 add description of EMCS controller's duties to obtain Enclosure to ECS ICD version in use by the EMCS PMC and set the EMCS PLC's clock time.

7.10 Use Case: Stow Tracking Mechanisms

In step 1 update configuration attributes to use atst.tcs.ecs.[alt,az].namedPos not atst.tcs.ecs.namedPos, which is no longer an attribute of the TCS to ECS ICD.

8.5.1 abplc Connection Classes and Interfaces

In Figure 18 update the ABPlcioConnectionEmcs class to include the methods used to get and set the EMCS PLC clock time.


ABBREVIATIONS Acronyms and abbreviations of terms used in the ECS are described below, for a more complete list as used by ATST see [RD 3]. AD Applicable Document API Application Programming Interface ATST Advanced Technology Solar Telescope CIP Common Industrial Protocol CLX ControlLogix CM Container Manager (part of ATST CSF software) CSF Common Services Framework DB Database ECS Enclosure Control System EMCS Enclosure Mechanical Control System F-ATP Factory Acceptance Tests Plan FDR Final Design Review FOV Field of View FTCS Facility Thermal Control System GIS Global Interlock System GUI Graphical User Interface HMI Human Machine Interface ICD Interface Configuration Document JES Java Engineering Screens JNI Java Native Interfaces LIC Local Interlock Controller NAN Not-A-Number OCS Observatory Control System PAC Programmable Automation Controller PDR Preliminary Design Review RD Reference Document RDSA Reference Design Studies and Analysis PLC Programmable Logical Controller SDD Software Design Description SOW Statement of Work TAB Technical Architecture Block TAI Temps Atomique International TBD To Be Decided TCS Telescope Control System TEOA Top End Optical Assembly TMA Telescope Mount Assembly UML Unified Modeling Language VEMCS Virtual EMCS


GLOSSARY Glossary of terms used in the ECS are described below, for a more complete list as used by ATST see [RD 3]. Component vs. Controller – in the ATST CSF the software items component and controller are closely related. Controllers have configuration-management features, that is, configurations can be submitted to controllers using the submit command, whereas components do not accept configurations, see CSF User’s Manual [AD 9] for more information. The ECS uses only controllers. Ethernet vs. EtherNet/IP – in this document Ethernet is used to refer to the network link layer commonly used to deliver TCP/IP, and EtherNet/IP is used to refer to the network application layer protocol used by Allen-Bradley PLCs to communicate CIP over Ethernet networks. Package – in relation to software the term package is used in this document to refer to a collection of software classes that are designed to perform a cohesive and logically grouped set of actions, and are therefore grouped together in a package. Where the packages described in this document are implemented using Java the package name directly relates to Java packages contained in the final software implementation. Package diagram – following the definition used in the UML Distilled [RD 15]; the term package diagram [is used] for a diagram that shows packages of classes and the dependencies among them. PLC vs. PAC – the acronym PAC is becoming the preferred (by Rockwell Automation) reference for the hardware device previously referred to as a PLC. This is due to the desire to differentiate between the old style logic controllers and the new, more complex and capable controllers, of which the ControlLogix family of controllers is an example. In this document PLC and PAC will be used interchangeably but with preference for PLC.


TABLE OF CONTENTS

1 SCOPE ........................................................................................................................................ 11

2 APPLICABLE AND REFERENCE DOCUMENTS ................................................................ 12

2.1 APPLICABLE DOCUMENTS .....................................................................................................................................12

2.2 REFERENCE DOCUMENTS .....................................................................................................................................12

3 INTRODUCTION ..................................................................................................................... 14

4 SYSTEM OVERVIEW ................................................................................................................ 15

4.1 INTRODUCTION ......................................................................................................................................................15

4.2 ECS DEPLOYMENT DIAGRAM .............................................................................................................................18

4.3 IMPLEMENTATION LANGUAGE ............................................................................................................................19

4.4 SOURCE CODE ........................................................................................................................................................20

4.5 OVERALL USE OF ATST COMMON SERVICE FRAMEWORK ...........................................................................20

5 SYSTEM CONTEXT ................................................................................................................. 21

5.1 CONTEXT DIAGRAM ..............................................................................................................................................21

5.2 RELATIONSHIP WITH TCS ....................................................................................................................................22

5.3 RELATIONSHIP WITH EMCS ................................................................................................................................23

5.4 RELATIONSHIP WITH GIS .....................................................................................................................................23

6 SYSTEM DESIGN..................................................................................................................... 24

6.1 CONFIGURATIONS ..................................................................................................................................................24

6.2 EVENTS ....................................................................................................................................................................26

6.3 THE CONTROLLER MODEL ..................................................................................................................................26

6.4 CONTROLLER LIFECYCLE AND COMMANDS .....................................................................................................27 6.4.1 Load ......................................................................................................................................................................27 6.4.2 Init ........................................................................................................................................................................28 6.4.3 Startup ..................................................................................................................................................................28 6.4.4 Shutdown ...............................................................................................................................................................28 6.4.5 Uninit ....................................................................................................................................................................29 6.4.6 Remove ..................................................................................................................................................................29 6.4.7 Submit ...................................................................................................................................................................29 6.4.8 Pause .....................................................................................................................................................................29 6.4.9 Resume ..................................................................................................................................................................29 6.4.10 Cancel ...............................................................................................................................................................30 6.4.11 Abort ...............................................................................................................................................................30 6.4.12 Get ...................................................................................................................................................................30 6.4.13 Set ....................................................................................................................................................................30

6.5 ATST BASE CONTROLLERS ..................................................................................................................................30

6.6 ATST BASE TECHNICAL ARCHITECTURE BLOCKS ..........................................................................................31

6.7 ECS CONTROLLERS ...............................................................................................................................................31


6.8 PROPERTIES .............................................................................................................................................................33

6.9 DEFAULT STATE .....................................................................................................................................................33

6.10 HEALTH....................................................................................................................................................................33

6.11 ALARMS ....................................................................................................................................................................34

6.12 LOGGING .................................................................................................................................................................35 6.12.1 Status Messages ................................................................................................................................................35 6.12.2 Debug Messages ................................................................................................................................................35

6.13 ENGINEERING SCREENS .......................................................................................................................................35

6.14 CONTROLLING DEVICES THAT TRACK .............................................................................................................36 6.14.1 ECS and EMCS Tracking Modes ..................................................................................................................36 6.14.2 Tracking Control ..............................................................................................................................................39 6.14.3 ECS Tracking States and ATST Configuration States ...................................................................................40 6.14.4 Change of ECS Mode to Tracking ...................................................................................................................41 6.14.5 Change of Track Identifier ................................................................................................................................42

6.15 POSITION FEEDBACK FOR THE TCS ...............................................................................................................42

6.16 HARDWARE LIMITS ................................................................................................................................................43

6.17 ECS FAILURE MODES ...........................................................................................................................................43 6.17.1 Responding to Invalid Data ..............................................................................................................................43 6.17.2 Responding to Invalid Trajectory Data ..............................................................................................................43 6.17.3 Internal Failures ...............................................................................................................................................44 6.17.4 Failures of EMCS ...........................................................................................................................................44 6.17.5 Inconsistent EMCS to ECS Interface ..............................................................................................................44

7 USE CASES ................................................................................................................................ 45

7.1 USE CASE: INITIALIZING THE ECS .....................................................................................................................47

7.2 USE CASE: STARTUP ...............................................................................................................................................48

7.3 USE CASE: START TRACKING ...............................................................................................................................50

7.4 USE CASE: TRACKING ...........................................................................................................................................52

7.5 USE CASE: START OBSERVING .............................................................................................................................54

7.6 USE CASE: TCS RECEIVES NEW TARGET ..........................................................................................................55

7.7 USE CASE: ZENITH BLIND SPOT .........................................................................................................................57

7.8 USE CASE: INTERLOCK EVENT............................................................................................................................59

7.9 USE CASE: STOP OBSERVING ...............................................................................................................................61

7.10 USE CASE: STOW TRACKING MECHANISMS ......................................................................................................62

7.11 USE CASE: STOP TRACKING MECHANISMS .......................................................................................................63

7.12 USE CASE: SHUTDOWN .........................................................................................................................................64

7.13 ENGINEERING USE CASES .............................................................................................................................65 7.13.1 Engineering Use Case: Move to Fixed Position ................................................................................................67 7.13.2 Engineering Use Case: Offsetting Position.........................................................................................................69 7.13.3 Engineering Use Case: Constant Velocity Move ...............................................................................................71 7.13.4 Engineering Use Case: Move to EMCS Limit .................................................................................................73 7.13.5 Engineering Use Case: Calibrate Enclosure Tracking Mechanisms...................................................................75


8 DETAILED DESIGN ............................................................................................................... 77

8.1 EMCS TO ECS COMMUNICATION ......................................................................................................................77 8.1.1 PLCIO .................................................................................................................................................................78

8.2 PLC TAG INFORMATION IN THE PROPERTY DB .............................................................................................79

8.3 THE PLC TAG CLASS ..............................................................................................................................................80

8.4 ENSURING CORRECT ICD VERSION IN USE .....................................................................................................81

8.5 PACKAGE ABPLC: IMPLEMENTING THE CONNECTION BASED HARDWARE COMMUNICATION

APPROACH BETWEEN THE ECS AND EMCS USING JNI ..............................................................................................82 8.5.1 abplc Connection Classes and Interfaces..................................................................................................................82 8.5.2 abplc JNI ..............................................................................................................................................................86

8.6 PACKAGE ECS ..........................................................................................................................................................87 8.6.1 Management Controller atst.tcs.ecs .........................................................................................................................89 8.6.2 Tracking Sub-Controllers atst.tcs.ecs.az and atst.tcs.ecs.alt .....................................................................................89 8.6.3 Sub-controller atst.tcs.ecs.aux .................................................................................................................................90 8.6.4 Sub-controller atst.tcs.ecs.cover ................................................................................................................................91 8.6.5 Sub-controller atst.tcs.ecs.emcs .................................................................................................................................91

8.7 OVERVIEW OF ECS USE OF ABPLC TO COMMUNICATE WITH EMCS ........................................................91

9 SEQUENCE DIAGRAMS ......................................................................................................... 94

9.1 ECS SUB-CONTROLLERS USE OF ABPLC TO OPEN CONNECTIONS TO THE EMCS PLC .......................94

9.2 ECS CONTROLLERS USE OF ABPLC TO READ HARDWARE STATUS AND CURRENT POSITION .............95

9.3 ECS TRACKING SUB-CONTROLLERS CONTROL OF ENCLOSURE TRACKING MECHANISMS ....................97

9.4 ECS TRACKING SUB-CONTROLLERS ACTIONS WHEN TCS RECEIVES A NEW TARGET ..........................98

9.5 ECS COMMANDS ENCLOSURE HARDWARE, E.G. MOVING APERTURE COVER ........................................99

9.6 ECS ENTERING AND LEAVING THE ZENITH BLINDSPOT .......................................................................... 100

9.7 ECS CONTROLLER ACTIONS WHEN INTERLOCK BECOMES ACTIVE ........................................................ 101

9.8 ECS TRACKING SUB-CONTROLLER MOVE TO NAMED POSITION ............................................................ 102

9.9 ECS TRACKING SUB-CONTROLLER MOVE AT CONSTANT VELOCITY ..................................................... 103

10 ECS JAVA ENGINEERING SCREENS ................................................................................. 105

11 SIMULATION .......................................................................................................................... 106

11.1 THE VIRTUAL EMCS .......................................................................................................................................... 106 11.1.1 Design and Implementation of the VEMCS PLCIO Module ...................................................................... 107 11.1.2 Design and Implementation of the VEMCS CSF Java Controllers .............................................................. 109 11.1.3 VEMCS Support for User Interactions and ECS Testing ........................................................................... 110

11.2 TCS SIMULATION REQUIRED BY THE ECS .................................................................................................... 110

11.3 GIS SIMULATION REQUIRED BY THE ECS .................................................................................................... 111

12 TESTING ................................................................................................................................. 112

13 COMPLIANCE MATRIX ........................................................................................................ 113


This page intentionally left blank.


1 S C OP E

The software described by this design is the ATST Enclosure Control System, which is one of the Telescope Control System (TCS) sub-systems. It is referred to throughout this and other ATST documentation as the Enclosure Control System or more usually by its acronym ECS. The ECS is bounded by the TCS to ECS ICD 4.4/5.6 [AD 3] and EMCS to ECS ICD 5.0/5.6 [AD 4]. The ECS also receives interlock information from the GIS as described in the OCS to GIS ICD 4.2/4.5 [AD 5]. The TCS, EMCS and GIS are outside the scope of this document but will be described as far as is required to fully describe the ECS design. The purpose of the ECS is to control, on behalf of the TCS, the operation of the enclosure mechanical assemblies including position of the azimuth carousel and altitude shutter to track the sun during observations. It comprises of all software required to operate the Enclosure Mechanical Control System (EMCS), but does not include hardware or firmware of the EMCS. The scope of the ECS is specified as requirement 5.6-0010 in the ECS Specification SPEC-0082 [AD 1]. The ECS design does not make explicit reference to the Carousel Entrance Aperture Plate. At this stage of the enclosure development it is highly likely that the aperture plate will not be a moving mechanism and so require no direct control by the ECS. Therefore, to ensure the ECS design and documentation is kept as concise as possible to the likely enclosure design, the aperture plate control software is not included here. However, if required, the aperture plate control would be achieved using the same design as used for the other tracking mechanisms, namely the azimuth carousel and altitude shutter. Throughout this document, these mechanisms are referred to as tracking mechanisms, and if required the aperture plate will be added to their number. This fulfills requirement 5.6-0430 of the ECS Specification SPEC-0082 [AD 1], which states “If a carousel entrance aperture plate is used…”. The ECS is not responsible for thermal control inside the enclosure building; this is the responsibility of the Facility Thermal Control System (FTCS). This version of the document has been prepared in unison with the software Final release (version 1.1, post FAT release) and describes the ECS as-built design. Where the as-built ECS does not match design details described in previous versions of this document this is highlighted in the text using italics.


2 AP P LI C AB LE AND R E F E R E NC E D OC U M E NT S

2.1 APPLICABLE DOCUMENTS

Title Reference Iss. Date

AD 1 Enclosure Control System Specifications SPEC-0082 B 25 Aug 2010

AD 2 SOW ECS Amendment to Enclosure Contract – A 24 Aug 2010

AD 3 ICD 4.4/5.6 TCS to ECS ICD-4.4/5.6 H 17 Jan 2013

AD 4 ICD 5.0/5.6 Enclosure to ECS ICD-5.0/5.6 7 13 Jun 2013

AD 5 ICD 4.2/4.5 OCS to GIS ICD-4.2/4.5 – –

AD 6 ECS Operations & Maintenance Manual 15812-MAN-074-5_1

5.1 9 Aug 2013

AD 7 ECS Factory and Site Acceptance Test Plan 15812-TRE- 075-5_1

5.1 9 Aug 2013

AD 8 EMCS Functional Description 15812-TRE-079 FDR 15 Dec 2011

AD 9 Common Services Framework User’s Manual SPEC-0022-1 G Dec 2012

AD 10 Common Services Framework Reference Guide SPEC-0022-2 G Dec 2012

AD 11 Base Software for Control Systems TN-0088 D 3 Jan 2013

AD 12 Enclosure Maintenance Plan 15812-PLA-086 FDR 27 Jan 2012

2.2 REFERENCE DOCUMENTS


RD 1 Science Requirements SPEC-0001 B 12 Dec 2005

RD 2 Software Design Requirements SPEC-0005 B 21 Apr 2009

RD 3 ATST Glossary and Acronym List SPEC-0012 H Mar 2011

RD 4 Software Concepts Definitions SPEC-0013 B 22 Apr 2009

RD 5 ATST Software Design Document SPEC-0014 B 23 Apr 2009



RD 6 TCS Software Design Description SPEC-0021 G 28 Feb 2013

RD 7 TCS Software Operations Manual – F 28 Feb 2013

RD 8 Operational Concepts Definitions SPEC-0036 C Jul 2010

RD 9 Alt-Az Zenith Blind Spot and the ATST TN-0003 B 18 Aug 2006

RD 10 Enclosure Error Budget TN-0043 D 8 Dec 2009

RD 11 RDSA Document for the ATST Enclosure TN-0045 Draft 2 17 Dec 2009

RD 12 Java Engineering Screens User Manual TN-0089 B 10 Jan 2013

RD 13 ECS to EMCS Communication 15812-TRE-47 1 27 Jan 2011

RD 14 ECS to EMCS Communication Test 15812-TRE-58 2 12 Aug 2011

RD 15 UML Distilled 2nd Edition by Martin Fowler ISBN 0-201-65783-X

– 2000

RD 16 Programming ControlLogix Programmable Automation Controllers, by Jon Stenerson

ISBN-13:978-1-4354-1947-6

– 2009

RD 17 PLCIO version 4.3.0 User Manual and API, pdf file available from http://www.ctiplcio.com/doc_pdf.html

– 11_027 Jan 2011


3 I NTROD U C T I ON

This document describes the design of the software that constitutes the ATST Enclosure Control System (ECS), how it interfaces to the other systems of the ATST control system and how the requirements expressed in the ATST ECS Specification (SPEC-0082 [AD 1]) are met. Specifically requirement 5.6-2000 states a Software Design Document (SDD) must be provided. The intended audiences of this document are:

The reviewers of the ECS Final Design.

The developers of the ECS work package. The layout of this document is as follows: Section 4 provides an overview of the ECS, it describes what the ECS is and how it is structured and deployed. Section 5 sets the ECS in context with the other systems which it must interact with to fulfill its requirements. Section 6 details how the ECS is built using the ATST Common Services Framework (CSF), and how the CSF is utilized to provide ECS functionality. Section 7 contains the use cases of the ECS, describing how the ECS design handles various scenarios, functional behavior, and other typical use case interactions. Section 8 contains the detailed design of the ECS, it describes the ECS packages and the classes contained in them, and how they are implemented to provide the required ECS behavior. Sequence diagrams showing how the software described in the detailed design accomplishes the described use cases are contained in section 9. Following this section 10 contains details of the ECS engineering screens. Section 11 describes the ECS/EMCS simulator and section 12 discusses ECS testing; however tests are defined in a separate document [AD 7]. Finally, section 13 contains the ECS Compliance Matrix that cross-references how the design described in this document meets the requirements of the ECS specified in SPEC-0082 [AD 1].


4 S Y S TE M OV E RV I E W

4.1 INTRODUCTION

In the ATST software architecture the ECS is one of the TCS subsystems. The TCS has responsibility for delivery of the telescope light feed from the light’s entrance into the enclosure, through telescope optics to the instrument focal plane. To ensure the enclosure has no impact on passage of the light feed to telescope optics, the TCS sends to the ECS trajectory data for positioning of enclosure’s tracking mechanisms (e.g. azimuth carousel and altitude shutter). It is the responsibility of the ECS to accept the trajectory data and correctly transfer it to the enclosure hardware by communicating with the Enclosure Mechanical Control System (EMCS) in a correct and timely fashion. The ECS must also react to notification of an enclosure interlock from the Global Interlock System (GIS) that it receives via the Observatory Control System (OCS). When notified of an interlock the ECS must place the interlocked enclosure hardware into the default state. The ECS is not part of the safety critical interlock system and so does not have responsibility for protection of personal or hardware, but it must behave appropriately when an interlock is raised and throughout its duration, i.e. send to the EMCS request to set corresponding hardware into default state and not accept requests (commands) to move the hardware. To accomplish its responsibilities the ECS uses the ATST Common Services Framework (CSF). All communication with systems outside the ECS (e.g. the TCS) uses facilities provided by the CSF. Moreover, all ECS housekeeping, e.g. health and alarm notification, logging, etc, uses the provided CSF services. As a user of CSF the ECS application runs on a PC installed with the CentOS Linux distribution and packages as specified by the CSF [AD 10]. During operations the ECS controls all enclosure hardware operations through its connection with the EMCS. The ECS is connected to the EMCS over a dedicated Ethernet link. The EMCS runs on a PLC connected to the enclosure hardware and accepts demands to move the hardware from the ECS and returns status to the ECS. Therefore the outline of the primary role of the ECS is:

Place enclosure hardware in suitable state for operations.

Accept tracking mechanism trajectory streams from the TCS.

Forward trajectory streams in agreed format at agreed frequency to the EMCS.

React appropriately when notified of an enclosure interlock.

Receive enclosure status from the EMCS and publish this for use by TCS and other interested systems, e.g. engineering GUIs.

Before looking in detail at how the ECS software performs these functions an overview of the structure of the ECS, in relation to the infrastructure software it must be built with, is shown in the CSF and ECS package overview diagram in Figure 1. For a full description of the infrastructure software contained in the CSF see [RD 5].


Figure 1 Package Diagram – CSF and ECS package overview

The CSF package at the centre-right of the diagram contains the classes the ECS is built from. This includes the CSF classes and the ATST application base classes. The ATST application base is a suite of support software that extends the ATST Common Services beyond the technical architecture. The application base includes controllers that provide generally useful functional behavior that is not specific to a particular ATST system. All ECS controller classes are sub-classed from one of the base classes. The CSF package also contains the Container Manager (CM) classes that are responsible for the deployment and lifecycle of the ECS. The GUI and ECS packages depend on the CSF package. There is also a dependency of the CSF package on the database (DB) package. The databases maintained inside the DB package provide all permanent storage (including logs) required by the ECS. There are clearly defined interfaces in the DB package provided by the CSF package and the ECS utilizes these in the form of CSF classes. At the same level as the CSF package is the GUI package. The GUI package contains the Java Engineering Screens (JES) package. The JES is an extension of the CSF Component class that can be used to graphically layout an engineering user interface using the Java Swing widget set. Once designed, the screens can be activated such that they connect to other components as well as register for events.


This allows configurations to be submitted as well as status to be displayed. Full details of the JES and how it can be used are found in [RD 12]. The CM is used to load, initialize and startup the various components of the ECS. Depending on how it is configured, this can be done automatically or step by step. The manager is flexible enough that it can startup any container of the overall ATST control system and then load and initialize any components into these containers. The selection of containers and components is done graphically. Together, the JES and CM provide the interactive control of the ECS for observatory operations. The CM also provides a service that enables automatic booting of containers when the ECS computer hardware is powered-on or rebooted. This ensures that the ECS will be operational and ready to receive input within 5 minutes of a cold (from power-off) start of its computer hardware as required in the ECS specifications SPEC-0082 5.6-1005 [AD 1]. The main ECS package ecs is shown in the lower right of the diagram with its classes and controllers:

Alt is the class implementing the altitude shutter controller atst.tcs.ecs.alt.

Aux is the class implementing the auxiliary equipment controller atst.tcs.ecs.aux..

Az is the class implementing the azimuth carousel controller atst.tcs.ecs.az.

Cover is the class implementing the aperture cover controller atst.tcs.ecs.cover.

Ecs is the class implementing the top level ECS management controller atst.tcs.ecs.

Emcs is the class implementing the EMCS controller atst.tcs.ecs.emcs.

TrackingMech is an abstract class containing the common behavior of the tracking mechanism controller classes (e.g. atst.ecs.Alt and atst.ecs.Az), ensuring software is not duplicated across all tracking controller classes.

Also shown in the ECS package is its sub-package abplc that contains all classes used to implement the connection software to the EMCS Allen-Bradley PLC. This includes the CSF based connection class ABPlcioConnection. The ecs and abplc packages are fully described in section 8 Detailed Design. The ECS package sub-package vemcs contains all the classes of the Virtual EMCS software, which implements the EMCS simulator used by the ECS when the real EMCS and enclosure hardware are not available. This is fully described in section 11 Simulation. Communications between TCS and ECS takes the form of CSF configurations and events. Configurations are handled by the ecs package; specifically the atst.tcs.ecs controller. The configurations take the form of a set of attribute-value pairs that the ECS matches by adjusting itself and/or its sub-controllers to match the received values; this may or may not involve the requirement to move enclosure hardware. If enclosure hardware is to be moved then a configuration is sent to the atst.tcs.ecs sub-controller responsible for the hardware, with attributes and values describing the necessary hardware demands. Each hardware sub-controller has its own connection object to provide its connection to the EMCS, using the CSF connection based communication approach as implemented in the ABPlcioConnection and its derived classes. Using its connection class the controller writes data to and reads data from the EMCS PLC to control and monitor the enclosure hardware. Trajectory data to position enclosure tracking mechanisms is received from the TCS as CSF events. The connection objects of the tracking sub-controllers (e.g. atst.tcs.ecs.az and atst.tcs.ecs.alt) are configured to subscribe to the TCS trajectory event and write the data to the EMCS so that the hardware follows the demanded trajectory. The ECS also receives interlock notification from a CSF


event it subscribes to that is published by the OCS. The OCS receives interlock information from the GIS.

4.2 ECS DEPLOYMENT DIAGRAM

The ECS deployment diagram in Figure 2 shows the hardware on which the various software controllers of the ECS are deployed. In the ATST CSF software controllers are deployed (run) inside software containers. A container can run a number of controllers but a container can only run controllers implemented in one computing language. All ECS controllers are implemented in Java and therefore there is one ECS Java container in which all ECS controllers run.

Figure 2 ECS Deployment Diagram

The ECS uses a Linux 64 bit PC. The ECS does not place any requirements on the type of PC required above those expected by any other ATST systems running CSF applications. Therefore an example


specification for running the ECS is an Intel Core i7 processor with 8GB of RAM, dual GbE LAN, with 500GB HDD. The use of Ethernet on the control LAN is requirement 5.6-1230 of the ECS Specification SPEC-0082 [AD 1]. The ECS dedicates one of its network interfaces for communications with the EMCS, and the second for all other network communications, including ECS to TCS. The physical location of the ECS PC is defined in the Enclosure to ECS ICD 5.0/5.6 [AD 4]. As the ECS design makes extensive use of the CSF, and is of a size (in number of CSF components) that places no greater burden on computer resources than other ATST systems, the expectation is very high that the use of such a machine (as specified above) ensures the ECS uses less computer resources as specified in requirement 5.6-1020 of the ECS Specification SPEC-0082 [AD 1]. To evaluate the TCS target trajectory stream received from the TCS (see TCS to ECS ICD 4.4/56 [AD 3] and section 6.14 of this document) the ECS requires access to the current time as TAI. The ECS obtains TAI from CSF using the getCurrentTAITime() method of atst.cs.services.Time.java and therefore any additional hardware or connections required for this method to obtain accurate time are required by the ECS PC. The use of TAI is stated in requirement 5.6-1305 of the ECS Specification SPEC-0082 [AD 1]. The EMCS PLC is an Allen-Bradley 1756 ControlLogix, supplied by Rockwell Automation. Its connection to the ECS over Ethernet is via an Allan-Bradley 1756-EN2T EtherNet 10-100M Interface Module, connected to the PLC using the PLC’s backplane. Only the ECS container, its controllers, CSF connection software and associated JES screens are supplied as part of the ECS. All other systems/services are utilized by the ECS but are provided as either part of the ATST CSF or TCS. The CSF server runs on a separate dedicated Linux PC. The permanent data storage (PostgreSQL database) is also maintained on this machine. The ECS engineering interfaces are written in Java (using JES) and communicates with the ECS using the ATST CSF. Multiple engineering interfaces can be run concurrently (if required), as JES screens are stateless and contain no specific information in themselves, the diagram shows two such instances running on two separate Linux PCs. The engineering interface running on a separate machine is not a requirement and it could run on the same machine as the ECS, in fact the interface can be run on any machine supporting the Java ATST CSF. The ECS is expected to be robust and run continuously. Its normal operational state is Running i.e. it will have executed its init and startup functionality. It is only shut down for engineering purposes and not, for example, at the end of each observing day. If the ECS is shut down it will return all system resources to the operating system (i.e. there will be no memory leaks, unreturned buffers, blocked TCP sockets, etc). Shutting down the ECS causes the ECS to shut down any of the hardware systems it is connected to, by placing them in a default state (e.g. power off, brakes on, aperture cover closed, etc.), as specified in SPEC-0082 5.6-0050 [AD 1]. The ECS assumes that all communications within its running environment are secure; it does not implement any firewall, encryption or password access. All security considerations are expected to be dealt with by the ATST CSF and the observatory wide computer systems.

4.3 IMPLEMENTATION LANGUAGE

As previously mentioned all ECS controllers and associated software are implemented in Java. However, the library selected to provide communication with the EMCS PLC is written in C. Calls to


this library are made from Java using Java Native Interface (JNI) C code. The C code provides a wrapper enabling calls and return of data to and from the PLC C communications library in Java. Java is used as the language of choice as previous prototyping carried out using Java containers and controllers, has demonstrated there is no compelling reason to write CSF applications in C++. In fact some of the base classes (including specialized management controllers) are only supported in Java, and it is therefore desirable to use Java in the ECS controllers to utilize the functionality already provided [RD 6].

4.4 SOURCE CODE

All source code used by and implemented as part of the ECS contract is provided. As the code has been developed it has been committed to the CVS repository in Tucson. At the various ECS delivery stages the code constituting the delivery has been tagged in the repository; using this tag the code of the delivery can be extracted and reviewed. All implemented source code is documented in a manner consistent with good software practices, using tools such as Javadoc and doxygen. All implemented source files shall contain a header including the version number, revisions, author(s), and functional description. All functions within a source file shall have a description of the interface and operation of the function, and shall be clearly commented. In this way the ECS fulfills the requirement 5.6-0030 Best Software Practices of the ECS Specification SPEC-0082 [AD 1]. The source files of the ECS as-built Final release do not contain a header detailing version number and revision, however all other documentation requirements are fulfilled.

4.5 OVERALL USE OF ATST COMMON SERVICE FRAMEWORK

The ECS, as one of the systems of the ATST, must work seamlessly with the other systems that make up the overall ATST control system. In particular it must accept and act on configurations sent by the TCS. To accomplish this, the ECS is built using the ATST CSF which in turn constrains its design (see [AD 9] and [AD 10]). Providing such a software interface, which conforms to the ATST interface of the CSF, is requirement 5.6-1210 of the ECS Specification SPEC-0082 [AD 1]. ECS development has been done using the currently approved ATST Linux distribution and version number (CentOS 6) and Java release (7), together with the current CSF release of both common services and base (Canary 5.2). At the highest level the ECS consists of one CSF Java container. The ECS container holds a number of controllers that are initialized and started by the container manager via the init and startup command methods (see section 6.4). During this phase the ECS controllers attempt to make connections to the other ATST components with which they need to communicate and retrieve their initial state from the runtime database through the use of the property service. All workers of the system are implemented as ATST controllers (sub-classing from atst.base.hardwareController) providing the command/action/response behavior needed to handle the submit of configurations. Details of the controller model in general and the particular controllers and components that are sub-classed by the ECS can be found in the Base Software for Control Systems TN-0088 [AD 11].


5 S Y S TE M C ONTE XT

This section describes the ECS in its context with other systems of the ATST that it must communicate with to do its job. Here is described what the ECS must do; the details of how this is achieved are described in subsequent sections of this document. The ECS context is bounded by the TCS and EMCS. The TCS is the higher-level system (in respect to its closer proximity to higher-level observatory operations) from which the ECS accepts configurations. The EMCS is the lower-level system (in respect to its closer proximity to lower-level enclosure hardware operations) that the ECS communicates with to position enclosure hardware and receive hardware status information. The ECS also receives information from the GIS that is the observatory wide interlock system that generates all safety-critical events.

5.1 CONTEXT DIAGRAM

The ECS context diagram is shown in Figure 3. The node at the top of the diagram represents the TCS, the configuration and event interface used between TCS and ECS is defined in the ICD 4.4/5.6 [AD 3]. The node at the bottom of the diagram represents the EMCS, as the EMCS is not a CSF application the ECS does not communicate with it using configurations and events but using the specified format as defined in ICD 5.0/5.6 [AD 4]. The other system to which the ECS must subscribe for events is the GIS, shown as node to the left of ECS. Information from the GIS is made available through the OCS and this is defined in the ICD 4.2/4.5 [AD 5]. Interacting with the GIS is requirement 5.6-1220 of the ECS Specification SPEC-0082 [AD 1].


Figure 3 ECS Context Diagram

5.2 RELATIONSHIP WITH TCS

The relationship between TCS and ECS is defined in the ICD 4.4/5.6 [AD 3]. The ECS must accept configurations defined, and subscribe to and generate the specified events of this ICD, as specified in requirement 5.6-1200 of the ECS Specification SPEC-0082 [AD 1]. Configurations contain the current mode required of enclosure tracking e.g. off, active or tracking, and other parameters used to define how the enclosure hardware is to be moved. The principle event subscribed to by the ECS, generated by the TCS, is the trajectory event. This event is generated at 20 Hz and contains the trajectory data used to position the tracking mechanisms. The ECS communicates this data to the EMCS at the same rate that it is received from the TCS. The latency between arrival of TCS trajectory in ECS and it communicating the demand positions to the EMCS is expected to be minimal, but to ensure this is the case the ECS monitors the time taken between trajectory arrival and sending of the demand, if this takes longer than a configurable amount of time (as read from property in property DB) an alarm is raised. The current status of the enclosure is broadcast on events atst.tcs.ecs.cPos and atst.tcs.ecs.cStatus that the TCS, and any other interested systems, subscribe to. Attributes contained in the cPos status event


relate to the current enclosure position. Attributes contained in the cStatus event relate to the current status of the ECS and include the Boolean inPosition attribute, which is set true when the ECS is tracking and all its tracking axes are maintaining their position within specified tolerances. The reporting of status information is requirement 5.6-0210 of the ECS Specification SPEC-0082 [AD 1].

5.3 RELATIONSHIP WITH EMCS

The relationship between EMCS and ECS is defined in the ICD 5.0/5.6 [AD 4]. This ICD does not define the interface in terms of configurations and events, as in the TCS to ECS ICD, because the EMCS is not a CSF application. The EMCS runs on an Allen-Bradley 1756 ControlLogix PLC. The ICD defines communications between ECS and EMCS using the ControlLogix tag data format used by the PLC’s programs. The ECS commands the EMCS to move enclosure hardware by writing to the PLC tags relating to the hardware to be controlled. Status data is retrieved from the EMCS by reading PLC tags. For example, trajectory data received by the ECS, from TCS trajectory event, is written to the EMCS using the defined tag for positioning tracking hardware, e.g. azimuth carousel and altitude shutter. The current position of the hardware is retrieved by the ECS reading the corresponding PLC tag, which is then broadcast as a status event (cPos) as defined in TCS to ECS ICD [AD 3]. The ECS cPos event contains data the ECS management controller receives from its tracking sub-controllers by subscribing to their individual cPos events; the management controller amalgamates all the individual cPos event data into one overall ECS cPos event containing the current position data of all enclosure axes. The ECS opens and closes connections to the EMCS PLC as and when required to do the above, details about the number of connections are contained in section 8.7 of this document.

5.4 RELATIONSHIP WITH GIS

The ECS subscribes to the enclosure interlock notification event from the Global Interlock System (GIS) that is published by the OCS. The ECS itself plays no part in servicing the interlock or protecting personnel or hardware. The event received by the ECS contains attributes that communicate the overall enclosure interlock status, and whether one or more of the movable enclosure mechanisms are individually interlocked. The ECS is required to react to an enclosure interlock condition by placing itself into a suitably safe configuration (the default state, see section 6.9) and remaining in this condition until notification from the GIS that the interlock is cleared. This is requirement 5.6-3000 of the ECS Specification SPEC-0082 [AD 1]. If the interlock relates to a single enclosure mechanism then only the ECS controller responsible for the mechanism places itself into the interlocked state. The interface used between GIS and ECS is described in the overall GIS ICD contained in the OCS to GIS ICD 4.2/4.5 [AD 5].


6 S Y S TE M D E SI G N

This section describes the system design of the ECS and in particular its use of the ATST CSF. The ECS design is constrained by the need to interact seamlessly with the rest of the ATST systems and to use the CSF in its operations [AD 1]. The first subsections of this section therefore recap and summarize the CSF design with regard to the use of configurations, and in particular the controller model. Subsection 6.7 then describes the controller model as applied to the ECS. Subsequent subsections then describe other operations of the ECS that rely heavily on the CSF.

6.1 CONFIGURATIONS

Configurations lie at the heart of the ATST CSF. Configurations consist of a list of attributes and values that the system receiving the configuration must match. The matching of the configuration’s attributes to the system’s attributes is done by CSF controllers. The internal configuration of a controller can be set up by issuing a series of set commands (see section 6.4.13) or more usually by sending a complete configuration with a submit command (see section 6.4.7). A configuration is a specialized form of an AttributeTable class that also contains a unique configuration ID and header. The proper use of configuration identifiers (IDs) is requirement 5.6-1250 of the ECS Specification SPEC-0082 [AD 1]. An AttributeTable consists of a collection of Attribute objects each of which has a name and value. Internally an Attribute value is stored as a string representation of the actual value, and so multiple attributes of different types can be stored in the same AttributeTable. Configurations go through a set of states during their lifecycle as illustrated in Figure 4. The state is set by the controller depending on which command the controller receives relating to the configuration. The controller also sets the state when the action relating to the configuration completes (either successfully or unsuccessfully). The commands are Submit, Cancel, Abort, Pause and Resume. The completion possibilities are Done, Cancelled or Aborted. A configuration is submitted to a controller using the submit() method. The controller then performs a quick check of the attributes in the configuration to make sure the attributes are valid. The controller then passes the attributes to the doSubmit() method to make sure that the combination of attributes make a valid configuration. If the attributes do make a valid configuration the configuration is scheduled, and the submit method returns OK. The acceptance or rejection of a command occurs within 0.1 seconds; this is requirement 5.6-1000 of the ECS Specification SPEC-0082 [AD 1]. If the configuration is not valid the submit method returns with a problem code (see section 6.4.7). When the configuration’s action starting time is reached (the default is for immediate execution) then the doCanRun() method is called, providing a hook for final checking that the configuration can be executed at the current time. If the doCanRun() method returns true then the doSerialAction() method is called followed by the starting of an action thread. The action thread calls the doAction() method that does the required work to match the component attributes to those of the configuration. ECS requirement 5.6-1010 of the ECS Specification SPEC-0082 [AD 1] states the time taken to apply changes due to external information received in a configuration or event is 0.1 seconds. Once the work is completed the method and action thread complete. Three events are usually generated for a configuration action:

An event is generated when the action is scheduled.


Another event is generated when the action is started.

A final event is generated when the action completes. Configurations can also be Paused, Resumed, Cancelled and Aborted, which lead to additional events being generated. The ECS is configured (using property atst.tcs.ecs.prac) to not respond to Pause and Resume commands as they are not appropriate for enclosure hardware operations.

Figure 4 Configuration States

When a configuration is cancelled using the Cancel command or aborted using the Abort command, the ECS takes the following actions:

1. If the configuration is queued then it is removed from the queue and an abort event sent for it. This behavior is provided by the CSF.


2. If the configuration is running then the action thread propagates the cancel or abort command to all the sub-controllers involved in the configuration and then aborts and destroys the configuration. The propagation of cancel/abort commands is handled automatically when using the Base ManagementController. Action threads must check for the abort status at regular intervals and then enforce the abort by terminating their thread.

6.2 EVENTS

As well as providing configurations that can be sent from one controller to another, the CSF also provides events that can be used to signal changes of state or status. Although both configurations and events can be used to pass data between controllers, they do so by different mechanisms. Configurations require there to be a connection maintained between the two communicating controllers. Events on the other hand use a publish-subscribe mechanism. The source of the data publishes it and then any number of clients can subscribe. The publisher does not care how many, or who the subscribers are, and there is no permanent connection between the two. If a publisher is not present then a subscriber receives no events until the publisher is started. In the CSF the data sent with events is encoded as an attribute table, i.e. the same data format used in configurations. Arbitrary amounts of data can therefore be sent as an event; all a subscriber needs to know is the name of the event so that it can register (subscribe) to receive it. Events are used internally by the CSF to signal the matching of configurations and are used extensively by the ECS to report status, and also to receive the TCS trajectory stream for positioning of tracking mechanisms. To ensure the status of ECS items that change in a non-periodic or low frequency fashion are readily available to other systems as events, these items, e.g. position of the aperture cover, are published by controllers in a cStatus event. Every ECS controller publishes a cStatus event containing its current status. The contents (attributes) of the cStatus event of each controller and the frequency they must be published are defined in the TCS to ECS ICD [AD 3].

6.3 THE CONTROLLER MODEL

An ATST CSF Controller implements the command/action/response model. In this model commands are separated from the actions they trigger. In this way many commands may be sent to a controller resulting in many simultaneous actions, and in particular a controller is not blocked whilst waiting for a previous command/action to complete. In the CSF commands are passed to controllers as configurations; the configuration’s attributes describe the command in the form of values that must be matched by the controller for the command to complete. On receipt of a configuration describing the command’s values, the controller sends an immediate response to the sender saying whether the attributes sent with the configuration are accepted or rejected (within 0.1 seconds [AD 1]). It then queues the configuration for either immediate or later action. Once queued, the controller is ready to accept another command contained in another configuration. The actions started by configurations are handled by separate threads under the control of an action manager. Configuration actions can complete as either Done, Cancelled or Aborted. Normal completion for a configuration action is Done, but if an error occurs then it will be Aborted. This response is advertised by the posting of a configuration action status event, which is automatically monitored by the CSF. Controllers can attach a callback to perform processing on receipt of the


action’s status event, if no further processing is required the callback can be null. The action status event’s name is prefixed with the name of the controller posting the event, as is the name of the attribute containing the event’s status value. The event name is made up of this prefix and the text status. For example, if the controller atst.tcs.ecs posts an action status event, the name of this event is atst.tcs.ecs.status and this matches the name of the action status attribute containing the event’s value. Controllers accept a configuration as a parameter in the submit command. It is important for the ECS to distinguish between the completion of an action and the state of an underlying piece of hardware. A CSF configuration action is in the Running state until it is Done, Cancelled or Aborted. This may or may not coincide with an underlying piece of hardware being physically stationary or not. For example, if the aperture cover is moved from the closed to open position, when the hardware reaches the open position a signal must be sent to the action thread to tell the configuration it is Done. In this case the hardware device stopping coincides with the configuration being Done. However, in the case of slewing the azimuth carousel to begin a new track, the action is Done when the carousel first matches the position and velocity tolerances. The mechanism continues to track (move) and it would be incorrect to consider the configuration as still Running because of this. Instead the configuration is considered Done when the carousel is moving within specified tolerances for carousel alignment. The availability of the ECS to accept and reject commands is requirement 5.6-0090 of the ECS Specification SPEC-0082 [AD 1].

6.4 CONTROLLER LIFECYCLE AND COMMANDS

During processing an ATST CSF controller moves through a well defined lifecycle, see Figure 5.

Figure 5 ATST CSF Controller Lifecycle

To trigger a transition between controller lifecycle states the commands Load, Init, Startup, Shutdown, Uninit and Remove are used, these are described below in sections 6.4.1 to 6.4.6. For configuration operations a controller provides the commands Submit, Pause, Resume and Cancel, see sections 6.4.7 to 6.4.10. For low-level access to individual and groups of attributes, the commands Get and Set are provided, these are described in sections 6.4.12 and 6.4.13 respectively.

6.4.1 Load

This is not a command to the controller itself but the action of a container (or container manager) that loads the controller from disk. This creates the controller by invoking the controller’s default constructor, which places it in the Loaded state. During transition from Unknown to Loaded state none of the CSF services are available to the controller. For this reason a controller should do very little at load time and so constructors are kept to an absolute minimum. The ideal constructor is empty. Once loaded the controller is connected to the CSF. A controller executes no functional behavior nor allocates any resources in this state. Controllers responsible for hardware control do not attempt to connect to it or move it in the Loaded state.


6.4.2 Init

Initialization is the process of preparing a controller for operation, but stops short of starting that operation. Typical steps taken during initialization include:

1. Metadata about the controller’s attributes are loaded. 2. Any special memory needs (fixed buffers, memory maps, etc.) are satisfied.

The first of these is performed automatically by the CSF. The latter is an action based upon the functional behavior required of the controller and so is done by the individual controller. A controller always reaches the Initialized state as a result of an init command. This is guaranteed by the CSF. If an error occurs during the initialization actions the controller sets its health to BAD or ILL and raises one or more alarms depending on the severity of the failure. No connections to hardware are made during initialization or while in the Initialized state.

6.4.3 Startup

Once in the Initialized state the startup command is used to progress to the Running state. The Running state is the state for operational use. Only in the Running state is the controller able to accept the submitting of configurations, checking they are valid and queuing them for action. Whether the controller actually acts on a submitted configuration depends on whether any errors were encountered on reaching the Initialized and then Running state. It may be that due to problems some or all configurations will be rejected. During startup controllers responsible for hardware make connection to hardware and read back its status. Controllers demand their hardware into the default (.e.g. power off, brakes applied) state at startup, this may or may not result in hardware movement depending upon the state of the enclosure hardware when ECS startup occurs. Reaching the Running state is a necessary condition for a controller to be operational but for some controllers it may not be fully sufficient. For example, a controller responsible for a tracking mechanism does not begin tracking operations until specifically told to do so by the submitting of a configuration. The startup and restart of the ECS operates in a manner that fulfills requirement 5.6-0060 Restart of the ECS Specification SPEC-0082 [AD 1].

6.4.4 Shutdown

Shutdown is essentially the reverse process of startup; any actions undertaken as part of startup are undone during the processing of the shutdown command, e.g. close hardware connections. Once shutdown has completed the component state returns to the Initialized state and its capabilities must reflect this. Whilst in the Running state the controller may have executed many configurations that leave mechanisms active, these are halted as part of the shutdown as all controllers demand their hardware to the default state on receipt of the shutdown command. For example if the azimuth carousel is tracking it is stopped, motors powered down, and brakes applied. Besides restarting the component, using the startup command, the only other operation available on an Initialized component is the un-initialization of the component using the uninit command.


6.4.5 Uninit

This command is the reverse of init and undoes any actions that resulted from init command processing. As a result of the uninit command the controller returns back to the Loaded state as if it had just been loaded from disk.

6.4.6 Remove

As with the load command, the remove command is not a command to the controller itself but rather an action of the container (or container manager). The action of remove is to remove the controller’s instance from memory.

6.4.7 Submit

Once a controller is in the Running state it is ready to act on any configurations sent to it. Configurations are sent using the submit command. On receipt of a submit command the controller verifies that the configuration is valid. Once the verification is complete, the command thread queues the configuration and signals the action manager. At this point a response is returned to the external source of the command. The response is an integer representing the result of the submission (see the CSF Users’ Manual for details [AD 9]). Within the ECS validation consists of a number of stages:

1. The name of the attribute is checked to ensure it is a valid attribute name. If any attribute name is not a valid ECS attribute name then the configuration is rejected with return value BAD_PARAM. The alternative of simply ignoring invalid attribute names could lead to a situation where a complex configuration is submitted with one of the attribute names spelt incorrectly. The user might not notice that the configuration had been accepted but with one attribute discarded in the process.

2. The value of the attribute is range checked. Range checking is provided through the CSF (property database) and is done by the CSF submit() method (see 6.1). If the value is out of range then the whole configuration is rejected with the return value BAD_PARAM.

3. Conflict checking. This is a check that the configuration as sent contains no conflicting demands and is done in the component’s doSubmit() method (see 6.1). For example setting the altitude shutter to off and also setting the position would conflict as the enclosure would simultaneously be asked to move the shutter and to power it off. The configuration is rejected with return value INCONSISTENT_PARAM.

If all validation checks are passed then the configuration is handed to an action thread for execution and the OK value is returned from the submit command.

6.4.8 Pause

The ECS does not respond to this command due to the inability to pauses hardware actions; they can be stopped but not paused. The ECS uses the CSF PRAC support to provide this behavior (see [AD 11]).

6.4.9 Resume

As detailed in the previous section the ECS does not respond to the pause command and so does not respond to the resume command.


6.4.10 Cancel

The cancel command removes a configuration from the queue if it has not yet been started. If the configuration is already active then an abort signal is sent to the action thread and the configuration is destroyed. In the ECS the cancel command cancels an action’s ongoing monitoring of hardware status, used to determine if the hardware state of the submitted configuration has been matched, thus causing it to complete before this or a timeout has occurred. If the configuration being cancelled contains the .mode attribute with value active or tracking the cancel causes the ECS to adopt the .mode equal to active with tracking controllers demanded to actively hold their current position (e.g. the same behavior as achieved when a configuration is submitted containing only .mode=active). A user wishing to stop hardware movement should at all times submit a configuration demanding hardware to stop. Any currently ongoing actions do not have to be cancelled before this is done as when a new configuration action begins any ongoing action is automatically cancelled, as only one action can be demanding hardware at any one time. Likewise, if a user simply wants to adjust or modify the currently ongoing action then a new configuration should be submitted containing the hardware setting now required.

6.4.11 Abort

The abort command functions in the same manner as the cancel command but completes with action response Aborted.

6.4.12 Get

This is a low-level command that can be issued to a controller once the controller is in the Initialized state; it does not have to be Running for this command to be accepted. The get command can be used to fetch the value of any attributes from the current internal configuration of the controller.

6.4.13 Set

This is a low-level command that can be issued to a controller once the controller is in the Initialized state; it does not have to be Running for this command to be accepted. The set command can be used to set the value of attributes of the current internal configuration of the controller. These values are overridden if they are subsequently specified in a configuration that is submitted to the controller for execution using the submit command.

6.5 ATST BASE CONTROLLERS

The ATST application base is a suite of software that extends the ATST CSF beyond the technical architecture. The application base includes controllers that provide generally useful functional behavior that is not specific to a particular ATST system. Details of controllers contained in base can be found in [AD 11]. ECS controllers are implemented by extending the following base controllers:

atst.base.management.action.ManagementController

atst.base.hardware.HardwareController


6.6 ATST BASE TECHNICAL ARCHITECTURE BLOCKS

Technical Architecture Blocks (TABs) are used to add technical code to a controller. A large portion of the code in many of a controller’s methods is bookkeeping and error checking that needs to be done regardless of other operations. TABs are standalone objects that have some close relation to a controller and are constructed in the controller’s namespace, i.e. TABs belonging to one controller cannot interfere or corrupt another controller’s TABs. The purpose of TABs is to remove the necessity to duplicate code that duplicates operations across different controllers. The only duplicated code is registering the TAB with the superclass. Since TABs are standalone and are iterated through, there is no fear of overriding methods from a superclass and forgetting to call the superclass’s method. Since TABs are standalone objects they can be mixed and matched as needed and there are no issues with multiple inheritances. Since each TAB only has to do one thing it makes it easier to track down bugs, and modify behavior; bug fixes and modifications are made once in the TAB not in every component using the TAB. For more information see the CSF Reference Guide [AD 10]. The ECS uses the PropertyTAB and LifecycleTAB as the ECS controllers are extended from CSF controllers that use these tabs. In addition the ECS controllers make direct use of the PostingTAB. The PostingTAB continually posts information from a controller that implements the IPoster interface. It is configured using properties to setup its event channel name and posting rate. It can also be enabled and disabled. This TAB simplifies the posting of regular attribute tables from controllers by taking care of setting up the task, managing the timing of the task and ensuring it is created at init, started at startup, stopped at shutdown and destroyed at uninit. Each ECS controller uses a PostingTAB to post its cStatus event, and if applicable its cPos event.

6.7 ECS CONTROLLERS

The ATST controller model imposes a strict hierarchy on the control flow through the ATST control system. This means that any attribute destined for a sub-controller must pass through a parent and so the name of the attribute maps directly on to the controller hierarchy. For example the attribute atst.tcs.ecs.az.mode may be sent from the TCS to the top-level ECS MangementController atst.tcs.ecs, which in turn will forward the attribute to the atst.tcs.ecs.az sub-controller. This is handled automatically as the top-level ECS MangementController is implemented as an extension of the CSF base ManagementController class that provides this functionality. A controller in the hierarchy may intercept an attribute and as a result generate its own configuration. This occurs in the top-level ECS ManagementController, allowing multiple subsystem mode changes by issuing just a few (or maybe one) attributes. An example of this is the atst.tcs.ecs.mode attribute; when the top-level ECS controller receives this attribute in a configuration it generates new configurations containing mode attributes for its tracking sub-controllers, e.g. atst.tcs.ecs.az.mode and atst.tcs.ecs.alt.mode. Whenever new configurations are generated they are done so using the original configuration as a starting point. This ensures the configuration ID is preserved (appended to) and consequently all configurations can be traced from the originally received configuration. The use of configuration identifiers in this manner fulfills requirement 5.6-1250 Configuration Identifiers of the ECS Specification SPEC-0082 [AD 1].


The ECS controller hierarchy is shown in Figure 6. This shows that all configurations flow through the atst.tcs.ecs ManagementController. The hierarchy and names used to identify the controllers are defined in the TCS to ECS ICD [AD 3].

Figure 6 ECS Controller Hierarchy

The roles of the ECS controllers are defined as follows:

atst.tcs.ecs – this is the top-level controller of the ECS and is implemented using the class atst.ecs.Ecs that extends atst.base.management.action.ManagementController. It manages the lifecycle of all other ECS components and all configurations for the ECS pass through this controller.

atst.tcs.ecs.alt – this is implemented using the class atst.ecs.Alt that extends the abstract atst.ecs.TrackingMech class. This controller has responsibility for all operations of the altitude shutter including monitoring its cable wrap using the tension sensor enclosure hardware (monitoring of cable wraps is requirement 5.6-0410 of the ECS Specification SPEC-0082 [AD 1]).

atst.tcs.ecs.az – this is implemented using the class atst.ecs.Az that extends the abstract atst.ecs.TrackingMech class. This controller has responsibility for all operations of the azimuth carousel including monitoring its cable wrap using the tension sensor enclosure hardware (monitoring of cable wraps is requirement 5.6-0410 of the ECS Specification SPEC-0082 [AD 1]).

atst.tcs.ecs.cover – this is implemented using the class atst.ecs.Cover that extends atst.base.hardware.HardwareController. This controller has responsibility for all operations of the aperture cover. Control and monitoring of the entrance aperture cover is requirement 5.6-0420 of the ECS Specification SPEC-0082 [AD 1].

atst.tcs.ecs.aux – this is implemented using the class atst.ecs.Aux that extends atst.base.hardware.HardwareController. It has responsibility for monitoring of all enclosure auxiliary equipment (bridge crane, jib crane, Top End Optical Assembly (TEOA) access platform and lights) and control and monitoring of the calibration camera. The monitoring of dome cranes is requirement 5.6-0400 of the ECS Specification SPEC-0082 [AD 1].

atst.tcs.ecs.emcs – this is implemented using the class atst..ecs.Emcs that extends atst.base.hardware.HardwareController. This controller is responsible for configuring and monitoring status of the EMCS PLC. N.B. Unlike the other ECS controllers this controller is not part of the TCS to ECS ICD. The ECS operates this controller for necessary house-keeping purposes; no system outside the ECS requires to communicate with it.


Using the above controllers the ECS fulfills requirement 5.6-0040 Control of the ECS Specification SPEC-0082 [AD 1].

6.8 PROPERTIES

The property service maintains metadata about attributes in a persistent store (property DB). It provides a mechanism that allows controllers access to this metadata as application-specific attributes. An example of its use is the automatic range checking of attributes submitted to a controller within a configuration. If a property exists for an attribute present in a configuration, when the configuration is submitted the attribute’s value is range-checked as is its read-only value, and the submission is rejected if these checks fail, e.g. if the value is out of range and/or the value is read-only. This is provided as standard in the CSF and the ECS complements this functionality with additional use of the property service. In particular the ECS uses the property service to store saved values for many of its attributes. These saved values can then be restored after a reboot to bring the ECS straight back into a fully operational state. The saved values include (but are not limited to):

1. Current software and hardware limit values 2. The last recorded set of defined named positions.

The ECS also uses the property DB to store all EMCS PLC tag information required to enable communication with the EMCS. The PLC tag information required is detailed in the EMCS to ECS ICD [AD 4]. The use of the property service ensures persistence of data between restarts of the ECS; this is requirement 5.6-0095 of the ECS Specification SPEC-0082 [AD 1].

6.9 DEFAULT STATE

All enclosure hardware has a defined default state (requirement 5.6-0050 of SPEC-0082 [AD 1]). The default state of all hardware is an inert, non-moving, non-powered condition. The ECS ensures all hardware is demanded into this state on startup, shutdown or occurrence of an interlock condition. The startup command always asserts the default hardware state and may be used at any time to re-assert the default state. The default state of all enclosure hardware is stored alongside the EMCS PLC tags used to control the hardware in the property DB (see section 8.2). Every PLC tag used to control enclosure hardware, has the possibility of having an associated default value, and is defined together with the tag in the EMCS to ECS ICD [AD 4].

6.10 HEALTH

Every controller within the ECS uses the CSF Health.set() method to set its health. If any conditions indicating poor health are recognized the component’s health is set to ILL or BAD, as appropriate, via a call to the Health.set() method, giving an informative reason. If no reasons for poor health are found then the health is set to GOOD. The requirement to determine health is contained in SPEC-0082 5.6-0070 [AD 1].


For details of health categories used by the ECS and the criteria for determining the current health see the ECS Operations & Maintenance Manual [AD 6], section ECS Health.

6.11 ALARMS

The CSF alarm service provides a facility for raising alarms. Controllers can raise alarms in response to exception conditions that require immediate operator intervention. Alarms are not raised when hardware fails as this is notified by a change to controller’s health (see section 6.10 above); rather they are used when the hardware or software is unable to carry out the demanded request, e.g. move mechanism past the mechanism’s limits. The ECS uses the alarm system provided by the CSF to notify the operator of these errors or problems as they are detected. For details of alarms generated by the ECS see the ECS Operations & Maintenance Manual [AD 6], section ECS Alarms. The ECS Beta release of this document (version 4) listed the following as alarms to be generated by the ECS:

1. Alarms are generated whenever the ECS loses connection with the EMCS. The ECS constantly monitors EMCS connection status and so can determine if a connection is suddenly lost. In the ECS Final release as-built ECS hardware controllers do not generate an alarm at loss of connection to the EMCS but change their health category EMCS_Connection to BAD with reason explaining cause.

2. Loss of hardware control by a sub-controller (possibly due to loss of connection) results in an alarm being raised by the ECS. In the ECS Final release as-built ECS hardware controllers do not generate an alarm on loss of hardware control but change their health category EMCS_Channel_Err to BAD with reason explaining cause.

3. Loss of connection between ECS management controller and any of its sub-controllers from which it receives status information used in the overall ECS status. In the ECS Final release as-built the ECS management controller does not raise an alarm when connection to any of its sub-controllers is lost but changes its health category ECS_SubControllers to BAD with reason explaining the sub-controller(s) that cannot be connected to.

4. Detection of limits. In the ECS Final release as-built the ECS does not raise alarm or set its health BAD when a limit is detected. The ECS tracking controllers' cStatus.limit attribute value is constantly updated with current status of limits.

5. Loss of TCS trajectory event by the ECS when the ECS is tracking. In the ECS Final release as-built the ECS does raise alarm when this occurs.

6. The TCS trajectory event received by ECS results in position demand that is outside travel limits of mechanism. In the ECS Final release as-built the ECS does raise alarm when this occurs.

7. The miss-match of ECS tracking modes between tracking sub-controllers, e.g. azimuth carousel controller’s mode is active when altitude shutter controller’s mode is tracking. In the ECS Final release as-built the ECS does not raise an alarm when this is detected but changes its health category ECS_Mode_Mismatch to BAD with reason listing those sub-controllers whose mode differs from ECS management controller's mode.

8. The continued (after a configurable time period) miss-match of TCS trajectory event track identifier and that received in submitted configuration containing the .trackId attribute. In the ECS Final release as-built the ECS does raise an alarm when this occurs.


6.12 LOGGING

The ECS uses the ATST CSF Log Service [AD 9] to log its system activity. In accordance with the CSF the ECS recognizes messages of two types:

1. Status messages are messages that are always logged 2. Debug messages are only logged during diagnostic checks.

Both types of messages are stored in a relational database. Messages generated through the log service are automatically time stamped and tagged with the name of the component that generated them. The ATST Log Service enumerates a number of different message categories e.g. lifecycle, flow, init, timer etc, for a full list see [AD 9]. Logging is requirement 5.6-0080 of the ECS Specification SPEC-0082 [AD 1].

6.12.1 Status Messages

It is considered that the ECS controllers do not need to explicitly generate any status messages of their own as the CSF automatically generates them under the following circumstances:

Lifecycle changes

Health changes

Connection changes

Commands and responses

Alarms The approach the ECS generally adopts in the event of needing to log a status message is to change the health (see section 6.10) as this automatically logs a status message of the appropriate class i.e. note, warning or severe.

6.12.2 Debug Messages

When generating debug messages the ECS uses both message categories and debug levels. The category used is taken from the list of categories provided in the CSF User Manual [AD 9]. In addition to enable comprehensive debugging capabilities the ECS complements these categories, for details see the ECS Operations & Maintenance Manual [AD 6], section Trouble-Shooting & Debugging. The debug level of a controller is set through the lifecycle interface and applies to all code within that controller. Unless used carefully this can lead to excessive numbers of debug messages. The ECS adopts the guide lines described in [AD 9] and in particular only uses level 4 messages when absolutely necessary.

6.13 ENGINEERING SCREENS

The ECS provides a number of engineering screens capable of exercising the full functionality of the ECS. The screens are developed using the JES [RD 12] and so offer the user full control of the ECS controllers using the CSF capabilities provided by the JES. The functionality provided by the screens includes all capabilities available to the TCS through the TCS to ECS interface (see ICD 4.4/5.6 [AD 3]), though they are not limited by this interface; other maintenance capabilities are provided that are outside of the scope of this ICD, e.g. for azimuth carousel and altitude shutter checking travel limits


(details of these checks can be found in the Enclosure Maintenance Plan [AD 12]). The ability to perform engineering operations is specified in requirement 5.6-1310 of the ECS Specification SPEC-0082 [AD 1]. Moreover, the screens provide capability to monitor and control communications between ECS and EMCS and provide full access to the interface described in Enclosure to ECS ICD 5.0/5.6 (see [AD 4]). Providing engineering displays that permit the exercising of all the system’s functionality is requirement 5.6-1300 of the ECS Specification SPEC-0082 [AD 1].

6.14 CONTROLLING DEVICES THAT TRACK

The enclosure tracking mechanisms (e.g. azimuth carousel and altitude shutter) have to track a continuously changing demand position being passed to the ECS from the TCS. The TCS controls the tracking of these mechanisms by setting the ECS tracking mode. The ECS in turn controls the mechanisms by commanding the EMCS by setting the EMCS tracking mode. The ECS Specification SPEC-0082 [AD 1] contains the requirements 5.6-0130 Pointing, 5.6-0140 Tracking and Following and 5.6-0150 slewing, regarding the control of tracking mechanisms. Moreover, requirement 5.6-1015 states that the “ECS shall not contribute to the degradation of the delivered image quality of the ATST”, as no allocation within the enclosure error budget has been given to the ECS.

6.14.1 ECS and EMCS Tracking Modes

The TCS controls the enclosure tracking mechanisms by setting the ECS tracking mode of the ECS tracking controllers (e.g. atst.tcs.ecs.az.mode and atst.tcs.ecs.alt.mode). The tracking controller can be operating in one of the following ECS tracking modes:

Off – brakes are on, motor drives are off and servo loops are off.

Active – the controller is holding-position (brakes are off, motor drives are on and EMCS servo loops are actively maintaining a stationary position), or slewing to a new fixed position that the controller will subsequently maintain by holding-position. The position is submitted in a configuration containing the .pos, .namedPos or .oPos (if offsetting from current position) attribute with value set to the required position in degrees or the named position. Similarly the active mode is used when the axis is to be moved at a constant velocity; the velocity required is submitted in a configuration containing the .jogVel attribute. Only configurations containing one of .pos, .namedPos, .oPos or .jogVel are accepted, a configuration containing two or more of these attributes is rejected. When the ECS mode is active the controller disregards the TCS trajectory event.

Tracking – the controller is tracking using position demanded by TCS as received in the trajectory event. When the ECS mode is tracking any configurations containing the .pos, .namedPos, .oPos or .jogVel attributes are rejected.

Figure 7 shows diagrammatically the transition between the different ECS tracking modes.


Figure 7 Transitions between Tracking Modes

For efficient control of the enclosure tracking mechanisms the EMCS must be notified of the type of move being demanded by the ECS. This is communicated by the ECS to the EMCS by the setting of the EMCS tracking mode. The EMCS tracking modes are:

Off – brakes are on, motor drives are off and servo loops are off.

Point-to-Point – the mechanism is being controlled using a PID tuned for large movements, e.g. as may occur when slewing to a new target or moving to a named position.

Tracking – the mechanism is being controlled using a PID tuned for smaller movements, e.g. as occurs when tracking a target.

Jogging – this is an engineering mode used to move the mechanism at a constant velocity. As an EMCS engineering mode this mode can only be demanded when the EMCS current mode is Point-to-Point and the ECS controller's .inPosition=true, which ensures the mechanism is moving at minimum velocity.

Offset – this is an engineering mode used to demand a movement offset from the current position. As an EMCS engineering mode this mode can only be demanded when the EMCS current mode is Point-to-Point and the ECS controller's .inPosition=true, which ensures the mechanism is moving at minimum velocity.

Figure 8 shows diagrammatically the allowed transitions between the different EMCS tracking modes.


The relationship between ECS and EMCS tracking modes is shown in Figure 9.

Off Point

to

Point

Tracking

Jogging

pointToPoint

off

tracking pointToPoint

off

off

tracking

jogging inPostion=true

Offset off

offset inPosition=true

pointToPoint

pointToPoint

Figure 8 EMCS tracking modes


6.14.2 Tracking Control

When a tracking mechanism’s controller (e.g. atst.tcs.ecs.az or atst.tcs.ecs.alt) enters the Running state, when it receives a startup command, its ECS tracking mode will be Off. When the TCS wishes to start a mechanism tracking it submits a configuration containing attribute .mode with value equal to Tracking. The controller then decides which EMCS mode is correct for the movement of the mechanism based upon its current hardware position in relation to the position demanded in the TCS trajectory; if the difference in position demand and current position is greater than point-to-point tolerance than EMCS mode Point-to-Point is selected, otherwise Tracking is selected. The selected mode is sent to the EMCS together with the demanded position (calculated from the TCS trajectory event) and the mechanism begins moving. The ECS continues selecting the correct EMCS mode for each subsequent trajectory position it receives from the TCS and sends it to the EMCS. For example, if when tracking is started the target is some number of degrees from the current position of the mechanism, the ECS will select the EMCS mode Point-to-Point and send this to the EMCS together with the position demand, ensuring a swift movement towards the target. As the mechanism approaches the target position the ECS selects the EMCS mode Tracking and sends this with the position demand, ensuring a smooth track of the target. All tunable parameters used in the switching between EMCS tracking modes (e.g. the position difference at which the mode should be changed between Point-to-Point and Tracking) are stored in the property DB.

EMCS Off EMCS

Point-to-

Point

EMCS

Tracking

EMCS

Jogging

ECS Off ECS Tracking

ECS Active

EMCS

Offset

Figure 9 ECS Mode relationship to EMCS Modes


When the shutdown command is sent to the controller it always transition through the ECS Off mode and sets the EMCS mode to Off. For a full description of actions carried out to control tracking see the Use Cases in section 7. If communication is lost between ECS and EMCS while the EMCS is in tracking mode after a short amount of time the EMCS independently stops hardware movement and places the hardware in the default state (powered off, brakes applied). The ECS will set its mode to off and its health to bad if communication is lost to the EMCS while tracking. The presence of EMCS tracking modes and the transitions between them is fully hidden from the TCS as they only have consequence for direct control of hardware internally in the ECS.

6.14.3 ECS Tracking States and ATST Configuration States

The complication with tracking mechanisms is the ECS tracking state and how this maps on to the ATST configuration states. Once tracking has been started the mechanism will be continuously changing its position but the associated configuration is not necessarily Running. Indeed, it is more likely to be Done. The reason for this initially perhaps confusing terminology and why it is essential to the operation of the ATST control system is explained below. The ECS receives a new trajectory update from the TCS every 50ms consisting of:

A timestamp (as a modified Julian date on the TAI timescale).

An array of reference times.

An array of coefficients.

A unique track identifier (trackId). From the array of coefficients and reference times the ECS can evaluate the position and velocity at any instant in time. The TCS will have evaluated these coefficients by fitting a polynomial to demand positions at the reference times. The TCS uses reference times of t, t + 0.5s and t + 1.0s. The units of position are chosen to allow easy interpretation of the event stream – e.g. for the ECS, degrees rather than radians. The use of a quadratic polynomial enables the ECS to extrapolate the position to both earlier and later times. In the absence of any change to the positions of the targets (other than a constant differential tracking rate), which the TCS is tracking or changes to the telescope pointing model, successive demands generated from these arrays describe a smooth track, where extrapolating forward from one point or backwards from the next give much the same position. However, if there is a change in a target position or an adjustment to the pointing model there will be a discontinuity in the tracks described by two successive sets of coefficients evaluated at the same time, as illustrated in Figure 10. These discontinuities in the track can be any size from close to zero or to the full range of movement of the mechanism. The TCS signals such a discontinuity by changing the track identifier.


In the following two subsections two scenarios are considered to illustrate how ECS tracking mechanisms behave under control of the TCS.

6.14.4 Change of ECS Mode to Tracking

When the tracking controller receives a configuration that puts its ECS mode into tracking and it begins sending demands to the EMCS to move to the position contained in the TCS trajectory event, before the controller state is returned to Done it must check the mechanism’s current position against the evaluated TCS demand. If the difference is greater than a specified tolerance then the action must remain busy (configuration does not return) until the tolerance criterion are met. This criterion includes not only position tolerance but also velocity tolerance. It is not sufficient to set the configuration state to Done simply because the positions are close if it is known that the mechanism can overshoot and oscillate before it settles. Velocity criteria are tested using the current velocity of the hardware returned to the ECS from the EMCS. The reason for only reporting Done when the mechanism is truly settled is that the TCS and higher level systems will be waiting for every mechanism in the configuration to return Done, including those not controlled by the ECS. This is the signal that the next step in the observing sequence can be started. Typically this might be the opening of a shutter to start an integration. If some controllers have reported that they are Done too early then the integration may be degraded. The above is also the reason that a controller, once it is within tolerance, must not leave its action Running whilst tracking. If this happens the higher level sequencers will never know when the mechanism is ready. Although in principle these systems could compare their demand positions with the current position reported by the controller it would also require them to understand the dynamics of each of their subsystems’ mechanisms. It is more appropriate that this information resides in the subsystem. If a mechanism’s servo was re-tuned, for example, all the higher level devices that were monitoring that mechanism would probably need to be modified.

Time

Position

Figure 10 Tracking discontinuity


6.14.5 Change of Track Identifier

When a discontinuity appears in the stream of TCS trajectory demands the TCS signals this by both a change of the track identifier within the stream of trajectory demands and by submitting a configuration to the ECS top-level controller containing the attribute .trackId with value equal to the new track identifier. The change of track identifier is considered equivalent to the receipt of a configuration that puts the controller into the ECS tracking mode and should therefore be handled exactly like the situation described in the previous section. The configuration state changes to Running until the mechanism is once more within tolerance. Even if the discontinuity is so small that the mechanism remains within tolerance all the time, the configuration state must briefly be changed to Running and then be returned to Done. If at any time when ECS tracking mode equals tracking, the track identifier received by the ECS in the TCS trajectory demand does not match the last track identifier submitted in a configuration with attribute .trackId, the controller sets its in position status to false. However, once the ECS is in tracking mode it continues to send position demands to the EMCS using the TCS trajectory demands irrespective of a miss-match of trackIds, unless the miss-match of Ids continues for some configurable amount of time (as set in property DB). If the trackIds continue to be inconsistent after this time period the ECS will demand the ECS mode off, all axis movement is stopped and an alarm is raised. The trigger for changing to Running is simply the submitting of a configuration containing the attribute .trackId with new value of the track identifier, this relieves the controller from deciding whether the discontinuity is big enough to warrant going to the Running state but can instead set it unconditionally. Details of the above behavior are described in Use Case: TCS Receives New Target (see section 7.6).

6.15 POSITION FEEDBACK FOR THE TCS

In addition to the actions of a tracking controller’s state transitioning between Running and Done to signal a mechanism is tracking within tolerance (as described in section 6.14.3), the ECS must provide the TCS with up-to-date tracking mechanism (e.g. azimuth carousel and altitude shutter) position information. The position events posted by the ECS are defined in the TCS to ECS ICD 4.4/5.6 [AD 3]. Provision of in position status is requirement 5.6-0170 of the ECS Specification SPEC-0082 [AD 1]. The TCS uses the velocity information to extrapolate the position to the times for which the TCS is doing its pointing calculations, so that if required the actual position can be compared with the demand. In addition, an inPosition status for azimuth carousel and altitude shutter must be constantly available. The inPosition status events are monitored by the TCS at all times as a health check. Note that this status does not duplicate the information provided by the state transitions from Running to Done, etc. (see section 6.14.3). Consider the case where a mechanism is tracking perfectly well but then can no longer keep up with the TCS demands. This might happen for example to the azimuth carousel if the TCS is trying to track too close to the zenith. In this case there is no configuration submitted or any change in the track identifier sent in the trajectory event, so the controller state is always Idle. The inPosition status is however set to false so that the TCS can take action if required.


6.16 HARDWARE LIMITS

Each of the enclosure’s tracking mechanisms has a number of devices to protect their range of travel. These are, in advancing order towards hardware end of travel:

Velocity limit – as mechanism approaches the first protection limit (the EMCS soft limit) the mechanism’s maximum velocity is reduced by the EMCS.

EMCS soft limit – position beyond which the ECS will not, under normal operational control, ever demand the mechanism to move.

End-of-travel limit – a limit switch which the ECS is never, under any circumstances, able to move the mechanism past.

Final limit – the limit at which motor power is removed.

Hard limit – the hard stop. The actual limit values are stored in the property DB (see section 8.6.2). If a limit is entered the EMCS only accepts demands from the ECS to move the mechanism away from the limit and will reject demands to move further into the limit. Travel past the EMCS soft limit as far as the end-of-travel limit is permitted as an engineering operation (see Use Case in section 7.13.4). Correct use of hardware limits ensures the ECS is able to demand the enclosure tracking mechanisms over their full range of travel; this is requirement 5.6-0100 of the ECS Specification SPEC-0082 [AD 1].

6.17 ECS FAILURE MODES

This section describes possible failure modes of the ECS, how the modes are handled, and the potential consequences for other parts of the ATST control system.

6.17.1 Responding to Invalid Data

Attributes sent to the ECS are automatically range checked using data from the property DB; see TCS to ECS ICD [AD 3]. Configurations consisting of multiple attributes are then checked for consistency. The first of these checks could fail if the range limits in the property DB were incorrect. The second could fail if a combination of attributes that are invalid was accepted when it should have been rejected due to a programming error. The worst case scenario of an attribute being incorrectly range checked is likely to be an attempt to move hardware outside of the ECS limits, this will however not result in hardware damage as the hardware limits have multiple levels of protection. Other incorrect attributes may cause a software crash of a controller or controllers within the ECS due to an unhandled exception. This in turn could lead to the hardware controlled by the sub-controller no longer being controlled and the status event from the sub-controller no longer being published. The EMCS automatically protects and stops the movement of enclosure hardware on loss of connection to ECS. Loss of an event source, e.g. status, being subscribed to by other ATST systems would presumably be handled in that system in the same way as if the source had never existed, e.g. if required by that system for its operation it would probably raise an alarm or change its health.

6.17.2 Responding to Invalid Trajectory Data

The ECS receives from the TCS trajectory data resulting in position demands outside of the enclosure tracking mechanisms' range. When tracking is switched on the received data are range checked before sending to the hardware. If received value is outside of position limits tracking is switched off and an


alarm raised, with message including the evaluated position attempted to be demanded and the time used to evaluate the position coefficients. If received value is outside of velocity limits the velocity is clipped to maximum permitted value before demand is sent to the EMCS PLC and an alarm is raised, this is the behavior that occurs when tracking through the zenith region, see section 7.7 Use Case: Zenith Blind Spot.

6.17.3 Internal Failures

The ECS is required to monitor the state of its sub-controllers and reflect any failures of these sub-controllers. Failure here is in respect to a failure in sub-controller processing, not a failure due to EMCS processing or enclosure hardware, EMCS and hardware failures are coved in section 6.17.4. The ECS top-level ManagementController atst.tcs.ecs is responsible for maintaining a record of the state of its sub-controllers and for maintaining open connections to them for submission of configurations. Each sub-controller present in the ECS system responds to a heartbeat sent by the management controller. If the sub-controller fails to respond to the heartbeat the atst.tcs.ecs controller sets its health BAD with a message explaining which of its sub-controllers are no longer available.

6.17.4 Failures of EMCS

The ECS can only control the enclosure hardware through its connection to the EMCS. If the connection fails or the EMCS reports an internal failure the appropriate ECS sub-controller sets its health to BAD with a message explaining the cause. If a connection failure occurs the sub-controller using that connection will discover this when it attempts to write data to the EMCS or read status. If an internal failure occurs in the EMCS, e.g. a PLC system fault, the atst.tcs.ecs.emcs sub-controller sets its health BAD or ILL, depending on severity of failure, with a message explaining the. Likewise, if the hardware that is the responsibility of other sub-controllers fails, the sub-controller responsible for the hardware sets its health BAD with a message explaining the cause.

6.17.5 Inconsistent EMCS to ECS Interface

The enclosure hardware is controlled and monitored by the ECS through its interface with the EMCS, as defined in the EMCS to ECS ICD [AD 4]. Any inconsistency between the implementation of this interface in the ECS and EMCS could cause major upsets during operation, e.g. the data being used by the ECS to demand azimuth carousel position is interpreted by the EMCS as a demand for the altitude shutter due to a mismatch of interface definitions. Any inconsistency in interface between EMCS to ECS shall not cause any risk of damage to health or machinery, as no control through this interface will ever be permitted to endanger safety, e.g. if the ECS was demanding to move the altitude shutter, when really it should be demanding to the azimuth carousel, the EMCS will not move the shutter, even if demanded to do so, if it is not safe to do so. However, all reasonable precautions are made to ensure the interface in use is consistent. The inconsistency of interfaces is protected against by the use of an interface version number. The version number of the interface in use by the ECS is stored in the ECS and the version in use by the EMCS is available for the ECS to read from the EMCS. Only if version numbers are equal will the ECS management controller accept configurations. Details of how this is implemented are described in section 8.4 Ensuring Correct ICD Version in Use of this document.


7 U S E C AS E S

The use cases presented here are based upon and developed from those described in the Reference Design Studies and Analysis (RDSA) Document for the ATST Enclosure [RD 11] and those contained in the version of this document presented at PDR. Since publication of the RDSA development of the ATST CSF has continued and specifics about the controllers of the ECS have been defined, see TCS to ECS ICD 4.4/5.6 [AD 3]. Therefore the use cases described here can contain details regarding the software controllers of the ECS. Detailed design of the controllers mentioned is contained in section 8 Detailed Design of this document. The use cases described here concentrate on normal operations expected to be performed routinely during the course of the enclosure’s working life. General operational/science use cases are described in sections 7.1 through 7.12. Section 7.13 and its sub-sections contain the engineering/maintenance use cases. The engineering use cases make reference to operational use cases they use to accomplish tasks common to both operational and engineering, e.g. starting up and shutting down the ECS, etc. There are four principle actors on ECS operations:

1. The human Operator is responsible for controlling the ECS operational lifecycle state (e.g. initialized, running, etc). During normal operations the operator controls the ECS lifecycle through the Observatory Control System (OCS). During engineering the operator uses the ECS JES screens.

2. During normal operations the TCS is the system from which the ECS receives its demands (except those operating on its lifecycle, see above) and that subscribes to ECS events. All permitted interactions between TCS and ECS are detailed in the ICD 4.4/5.6 [AD 3]. During engineering all operations available to the TCS are available to the engineer through ECS JES screens.

3. The EMCS is the system the ECS receives all enclosure hardware information from, and the system the ECS sends commands to move hardware. All permitted interactions between EMCS and ECS are detailed in the ICD 5.0/5.6 [AD 4].

4. The GIS is the system the ECS receives enclosure interlock status from, as detailed in the OCS to GIS ICD 4.2/4.5 [AD 5].

The use cases described below contain references to the ECS controllers (see Section 6.7), to explain as fully as possible how the overall system design of the ECS allocates responsibilities to its various parts. This ensures actions required to be carried out to fulfill use cases can be identified with specific controllers and these actions identified as requirements for the controller’s design. Figure 11 is the ECS Operational Use Cases diagram showing the associations between the use cases detailed in sections 7.1 through 7.12. In this diagram the GIS and EMCS are shown as UML actors to highlight the use cases that have a direct interaction with them. A <<precede>> relationship shown on the diagram between use cases, indicates that the use case at which the precede arrow ends can only be completed following the successful completion of the use case at which the arrow begins, e.g. the use case Start Tracking precedes the use case Start Observing as Start Observing cannot be completed until after Start Tracking has been completed. An <<include>> relationship identifies those use cases that to fulfill all of their role rely on including another use case, e.g. the Tracking use case includes the Interlock Event use case because while the ECS is tracking it must react to interlock events.


Figure 11 ECS Operational Use Cases


7.1 USE CASE: INITIALIZING THE ECS

Name ECS Initialization

Identifier ECS_UC_01

Description This use case describes the actions taken to transition the ECS from the Loaded to Initialized state. It is expected that the ECS PC is configured to start the ECS container when it is booted, and the ContainerManager loads the ECS components (as specified in the application database) into the ECS container. Therefore the first user access with the ECS will be after it, and its sub-controllers, are in the Loaded state.

Goal ECS enters the Initialized state. The ECS always reaches the Initialized state following an init command as this is a condition of CSF.

Actors Operator

Preconditions Successful boot of ECS PC with all components in Loaded state. The state of the enclosure hardware at the beginning of this use case is immaterial as the ECS does not connect to hardware during initialization (guideline of CSF).

Assumptions None

Frequency As required, but must be carried out following power-on/reboot of ECS PC, but could also occur following use of uninit command.

Basic Course 1. The operator issues the init command to the ECS top-level ManagementController atst.tcs.ecs.

2. The atst.tcs.ecs propagates the received init command to all its sub-controllers.

3. Controller properties are read from property DB. 4. The ECS enters the Initialized state

Alternate Course None

Post Conditions Startup

Included Use Cases None

Notes No hardware is moved during ECS initialization.


7.2 USE CASE: STARTUP

Name Startup


Description This use case describes the actions taken by the ECS when sent the startup command. During this process connection is made to the EMCS, status of enclosure hardware is retrieved and demands sent to place hardware into the default state. The health of the top-level ECS ManagementController and its sub-controllers, once in the Running state, will show BAD or ILL health if there is an ECS problem and/or the EMCS is unable to respond to requests. If, following a startup command, the health is shown as BAD or ILL, the ECS can be shutdown (see 7.12 Use Case: Shutdown) and then the startup command resent to ascertain if the state causing this initial health still persists, or whether the cause has been remedied.

Goal Enclosure hardware is in default state. ECS enters the Running state and will accept configurations sent to it to carry out actions, including the moving of enclosure hardware if demanded.

Actors Operator, EMCS, GIS.

Preconditions Use Case: Initializing the ECS (see section 7.1)

Assumptions The initial condition of the enclosure at the beginning of this use case is expected to be:

All enclosure hardware will be in state to enable control from the ECS, e.g.:

o the EMCS will be on and operating normally, o no emergency stops or other interlocks will be active, o any hardware switches isolating hardware and

enabling local-control, i.e. by human intervention using switches or other mechanisms, will be switched to position disabling local-control.

All enclosure motor drive power to azimuth carousel, altitude shutter and other movable mechanisms is off, though voltage power is supplied to all enclosure hardware systems enabling them to be powered on when demanded by the ECS.

Frequency As required, but must be carried out following use of init or shutdown commands.

Basic Course 1. The operator issues the startup command to the ECS top-level ManagementController atst.tcs.ecs.

2. The atst.tcs.ecs propagates the received startup command to all its sub-controllers.

3. Each sub-controller reads its EMCS PLC tag information from the property DB and opens connection to the EMCS PLC to read tag containing its hardware status.

4. Each sub-controller checks whether any interlock is currently active for the enclosure hardware it is responsible for


(ascertained from whether GIS event atst.gis.interlock contains overall enclosure interlock attribute with value true, or the individual sub-controller’s interlock attribute is true). The presence of an active interlock does not change the course of the use case but will determine the setting of the controllers’ health prior to completion of the strartup process, i.e. if an interlock is active the sub-controller does not check individual fault status of its hardware returned from EMCS to determine its health setting, as the presence of an interlock is likely to cause the setting of various fault status items, e.g. loss of power, etc.

5. If Sub-controllers’ interlock is not active (checked in step 4) they interrogate the status of the hardware they are responsible for and set their health appropriately (with corresponding message describing cause). If their interlock is active their health is set BAD with message explaining this is caused by an active interlock. Retrieved hardware status is published in controller's cStatus event.

6. Sub-controllers send demand to the EMCS to place their hardware into the default state.

7. The EMCS sub-controller atst.tcs.ecs.emcs reads from the EMCS PLC the tag containing the Enclosure to ECS ICD version number in use by the PLC. The controller places the value in its Cache where it is accessed by the ECS management controller using a get.

8. The EMCS sub-controller atst.tcs.ecs.emcs sets the current EMCS PLC time by writing a tag to the PLC containing the time obtained from the ECS PC host machine.

9. The ECS transitions from Initialized to Running.

Alternate Course #1 At step 3 the sub-controller is unable to open connection to EMCS. The controller (and ECS) transition into the Running state, but controller will set its health BAD and, at frequency set in properties DB, the controller will attempt to open connection to EMCS and read back status.

Alternate Course #2 At step 6 the sub-controller fails to ascertain hardware is in default state following sending demand to EMCS. The controller (and ECS) will transition into the Running state, but controller will set its health BAD explaining inability to ascertain hardware is in the default state.

Post Conditions Use Case: Start Tracking (see section 7.3) Use Case: Tracking (see section 7.4) Use Case: Start Observing (see section 7.5) Use Case: TCS Receives New Target (see section 7.6)


Notes Hardware default state is demanded and therefore hardware

may move if not already in this state prior to ECS startup.


7.3 USE CASE: START TRACKING

Name Start Tracking


Description This use case describes the actions taken to place the enclosure in the correct configuration to begin tracking trajectory demands from the TCS.

Goal ECS is sending TCS trajectory demands to the EMCS and the enclosure is tracking.

Actors TCS, EMCS.

Preconditions Use Case: Startup (see section 7.2)

Assumptions Prior to the start of this use case it is expected that the TCS is publishing enclosure trajectory data events, these may relate to a target object that is to be tracked or a fixed position; to the ECS it is irrelevant whether the trajectory demands are changing or fixed. For more information about how tracking devices are controlled see section 6.14.

Frequency As required but at least once per observing day.

Basic Course 1. The operator, via OCS or directly to TCS, submits configuration with attribute:

atst.tcs.mode = tracking. The TCS adds to this the track Id attribute and value:

atst.tcs.trackId = <newTrackId>

The TCS then propagates this configuration to ECS setting atst.tcs.ecs.mode to Tracking and atst.tcs.ecs.trackId to given value.

2. The atst.tcs.ecs propagates the mode value of Tracking and trackId to all sub-controllers responsible for enclosure tracking mechanisms. Prior to receiving this configuration the ECS mode may be Off (motor drive power is off and brakes are applied – EMCS mode Off) or Active (motor drive power is on, brakes are released and mechanism is actively holding-position or moving towards a fixed position demand – EMCS mode Point-to-Point).

3. ECS tracking sub-controllers (e.g. atst.tcs.ecs.az and atst.tcs.ecs.alt, which control the azimuth carousel and altitude shutter respectively) begin tracking their mechanisms (see Use Case: Tracking, section 7.4). (This continues until they receive a configuration with ECS mode value set to either Off or Active.) NB. If the altitude shutter seals are not in the deflated state they will be deflated by the EMCS before the shutter begins tracking.

4. The enclosure will begin moving to track the demanded trajectory, or if TCS demanded trajectory is a fixed position equal to mechanisms’ current position, the enclosure will


hold-position until the TCS receives a new target. 5. Once the current tracking configuration equals the

configuration of the current .trackId, and the position and velocity read from the EMCS are within specified tolerance (received from TCS in configuration attribute); the tracking sub-controllers set their 1 Hz status event .inPosition attribute value to true.

6. The submitted configuration completes with Done.

Alternate Course At step 5 if after some configurable timeout the EMCS is not within position tolerance and/or .trackId is not equal that requested. The sub-controller sets its health to BAD with message describing cause, and in step 6 the configuration completes with status Abort.

Post Conditions Use Case: Start Observing (see section 7.5) Use Case: TCS Receives New Target (see section 7.6) Use Case: Zenith Blind Spot (see section 7.7) Use Case: Stop Tracking Mechanisms (see section 7.11)

Included Use Cases Use Case: Tracking (see section 7.4)

Notes Hardware is powered on and may begin moving during

this Use Case.


7.4 USE CASE: TRACKING

Name Tracking


Description Use case describing actions of ECS tracking sub-controllers to move an enclosure tracking mechanism to follow trajectory data produced by the TCS.

Goal Enclosure tracking mechanism tracks TCS trajectory data stream.

Actors TCS, EMC, GIS.

Preconditions Use Case: Start Tracking (see section 7.3)

Assumptions The TCS is publishing enclosure trajectory data events. There are no interlocks or other hardware occurrences present that prevent enclosure mechanisms from tracking.

Frequency When a tracking sub-controller’s ECS mode is Tracking this occurs at 20Hz.

Basic Course 1. Each ECS tracking sub-controller (e.g. atst.tcs.ecs.az and atst.tcs.ecs.alt) receives the trajectory event (atst.tcs.ecsTrajectory) from the TCS.

2. Each tracking sub-controller calculates the next position and velocity demands for its mechanism from its coefficients received in the TCS event.

3. Each tracking sub-controller checks its calculated next position demand against the current hardware position and based upon this decides which EMCS mode is required – either EMCS mode Tracking or EMCS mode Point-to-Point. When EMCS mode transitions from Off to any of the other modes the EMCS switches on mechanism’s motor power and releases brakes. Operation of power and brake can be explicitly controlled by the ECS during engineering/maintenance but at all other times will be controlled by the EMCS.

4. Each tracking sub-controller updates the values being written to the EMCS in its trajectory position PLC tag to contain the position and velocity calculated in step 2, and EMCS mode selected in step 3, and writes the tag to the EMCS.

5. In a separate thread (i.e. independent from the arrival of the TCS trajectory events) each tracking sub-controller reads from the EMCS the PLC tag containing its current position information.

6. The in position status of the mechanism is calculated from the returned position and velocity information. The tracking sub-controller’s .inPosition attribute value is only set true when mechanism’s position and velocity remain in required tolerance for configurable (in property DB) period of time.

Alternate Course #1 In step 1 the ECS tracking sub-controller does not receive the TCS trajectory event within specified period (configurable in property DB).


The sub-controller raises alarm notifying user of none arrival of TCS trajectory events.

Alternative Course #2 In step 2 the position demand calculated from its coefficients received in the TCS event are outside of mechanism's range of travel. The sub-controller stops tracking by asserting mode off and raises alarm detailing coefficients received, time used to interpolate demand and position demand calculated.

Alternative Course #3 In step 2 the velocity demand calculated from its coefficients received in the TCS event is outside of mechanism's velocity range. The sub-controller raises alarm detailing coefficients received, time used to interpolate demand and velocity calculated.

Post Conditions None

Included Use Cases Use Case: Interlock Event (see section 7.8)

Notes Hardware is powered on and may begin moving during

this Use Case.


7.5 USE CASE: START OBSERVING

Name Start Observing


Description This use case describes the actions taken by the ECS to allow sun light into the enclosure to begin observing.

Goal Sunlight is entering the enclosure.

Actors TCS, EMCS, GIS.


Assumptions All observatory conditions are in correct state to accept sun light into the enclosure.



atst.tcs.ecs.cover.pos = open

The TCS propagates this configuration to the ECS. 2. The atst.tcs.ecs propagates the configuration to the aperture

cover sub-controller atst.tcs.ecs.cover. 3. The atst.tcs.ecs.cover sub-controller sends command to

EMCS to begin opening aperture cover. 4. While aperture cover is opening, the atst.tcs.ecs.cover sub-

controller sets the .cPos attribute in its 0.1 Hz status event to value between.

5. EMCS status informs sub-controller that aperture cover is open, and controller publishes this in .cPos attribute in its 0.1 Hz status event.

6. The submitted configuration completes with status Done.

Alternate Course At step 5 the EMCS status does not return that aperture cover is open within opening timeout or a cover failure is reported. The sub-controller sets its health to BAD with message describing cause. In step 6 this will cause the configuration to complete with status Abort.

Post Conditions Use Case: Zenith Blind Spot (see section 7.7) Use Case: Stop Observing (see section 7.9)


Notes Hardware will begin moving during this Use Case.


7.6 USE CASE: TCS RECEIVES NEW TARGET

Name TCS Receives New Target


Description This use case describes ECS actions when the TCS receives a new target, or any occurrence that causes a change to the track identifier. For more information about how tracking devices are controlled see section 6.14, and specifically section 6.14.5 for use of the track identifier.

Goal Enclosure begins to follow new target.



Assumptions TCS is publishing trajectory event.

Frequency As required during observing when new target is requested.

Basic Course 1. The TCS submits to the ECS a configuration containing attribute:

atst.tcs.trackId = <newTrackId> 2. The ECS ManagementController atst.tcs.ecs propagates the

new trackId to its tracking sub-controllers. 3. The tracking sub-controllers (e.g. atst.tcs.ecs.az and

atst.tcs.ecs.alt) receive the new trackId and set their respective 1 Hz status event attribute .inPosition value to false.

4. The enclosure moves to follow new trajectory from TCS as passed to it by the tracking sub-controllers – this is the same behavior as has continued since ECS Tracking was switched on (see Use Case: Start Tracking, section 7.3).

5. The tracking sub-controller continues to demand the enclosure to move the mechanism to the value received in the TCS trajectory stream irrespective of a miss-match between .trackId received in trajectory stream and submitted configuration, as long as this does not continue for a period longer than configured by value set in property DB.

6. Once the status from the EMCS shows that the tracking mechanism position is within tolerance the controller’s .inPosition attribute is set true and published in its status event. (The controller always sets its .inPosition value false whenever the trajectory .trackId does not match the last submitted configuration .trackId.)

7. The submitted configuration completes with Done, signaling the enclosure is now tracking the new target

Alternate Course At step 6 if after some configurable timeout the EMCS is not within position tolerance the sub-controller sets its health to BAD, with message describing cause, and in step 7 the configuration completes with status Abort.




Notes Hardware will begin moving during this Use Case


7.7 USE CASE: ZENITH BLIND SPOT

Name Zenith Blind Spot


Description This use case describes the actions taken when the demanded trajectory enters the zenith blind spot. Correct ECS operation when moving through the zenith blind spot is requirement 5.6-0110 of the ECS Specification SPEC-0082 [AD 1].

Goal The enclosure exits the zenith blind spot ready to continue observations but with aperture cover closed.


Preconditions Use Case: Start Observing (see section 7.5)

Assumptions None

Frequency Depends upon observing target trajectory.

Basic Course 1. The TCS detects the zenith blind spot is about to be entered and automatically submits configuration to the ECS with attribute atst.tcs.ecs.cover.pos with value equal to Close.

2. The actions described in Use Case: Stop Observing (see section 7.9) are carried out to stop sun light entering the enclosure.

3. The ECS tracking sub-controllers continue receiving TCS trajectory events and sending corresponding position demands to EMCS.

4. The enclosure continues to track through the blind spot as best it can. The TCS will decide whether the enclosure rotates north or south of the zenith depending upon the time of year.

5. As the zenith is approached the ECS tracking sub-controllers .inPosition status changes to false when enclosure can no longer keep up with position demands received in TCS trajectory events.

6. Depending upon proximity track passes to the zenith the TCS trajectory received may result in calculated velocity being out of range, if this occurs the velocity demanded is clipped by the sub-controller prior to sending demand to the EMCS and an alarm is raised.

7. Once through the zenith the tracking sub-controllers .inPosition status changes to true once the enclosure can maintain position within specified tolerances.

8. The zenith blind spot is exited and operator is notified by TCS. The operator then decides when to open the aperture cover (see Use Case: Start Observing, section 7.5) – the cover is not automatically opened once the zenith blind spot has been exited.


Post Conditions Use Case: Start Observing (see section 7.5)



Use Case: Interlock Event (see section 7.8) Use Case: Stop Observing (see section 7.9)

Notes Hardware will move during this Use Case


7.8 USE CASE: INTERLOCK EVENT

Name Interlock Event


Description This use case describes the actions of the ECS when notified of an enclosure interlock event by the GIS. If an interlock occurs in the enclosure but the ECS is not notified of it by the GIS the enclosure hardware status is likely to resemble the state of a powered off system, it may also create failure signals due to the removal of system power. If such failures occur without the ECS being notified of an interlock the ECS will carry out its normal behavior when hardware fails, i.e. set its health/alarms as appropriate to the hardware status being returned by the EMCS.

Goal The ECS correctly recognizes and acts upon the enclosure interlock.

Actors EMCS, GIS.


Assumptions None

Frequency As per enclosure interlock event occurrences.

Basic Course 1. The ECS is notified of an interlock through the event defined in the property DB .interlock:event , which the ECS ManagementController (atst.tcs.ecs) and all its sub-controllers are constantly monitoring. The raising of an overall enclosure interlock is notified by the attribute .encInterlock in the defined event becoming true.

2. The sub-controllers send commands to the EMCS to place their hardware in the default state, e.g. not moving, powered off, brakes applied. The default state of every mechanism controlled by the ECS is stored in the property DB (see section 6.9). Thus any ongoing motions at time of interlock are not resumed automatically after the interlock is cleared. NB. The ECS is not responsible for stopping or in any other way controlling hardware due to the presence of an interlock, this is the responsibility of interlock hardware.

3. The sub-controllers ensure their own state is inert, e.g. tracking sub-controllers transition to ECS mode Off, if not already in this state and also set EMCS mode to Off (this is the default EMCS mode) and will not accept configurations to move hardware while the .encInterlock attribute remains true (this behavior is part of the CSF).

4. The sub-controller's health goes to BAD with reason explaining hardware status can no longer be checked as presence of active interlock will cause hardware fault status to become active.

5. Once the interlock is cleared the .encInterlock attribute becomes false. The ECS remains in the state achieved by steps 2 and 3 until explicitly commanded to do otherwise; no


operations occurring prior to the interlock are automatically resumed. Health is returned to GOOD.


Post Conditions Use Case: Start Tracking (see section 7.3) Use Case: Start Observing (see section 7.5)


Notes The event from the GIS notifying the ECS of the presence of an active interlock contains not only an overall enclosure interlock attribute (i.e. .encInterlock that is used above), but also attributes for each of the enclosure’s mechanisms that the ECS can actively control, i.e. altitude shutter, azimuth carousel, auxiliary equipment and aperture cover. The ECS sub-controllers responsible for these mechanisms recognize the occurrence of an individual interlock relating only to their mechanism and take the same action as described above, placing them into the interlocked state for the duration that their individual interlock attribute remains true. Those sub-controllers to which the interlock does not relate continue to operate and accept configurations as normal. In this way the ECS does not prevent control of mechanisms that are not currently actively interlocked, e.g. it permits the same control as if the hardware was being controlled directly from the EMCS local control panel.


7.9 USE CASE: STOP OBSERVING

Name Stop Observing


Description This use case describes the actions taken to stop sun light entering the enclosure.

Goal Sun light is not entering the enclosure.


Preconditions Use Case: Start Observing (see section 7.5)

Assumptions None



atst.tcs.ecs.cover.pos = close The TCS propagates this configuration to the ECS.

2. The ECS atst.tcs.ecs ManagementController propagates configuration to the aperture cover sub-controller atst.tcs.ecs.cover.

3. The sub-controller atst.tcs.ecs.cover sends commands to EMCS to begin closing aperture cover.

4. While aperture cover is closing the atst.tcs.ecs.cover sub-controller sets the .cPos attribute in its 0.1 Hz status event to value between.

5. EMCS status informs sub-controller that aperture cover is closed, and controller publishes this in its 0.1 Hz status event by setting .cPos attribute to value closed.

6. Sun light is no longer entering enclosure. 7. The submitted configuration to close aperture cover

completes with state Done.

Alternate Course In step 5 the EMCS status does not show that aperture cover is closed. The atst.tcs.ecs.cover completes the configuration to close the cover with status Abort. If the sub-controller can determine the cause of the failure was a hardware problem then it sets its health to BAD with an appropriate message.

Post Conditions Use Case: Stow Tracking Mechanisms (see section 7.10)




7.10 USE CASE: STOW TRACKING MECHANISMS

Name Stow Tracking Mechanisms


Description This use case describes the actions taken to place the tracking mechanisms in their stow position and stop their movement.

Goal The ECS places the enclosure’s tracking mechanisms in the state appropriate for end of day’s observations.

Actors Operator, EMCS, GIS.


Assumptions None


Basic Course 1. The operator, via OCS or directly to TCS, submits configuration with attributes:

atst.tcs.ecs.mode = active

atst.tcs.ecs.alt.namedPos = stow

atst.tcs.ecs.az.namedPos = stow The TCS propagates this configuration to the ECS.

2. The ECS propagates the configuration to tracking sub-controllers, which set their 1 Hz status event .inPosition attribute values to false, and change their ECS mode from either Off or Tracking to Active.

3. Each tracking sub-controller sets the EMCS mode in their trajectory position PLC tag to Point-to-Point and position equal to its stow position (read from property DB). The tag is then sent to the EMCS.

4. The tracking mechanisms begin moving to the demanded stow position.

5. Once EMCS status informs tracking sub-controllers that their mechanism’s have reached the stow position within specified tolerances, the controllers set their 1 Hz status event .inPosition attribute values to true.

6. The submitted configuration to stow mechanisms completes with status Done.

Alternate Course #1 In step 5 if after some configurable (in property DB) amount of time the EMCS status does not show the mechanism to have reached the stow position, if this is due to a problem with hardware (discovered through interrogation of status) then sub-controller’s health is set BAD with message explaining the cause and the configuration completes with status Abort. If no hardware problem can be found then health is not changed but configuration completes with status Abort with reason explaining timeout occurred.

Post Conditions Use Case: Stop Tracking Mechanisms (see section 7.11)




7.11 USE CASE: STOP TRACKING MECHANISMS

Name Stop Tracking


Description This use case describes actions to stop movement of the enclosure tracking mechanisms.

Goal Enclosure tracking mechanisms are not moving.



Assumptions Use Case: Stow Tracking Mechanisms (see section 7.10)


Basic Course 1. The operator, via OCS or directly to TCS sends configuration with attribute:

atst.tcs.ecs.mode = off The TCS propagates this configuration to ECS setting atst.tcs.ecs.mode to Off.

2. The atst.tcs.ecs propagates the configuration to all tracking sub-controllers setting mode attribute to value Off.

3. The tracking sub-controllers set the EMCS mode in their trajectory position PLC tag to Off and write the tag to the EMCS. This applies brakes and powers off mechanism motor drives.

4. The EMCS status informs tracking sub-controllers that EMCS mode is Off.

5. The sub-controllers publish event data showing their ECS mode is Off.

6. The submitted configuration to set ECS mode to Off, and therefore stop tracking, completes with status Done

Alternate Course In step 4 if after some configurable (in property DB) amount of time the EMCS status does not equal EMCS mode Off, the sub-controller’s health is set BAD with message explaining the cause. In step 5 ECS mode will still be set to Off as tracking sub-controllers will no longer be sending position demands to the enclosure. In step 6 this will cause the configuration to complete with status Abort.




7.12 USE CASE: SHUTDOWN

Name Shutdown


Description This use case describes actions taken by the ECS on receipt of the shutdown command. During this process demands sent to place hardware into the default state and all connections to the EMCS are closed.

Goal Enclosure hardware is in default state. The ECS transitions from Running to Initialized state. The ECS always reachs the Initialized state following a shutdown command as this is a condition of CSF.

Actors Operator, EMCS.


Assumptions None

Frequency As required, but not expected to be used daily as the actions used to place enclosure in non-observing state are described in Use Case: Stop Observing , Use Case: Stow Tracking Mechanisms and Use Case: Stop Tracking Mechanisms.

Basic Course 1. The operator issues the shutdown command to the ECS ManagementController atst.tcs.ecs.

2. The atst.tcs.ecs propagates the shutdown command to all its sub-controllers that send demands to the EMCS to place their hardware into the default state. NB. The EMCS automatically inflates the altitude shutter seals when the sub-controller atst.tcs.ecs.alt demands the default state (EMCS mode Off).

3. All ECS hardware sub-controllers report status showing hardware is stopped, brakes applied and powered off.

4. The sub-controllers close all open connections to EMCS. 5. All ECS controllers transition from Running to Initialized

state

Alternate Course At step 3 a sub-controller cannot stop movement of hardware or hardware status does not report movement is stopped within specified timeout. The sub-controller enters the Initialized state and sets its health to BAD with message explaining cause.

Post Conditions Use Case: Initializing the ECS (see section 7.1)

Included Use Cases None.

Notes Hardware default state is demanded and therefore hardware

may move if not already in this state prior to ECS shutdown.


7.13 ENGINEERING USE CASES

This section contains a number of use cases that may be carried out during engineering and maintenance operations. They are:

Precisely move an enclosure tracking mechanism to a fixed position to enable access to various enclosure items, see Engineering Use Case: Move to Fixed Position section 7.13.1.

Move enclosure mechanism by offset to precisely align hardware to a specific point, see Engineering Use Case: Offsetting Position section 7.13.2.

Move enclosure mechanism at a constant velocity for testing purposes, see Engineering Use Case: Constant Velocity Move section 7.13.3.

Move enclosure mechanism past the EMCS software to the end-of-travel limit, see Engineering Use Case: Move to EMCS Limit section 7.13.4.

Calibrate the enclosure tracking mechanisms by carrying out an enclosure calibration pointing test, see Engineering Use Case: Calibrate Enclosure Tracking Mechanisms section 7.13.5.

It is expected that maintenance operations will take place by interacting directly with the ECS through its engineering JES screens. However, any use cases that uses operations available through the TCS to ECS ICD 4.4/5.6 [AD 3], could equally be carried out by sending configurations to the ECS from the TCS. Figure 12 is the ECS Engineering Use Cases diagram showing the associations between the engineering use cases detailed in sections 7.13.1through 7.13.5. In the diagram engineering specific use cases are identified by the Eng. prefix.


Figure 12 ECS Engineering Use Cases


7.13.1 Engineering Use Case: Move to Fixed Position

Name Move to Fixed Position

Identifier ECS_UC_13.1

Description This use case describes the actions taken by the ECS to move an enclosure tracking mechanism to a fixed position. The ECS sub-controller responsible for a tracking mechanism can be moved to any fixed position in its range of travel by submitting a configuration containing the .pos attribute. Moreover it recognizes a number of fixed named positions signaled in a configuration using attribute .namedPos, which may have one of the following values:

stow – indicates move to stow position of mechanism (as used in Use Case: Stow Tracking Mechanisms, see section 7.10). The actual position moved to is defined in controller’s .stowPos property.

servicePos[n] – indicates move to the numbered service position. The actual position moved to is defined in controller’s .namedPos:servicePos[n] property. The positions defined are useful for servicing operations, e.g. position of drive bogies, position of service hatches, etc.

limit[HiHi|Hi|Lo|LoLo] – indicates a move to a limit position. The actual position to move to is defined in controller’s .namedPos:limit* properties. The positions defined include the various limit positions of each tracking mechanism, e.g. electronic lower end-of-travel, EMCS lower soft-limit, etc. The moving to a limit position is a special case of moving to a named position and includes this use case but also its own use case, see Engineering Use Case: Move to EMCS Limit (section 7.13.4).

Goal ECS demands enclosure tracking mechanism to move to a fixed position.

Actors Engineer, EMCS, GIS


Assumptions Use Case: Stop Tracking Mechanisms (see section 7.11)

Frequency As required for maintenance and engineering purposes.

Basic Course 1. The engineer submits a configuration to the ECS ManagementController atst.tcs.ecs with the following attributes and values, where [trackingController] can be set equal to identifier of any tracking sub-controller (i.e. az or alt):

atst.tcs.ecs.[trackingController].mode =

active

if moving to a specific position – atst.tcs.ecs.[trackingController].pos =

<degPosRequired>

or if moving to a named position – atst.tcs.ecs.[trackingController].namedPos

= [stowPos | servicePos[n] |


limit[HiHi|Hi|Lo|LoLo] ]

NB. if named position selected is HiHi or LoLo then the EMCS limit test mode must be enabled using the EMCS HMI, see Engineering Use Case: Move to EMCS Limit (section 7.13.4).

2. The atst.tcs.ecs propagates configuration to tracking sub-controllers as required, e.g. atst.tcs.ecs.az if [trackingController] has value az.

3. The tracking sub-controller changes its ECS mode from Off (or Tracking) to Active and sets its .inPosition attribute of its 1Hz status event to false. NB. If the altitude shutter seals are not in the deflated state they will be deflated by the EMCS before beginning shutter movement.

4. The tracking sub-controller then sets the EMCS mode in their trajectory position PLC tag to Point-to-Point and position equal to the required position. If configuration contains the .pos attribute this will be the value of the attribute. If the configuration contains the .namedPos attribute the value is read from the controller’s property corresponding to the requested named position. The tag is then sent to the EMCS.

5. The tracking sub-controller monitors the current position of the mechanism (by reading tag from EMCS), and once position is within specified tolerance it sets its .inPosition attribute of its 1Hz status event to true.

6. The configuration to move to fixed position completes with status Done.

Alternate Course #1 In step 5 if after some configurable (in property DB) amount of time the EMCS status does not show the mechanism to have reached the required position, if a problem with hardware can be discovered as the cause (through interrogation of status) then sub-controller’s health is set BAD with message explaining the cause and the configuration completes with status Abort. If no hardware problem can be found then health is not changed but the configuration completes with status Abort.

Alternate Course #2 If during steps 3 to 5 the engineer decides that the move to the fixed position given in the configuration is no longer required, the engineer can submit a configuration containing .mode=off. This is propagated to the controller that sets the EMCS mode to Off and writes the tag to the EMCS. Once EMCS status shows this to have completed the controller sets its ECS mode from Active to Off. The original configuration completes with status Abort as it did not complete successfully.





7.13.2 Engineering Use Case: Offsetting Position

Name Offsetting Position


Description This use case describes the maintenance operation of moving a tracking mechanism a fixed offset from its current position. The ability to offset from the current position is requirement 5.6-0160 of the ECS Specification SPEC-0082 [AD 1].

Goal The tracking mechanism is moved a fixed offset from its current position.

Actors Engineer, EMCS, GIS


Assumptions Use Case: Stop Tracking Mechanisms (see section 7.11)


Basic Course 1. The engineer submits a configuration to ECS ManagementController atst.tcs.ecs with the following attribute and value:


active 2. The atst.tcs.ecs propagates configuration to tracking sub-

controllers as required, e.g. atst.tcs.ecs.az if [trackingController] has value az.


4. The tracking sub-controller then sets the EMCS mode in their trajectory position PLC tag to Active and position equal to the current hardware position. The tag is then sent to the EMCS.

5. The tracking sub-controller monitors the current position of the mechanism (by reading tag from EMCS), and once position is within specified tolerance it sets its .inPosition attribute to true in its 1Hz status event.

6. The configuration to set ECS mode to Active completes with status Done.

7. The engineer submits a configuration to ECS ManagementController atst.tcs.ecs with the following attribute and value:

atst.tcs.ecs.[trackingController].oPos =

<offSetPosRequired> The .oPos attribute’s value should be set to the number of degrees from current position the mechanism is to be moved. The direction of offset is determined by the value’s sign.

8. The atst.tcs.ecs propagates configuration to tracking sub-controllers as required.


9. The tracking sub-controller then sets the EMCS mode in their trajectory position PLC tag to Offset and position equal to the required offset position. The tag is then sent to the EMCS.


11. The configuration to move to offset position completes with status Done.

Alternate Course #1 In step 5 or 10 if after some configurable (in property DB) amount of time the EMCS status does not show the mechanism to be in position, if a problem with hardware can be discovered as the cause (through interrogation of status) then sub-controller’s health is set BAD with message explaining the cause and the configuration completes with status Abort. If no hardware problem can be found then health does not change but the configuration completes with status Abort.

Alternate Course #2 If during steps 7 to 10 the engineer decides that the move to the offset position given in the configuration is no longer required, the engineer can submit a configuration containing .mode=off. This is propagated to the controller that sets the EMCS mode to Off and writes the tag to the EMCS. Once EMCS status shows this to have completed the controller sets its ECS mode from Active to Off. The offset configuration completes with status Abort as it did not complete successfully.





7.13.3 Engineering Use Case: Constant Velocity Move

Name Constant Velocity Move


Description This use case describes the maintenance operation of moving a tracking mechanism at a constant velocity. E.g. moving the azimuth carousel at a fixed velocity of 0.01 degrees/second until told to stop (see Use Case: Stop Tracking Mechanisms), or a limit is reached (see Use Case: Interlock Event).

Goal ECS moves enclosure tracking mechanism at constant velocity.

Actors Operator, EMCS, GIS

Preconditions Use Case: Stop Tracking Mechanisms (see section 7.11)

Assumptions None


Basic Course 1. The engineer submits a configuration to ECS ManagementController atst.tcs.ecs with the following attribute and value:


active 2. The atst.tcs.ecs propagates configuration to tracking sub-

controllers as required, e.g. atst.tcs.ecs.az if [trackingController] has value az.


4. The tracking sub-controller then sets the EMCS mode in their trajectory position PLC tag to Active and position equal to the current hardware position. The tag is then sent to the EMCS.


6. The configuration to set ECS mode to Active completes with status Done.

7. The engineer submits a configuration to ECS ManagementController atst.tcs.ecs with the following attribute and value:

atst.tcs.ecs.[trackingController].jogVel =

<jogVelRequired>. The .jogVel attribute’s value should be set to the constant velocity in degrees/second that the mechanism is to be moved at. The direction of movement is determined by the value’s sign.

8. The atst.tcs.ecs propagates configuration to tracking sub-


controllers as required. 9. The tracking sub-controller then sets the EMCS mode in their

trajectory position PLC tag to Jogging and velocity equal to the required velocity. The tag is then sent to the EMCS.

10. The tracking sub-controller monitors velocity of mechanism returned in status from EMCS. Once velocity is within specified tolerance of demanded velocity, it sets its .inPosition attribute to true in its 1Hz status event.

11. The constant velocity configuration completes with status Done.

12. The mechanism continues to move at the specified velocity until it is commanded to stop (see Use Case: Stop Tracking Mechanisms, section 7.11) , a limit is reached (or other interlock occurs) or steps 1 to 6 are repeated to demand the EMCS to actively servo the mechanism at its current postion.

Alternate Course #1 In step 5 if after some configurable (in property DB) amount of time the EMCS status does not show the mechanism to be in position, if a problem with hardware can be discovered as the cause (through interrogation of status) then sub-controller’s health is set BAD with message explaining the cause and the configuration completes with status Abort. If no hardware problem can be found then health does not change but the configuration completes with status Abort.

Alternate Course #2 In step 10 if after some configurable (in property DB) amount of time the EMCS status does not show the mechanism to have reached the required velocity, if a problem with hardware can be discovered as the cause (through interrogation of status) then sub-controller’s health is set BAD with message explaining the cause and the configuration completes with status Abort. If no hardware problem can be found then health will not be changed but the configuration completes with status Abort




The tracking sub-controller’s attribute used to demand a constant velocity (.jogVel) has associated with it a range; this is defined in the TCS to ECS ICD [AD 3]. This range will be checked automatically by CSF and if value is outside range the configuration is returned with status BAD_PARAM. This occurs before the configuration is passed to the ECS and so reference to range-checking is not included in this use case


7.13.4 Engineering Use Case: Move to EMCS Limit

Name Move to EMCS Limit


Description This use case describes the actions taken to move an enclosure tracking mechanism to a position where the EMCS soft-limit or the EMCS end-of-travel limit is activated (actual degree positions are stored in property DB). The mechanism cannot be moved past the EMCS electronic end-of-travel limit as the ECS must never command the mechanism past this limit [AD 1]. The configuration accepted by the ECS to move to a limit position uses the limit named positions detailed in the TCS to ECS ICD [AD 3], the limitLo and limitHi named postions equate to the EMCS software limits, while the limitLoLo and limitHiHi equate to the EMCS end-of-travel limits.

Goal Move enclosure tracking mechanism to EMCS limit.

Actors Operator, EMCS, GIS

Preconditions Use Case: Stop Tracking Mechanisms (see section 7.11) If using the named positions limitLoLo or limitHiHi equating to the EMCS end-of-travel limits the EMCS limit test mode must be enabled using the EMCS HMI.

Assumptions None


Basic Course 1. The engineer submits a configuration to ECS ManagementController atst.tcs.ecs with the following attributes and values:


atst.tcs.ecs.[trackingController].namedPos =

[limitLoLo | limitLo | limitHi | limitHiHi] 2. The use case continues as Engineering Use Case: Move to Fixed

Position (section 7.13.1) with following additions: 3. If the limit being moved to is either limitLoLo or limitHiHi the

tracking sub-controller informs the EMCS by setting its limit test mode. This is done by writing motor drives command PLC tag with either positive or negative limit test mode set true, depending upon whether moving to low or high limit. The limit test mode in the EMCS remains true as long as no values in the trajectory position PLC tag change, i.e. once the values of this tag are written to the EMCS (done in the next step) any subsequent change to the tag values causes the limit test mode to be set false.

4. The tracking sub-controller then sets the EMCS mode in their trajectory position PLC tag to Point-to-Point and position equal to the required limit position. The tag is then sent to the EMCS.

5. The tracking sub-controller monitors the position of the mechanism and once position is within specified tolerance it sets its .inPosition attribute to true in its 1Hz status event.

6. The configuration to move to limit position completes with status Done once .inPosition is true.


Alternate Course #1 In step 5 if after some configurable (in property DB) amount of time the EMCS status does not show the mechanism to be in position, if a problem with hardware can be discovered as the cause (through interrogation of status) then sub-controller’s health is set BAD with message explaining the cause and the configuration completes with status Abort. If no hardware problem can be found then health does not be changed but the configuration completes with status Abort.

Alternate Course #2 If during steps 3 to 5 the engineer decides that the move to the limit given in the configuration is no longer required, the engineer can submit a configuration containing .mode=off. This is propagated to the controller that sets the EMCS mode to Off and writes the tag to the EMCS. Once EMCS status shows this to have completed the controller sets its ECS mode from Active to Off. The original configuration completes with status Abort as it did not complete successfully.


Included Use Cases Use Case: Interlock Event (see section 7.8) Engineering Use Case: Move to Fixed Position (see section 7.13.1)


Once the end-of-travel limit is active only configurations to move outside of EMCS software limits will be accepted by the ECS, as the ECS can never move beyond the

end-of-travel limit. To move out of the EMCS limit region a configuration can be submitted to the ECS with:


atst.tcs.ecs.[trackingController].pos =

<posOutsideLimit> Alternatively see Use Case: Stow Tracking Mechanisms (section 7.10) or Engineering Use Case: Move to Fixed Position (section 7.13.1).


7.13.5 Engineering Use Case: Calibrate Enclosure Tracking Mechanisms

Name Calibrate Enclosure Tracking Mechanisms


Description This use case describes the actions taken to carry out an ECS calibration pointing test of the enclosure tracking mechanisms. This is done using the TCS and ECS engineering screens. The TCS is used to move the TMA and the enclosure to a series of pointing test positions. At each position the smart camera attached to the TMA is used to calculate pointing corrections necessary to correctly align the enclosure. Following completion of the pointing test all recorded corrections are used as input to generate a pointing model using the TPoint software (as is used to generate the TMA pointing model used by the TCS). The model produced by TPoint is then used by the TCS as a pointing model to correct positions sent to the ECS to move the enclosure. For details of how to operate the TCS see [RD 7].

Goal To generate an ECS pointing model used by the TCS to position the enclosure.

Actors Operator, TCS, EMCS, GIS

Preconditions Use Case: Stop Tracking Mechanisms (see section 7.11)

Assumptions None


Basic Course 1. Set the TCS to use a null pointing model for the TMA, i.e. a pointing model with all terms set to zero. This is done to ensure the TMA’s pointing model does not impact on the ECS pointing model, and therefore require a new ECS pointing model to be generated if any changes are made to the TMA pointing model.

2. Using the TCS engineering screens ensure the enclosure is set to follow the mount.

3. Using the ECS engineering screens turn on the TMA Smart Camera and calibration LED by submitting a configuration with:

atst.tcs.ecs.aux.camera:enable = on 4. Turn on TCS and ECS tracking by submitting a configuration

with:

atst.tcs.mode = tracking This causes all mount and enclosure axes to begin tracking.

5. Begin the pointing test by demanding the TCS to move the mount to the first pointing test position. This causes both the mount and enclosure to move to the demanded position.

6. Wait until TCS status shows that both the mount and enclosure are in position.

7. Using the ECS engineering screens read the TMA Smart Camera x and y position error.

8. Use the ECS engineering screen to demand the TCS to apply the camera position errors as offsets to the demanded ECS


position. 9. Repeat steps 7 and 8 until the x/y corrections returned by the

TMA Smart Camera are zero. 10. Use the ECS engineering screen to demand the TCS to log the

ECS pointing test position to the pointing test log file. 11. Repeat steps 5 to 10 for each pointing test position. 12. Turn off the TMA Smart Camera and ECS calibration LED

and turn off TMA and ECS tracking. 13. Return the TCS TMA pointing model to that in use prior to

step 1. 14. Generate the ECS pointing model by running TPoint and

using the generated pointing test log file. 15. Configure the TCS to use the ECS pointing model generated

by TPoint.

Alternate Course Failure of any configuration submitted to the TCS or ECS will result in failure of the calibration.


Included Use Cases Use Case: Tracking (see section 7.4) Use Case: Interlock Event (see section 7.8)


The operations necessary to perform the ECS calibration pointing test could be made available on a single engineering screen, which accessed both TCS and ECS capabilities required. Moreover, the procedure could be automated within a script if the necessary capabilities were made available, e.g. the conversion from TMA Smart Camera x/y correction to TCS offsets.


8 D E TAI LE D D E S I G N

The detailed design of the ECS is contained in this section. As the communication between the ECS and EMCS is of intrinsic importance to the ability of the ECS to meet its requirements, this section begins by discussing how this communication is achieved. The subsequent sections describe the design of the ECS packages atcs.tcs.ecs and its sub-package atst.tcs.ecs.abplc, and build upon the communication information of the first section to describe how they meet the ECS requirements.

8.1 EMCS TO ECS COMMUNICATION

The EMCS uses an Allen-Bradley ControlLogix 1756 PLC supplied by Rockwell Automation. The PLC is connected by a dedicated Ethernet link to the ECS Linux PC using an Allen-Bradley EtherNet 1756-EN2T interface module (or equivalent). The native network application layer protocol supported by Allen-Bradley, running over TCP/IP Ethernet, is EtherNet/IP, where IP stands for Industrial Protocol. In this document Ethernet is used to refer to the network link layer commonly used to deliver TCP/IP, and EtherNet/IP is used to refer to the network link layer protocol used by Allen-Bradley PLCs to communicate over Ethernet networks. EtherNet/IP is the name given to the Common Industrial Protocol (CIP) when transferred over Ethernet. CIP is the protocol used between Allen-Bradley products to communicate, e.g. the EN2T interface module communicates across the PLC backplane to the ControlLogix PLC using CIP. In ControlLogix PLCs data is defined and accessed using tags, e.g. I/O addresses, bits, variables, timers, etc, are all identified by tag names. Therefore, for the ECS to control enclosure hardware using the EMCS the ECS must be able to read and write PLC tags using EtherNet/IP. Figure 13 shows the communication stack that is used to communicate between the ECS and EMCS.

Figure 13 ECS to EMCS EtherNet/IP Communications Stack

The communications stack including and below TCP/UDP layers, are supplied by Linux and the ATST observatory’s network infrastructure. The EtherNet/IP layer and above is supplied by the ECS. To understand the best method of supplying EtherNet/IP functionality to the ECS a study was completed, and its findings are documented in the technical report ECS to EMCS Communication [RD 13]. The report includes details of EtherNet/IP and CIP, various solutions that could be used including


software and hardware, and details of various software libraries that provide EtherNet/IP functionality. The study concluded that a software solution was the most suitable and that the PLCIO library from Commercial Timesharing Inc. is our choice of EtherNet/IP implementation. This library was chosen because:

The library’s Application Programming Interface (API) follows the normal Unix/Linux device driver form of open/close, read/write functions and hides knowledge of CIP and EtherNet/IP from users. Therefore it does not require any expert knowledge from the programmer above that expected for normal CSF application development.

The library is delivered with all source code.

The library contains different modules capable of communicating with a wide range of PLCs from the same and different manufacturers (e.g. Allen-Bradley and Siemens). The API remains the same irrespective of communication module being used, therefore a change of PLC type could be made and only require code changes if the data format used between PLCs was changed.

PLCIO is very cost effective compared to other solutions offering more comprehensive EtherNet/IP capabilities not required by the ECS. The initial software developers kit for PLCIO containing source code and one runtime license costs $1795 (additional runtime licenses cost $595), the next cheapest product costs $10,500 (prices correct as at January 2011).

We communicated with Dutch company Van Oord, who uses PLCIO to communicate between Allen-Bradley PLC and Linux, and they express happiness in its performance and support from Commercial Timesharing Inc.

A requirement placed upon the ECS is to provide a generic solution for communicating with Allen-Bradley PLCs, which can be used in ATST control systems not associated with the ECS [AD 2]. This is provided by a Java Native Interface C library containing wrappers for the PLCIO functions that can be called from Java. Therefore any ATST application requiring to communicate using PLC tags can simply include the library and call PLCIO from its Java controllers. In addition to the JNI library the abplc ECS package contains helper classes to assist with the passing of data in the form of PLC tags.

8.1.1 PLCIO

PLCIO is the selected C Library that is used for all communication between ECS and EMCS. All details of PLC communication using EtherNet/IP and CIP are hidden from the application programmer by the PLCIO API, see Figure 14. In the ECS only the JNI C library directly uses PLCIO. Moreover, only the ABPlcioMaster class in the ECS abplc package makes calls into the JNI and therefore all read and write of data to the EMCS goes through this class.


Figure 14 Linux PC to ControlLogix PLC Communication Using PLCIO

For full details of the PLCIO API see the PLCIO User Manual [RD 17].

8.1.1.1 The PLCIO pc_format String

When accessing a PLC tag PLCIO uses a pc_format string to describe the data type of the data items contained in the tag. The pc_format string has the form <type_id>[optional length in bytes]. Using this format the type and size of scalar, array and user-defined tags can be fully described. For example, the PLC tag used in the EMCS to accept tracking mechanism position data is a user-defined tag with the following format:

Tag name: Pos

Tag data item name Tag data item type ID INT Mode INT Position REAL Velocity REAL

The corresponding pc_format string is ‘jjrr’, where jj represents the two integer data items ID and Mode, and rr is used to represent the real data items Position and Velocity. PLCIO contains the utility showcip that can be used to query the public tags of a PLC, and generate the pc_format string for each tag. The same format string is used for storing and transferring the data type of tags used in the ECS.

8.2 PLC TAG INFORMATION IN THE PROPERTY DB

As described above the data transferred between ECS and EMCS is in the form of ControlLogix PLC tags. The property DB is used to store the PLC tag information for each tag a controller uses to communicate with the EMCS. The tag information stored in the property DB is taken from the EMCS to ECS ICD 5.0/5. 6 [AD 4].


The property DB is also used to store the default value of each tag that is written to the EMCS. The ECS has the requirement to command the default state of all enclosure hardware on ECS startup, shutdown and when notified of an interlock (SPEC-0082 5.6-0050 [AD 1]). For full information on PLC tag properties used by the ECS see section PLC Tag Configuration in the ECS Operations & Maintenance Manual [AD 6].

8.3 THE PLC TAG CLASS

The generic class used to represent PLC Tags in the ECS is the PlcTag class contained in the ECS abplc package. It is used by each ECS hardware controller to create PlcTag objects representing each tag the controller uses to communicate with the EMCS. The PlcTag objects of a controller are created when the controller is started and use the tag information stored in the property DB. When reading or writing a PLC tag the connection passes the PlcTag object representing the tag to its channel using the IPlcTag interface. This ensures the object can be successfully transferred across the namespace boundary between controller’s connection and the singleton master class responsible for all communications with the EMCS. Details of the classes of the abplc package implementing the connection and master classes are given in section 8.5. Figure 15 shows the class diagram of the PlcTag class and its interface IPlcTag. The class contains all information necessary to transfer tags between ECS and EMCS using the PLCIO library. Moreover the data read from the EMCS, and data to write to the EMCS, can be passed out of and into the PlcTag object as an attribute table, which is the standard data structure used throughout the CSF for transferring data.


Figure 15 Class diagram showing PlcTag class and its interace IPlcTag

8.4 ENSURING CORRECT ICD VERSION IN USE

To ensure the PLC tags in use by the ECS and the EMCS are defined from the same version of the EMCS to ECS ICD 5.0/5.6 [AD 4], the ECS contains the defined version it is using and checks this against the version in use by the EMCS. A mismatch between the interface version numbers results in the ECS management controller rejecting all configurations submitted to it. At ECS startup the ICD version number in use by the ECS is read by the management controller from the EMCS to ECS constants file and stored in property atst.tcs.ecs.icdVersionEcs (see 8.6.1). The version number in use by the EMCS is read from the EMCS PLC tag when the EMCS controller (atst.tcs.ecs.emcs) first connects to the EMCS (e.g. at controller Startup). The version number of the


EMCS ICD is stored in property atst.tcs.ecs.emcs.icdVersionEmcs (see section 8.6.5). If the atst.tcs.ecs controller detects a mismatch between versions in use, it sets its health to BAD with reason explaining cause. The doCanRun() method of the ECS management controller rejects all configuration submitted to it unless the ICD versions is use match.

8.5 PACKAGE ABPLC: IMPLEMENTING THE CONNECTION BASED HARDWARE COMMUNICATION APPROACH BETWEEN THE ECS AND EMCS USING JNI

The ECS software used by ECS controllers to communicate with the EMCS PLC is contained in the abplc sub-package of the ecs package of the ECS. The abplc package implements the ATST preferred hardware communication design pattern termed connection based, see CSF documentation for details [AD 11]. Also contained in the package is the source code of the JNI library that provides the Java wrapper for the PLCIO communications library. The use of JNI is the ATST preferred solution for interfacing between Java and C software.

8.5.1 abplc Connection Classes and Interfaces

The main abplc connection classes consist of the classes ABPlcioConnection, ABPlcioChannel and ABPlcioMaster. ABPlcioConnection is the abstract class used to derive the specific controller connection classes. Each ECS hardware controller has its own connection object of its required type, see Table 1. The tracking mechanism controller's do not derive their connection classes directly from ABPlcioConnection but from the abstract class ABPlcioConnectionTracking (that itself is derived from ABPlcioConnection) as this enables common connection tracking software to be shared by both controllers' specific connection classes. The class of the connection object used by each controller is defined in its .connection:class property and has the value listed in the table. The connection object of the correct type is created for the controller by CSF prior to calling the controller's doStartup() method.

Controller Name Connection Class

atst.tcs.ecs.alt ABPlcioConnectionAlt

atst.tcs.ecs.az ABPlcioConnectionAz

atst.tcs.ecs.aux ABPlcioConnectionAux

atst.tcs.ecs.cover ABPlcioConnection

atst.tcs.ecs.emcs ABPlcioConnectionEmcs

Table 1 Controller Connection classes

Each connection creates a number of ABPlcioChannel objects that it uses to read and write data to the EMCS using the ABPlcioMaster. The ABPlcioMaster controls all access to the EMCS, there is a single object of this class in the ECS container. Due to the above distribution of responsibilities between connection, channel and master, with connection and channel objects belonging to a specific ECS controller and therefore operating in the controller’s Java namespace, while the single master belongs to the ECS container and therefore operates in the container’s namespace, Java interfaces must be used to successfully transfer data across


the controller/container namespace barrier. The distribution of connection classes within the controller and container namespaces are shown in Figure 16.

Figure 16 Distribution of Connection Classes within Controller and Container Namespaces

The top-level interfaces and classes of package abplc implementing the connection software of the ECS are shown in Figure 17. Figure 18 contains the class diagram showing the dependencies between the ABPlcioConnection class and its derived classes that provide the controller specific connection classes. Each connection class shown in Figure 18 also has an associated interface (e.g. as shown in Figure 17 for ABPlcioConnection in the IABPlcioConnection interface), but for diagram clarity these are not included in the figure.


Figure 17 Class diagram showing top-level Connection interfaces and classes contained in the ECS package abplc.


Figure 18 Class diagram showing dependencies between the Connection classes.

Full details of all connection interfaces and connection classes of the ECS Final release as-built are contained in the ECS's Javadoc source code documentation. Following ECS installation the documentation may be viewed using a web-browser by opening the file $ATST/doc/api-


docs/java/atst/index.html and navigating to package atst.ecs.abplc. For ECS installation details see the ECS Operations & Maintenance Manual [AD 6].

8.5.2 abplc JNI

Within the directory structure of the ECS abplc package is the jni directory. This directory contains the JNI C source code implementing the JNI C library that contains the PLCIO wrapper functions callable from Java. The functions contained in this library are called from class ABPlcioMaster when any request is made to communicate with the EMCS PLC by a call to its plcAccess() method. The ABPlcioMaster class declares the wrapper functions as methods prefixed by the Java modifier native. There is a one-to-one relationship between these native methods and the PLCIO API functions used by the ECS components (see 8.1.1). When ABPlcioMaster calls a native method it results in the corresponding JNI wrapper function being called, which in turn calls the PLCIO API function of the same name. The native methods implemented in the JNI library are:

plc_open() – used to open a connection to the EMCS PLC. Passed as an input parameter is the address of the EMCS PLC, this address originates from the property DB (.connection:address) and is passed to the controller’s connection object in its doConnect() method. The method returns a unique connection number used to identify the open connection in all subsequent plc_* method calls.

plc_close() – used to close an open connection to the EMCS PLC. The connection closed is identified by the unique connection number passed as an input parameter.

plc_read() – used to read a PLC tag from the EMCS. Once data is successfully retrieved from the EMCS the native method calls back into the ABPlcioMaster class using its plc_readCallback() method. The plc_readCallback() method accepts as input parameters the number of bytes and the byte data read. A JNI method can only return a single value, whereas using a callback method enables the returning of multiple values. The tag value is returned from JNI as a byte-stream using little endian byte ordering, this must be swapped to Java's endianess which is always big endian, irrespective of processor architecture on which the application is running. Following translation into the correct byte ordering the byte-stream is decoded into data of the correct type using the tag's pc_format definition (see 8.1.1.1). The tag data is then stored in the tag's PlcTag object (see section 8.3) from where it is accessed by the connection class once this method completes.

plc_write() – used to write data to the EMCS. The data is passed as an input parameter to this method in bytes; prior to calling the method ABPlcioMaster encodes the tag data into bytes using the tag’s defined pc_format (see section 8.1.1.1) and translates the bytes from Java (big) endian to little endian format.

To evaluate the use of the connection based approach and JNI for transferring the type and amounts of data required by the ECS to the EMCS using PLCIO, a number of communication tests were carried out. The tests used Fast Data; data equating to the data to be written and read at the rate of the tracking trajectory stream data (20Hz), and Slow Data; equating to data read to receive hardware status and written to send hardware commands at 1Hz. Table 2 shows the results of the test. For full details of the tests and results see [RD 14].


Max

read/write time (ms)

Min read/write time (ms)

Mean read/write time (ms)

Modal read/write time (ms)

Percentage total of read/writes

accomplished in:

2ms 5ms

Read Fast Data

11 0 2.181 1 61.28% 98.96%

Write Fast Data

11 0 2.119 1 65.33% 99.13%

Read Slow Data – 8 drives

11 1 2.514 3 50.92% 98.41%

Write Slow Data – 8 drives

12 1 2.822 3 42.97% 96.69%

Table 2 Communication Test Results

The results obtained show that the selected design using the connection based approach and JNI to call PLCIO to access the EMCS PLC, provides the necessary performance. However, threads used in the ECS components to communicate with the PLC and operating within a defined period (e.g. 20Hz), do monitor the time they take to accomplish their duties and raise alarms if they do not complete their work cycle within their allotted period.

8.6 PACKAGE ECS

The atst.ecs package contains the ECS application specific classes used to create the ECS controllers. These classes contain the knowledge of how to translate information received by the ECS into the correct format to command the enclosure hardware as required through the EMCS. Likewise they contain the knowledge of how to retrieve information from the EMCS required by the ECS that it then passes to other systems, e.g. the TCS. The atst.ecs package controller class diagram is shown in Figure 19.


Figure 19 Class Diagram of ECS Controllers.

All atst.ecs package classes are implemented in Java, the controller classes are:

Ecs – extends the CSF ManagementController and implements the atst.tcs.ecs controller.

Alt – extends the CSF HardwareController class through the abstract atst.ecs.TrackingMech class and implements the atst.tcs.ecs.alt controller.

Az – extends the CSF HardwareController class through the abstract atst.ecs.TrackingMech class and implements the atst.tcs.ecs.az controller.

Aux – extends the CSF HardwareController class and implements the atst.tcs.ecs.aux controller.

Cover – extends the CSF HardwareController class and implements the atst.tcs.ecs.cover controller.

Emcs – extends the CSF HardwareController class and implements the atst.tcs.ecs.emcs controller.


8.6.1 Management Controller atst.tcs.ecs

The atst.tcs.ecs controller is implemented using class Ecs that is a subclass of the CSF ManagementController. It manages the lifecycle of all other ECS. The ECS Final as-built properties used by this controller are contained and documented in the file ECS.prop installed with the ECS, see the ECS Operations & Maintenance Manual [AD 6]. All configurations submitted to the ECS are submitted to the atst.tcs.ecs controller. It then inspects the attributes submitted and makes any additional adjustments before propagating them to the destination sub-controllers. As with all ECS Java classes full documentation of the Ecs class as-built may be viewed using a web-browser by opening the file $ATST/doc/api-docs/java/atst/index.html and navigating to package atst.ecs, once the ECS installation is complete. (for details see [AD 6]).

8.6.2 Tracking Sub-Controllers atst.tcs.ecs.az and atst.tcs.ecs.alt

From the respect of control by the ECS through the EMCS, the azimuth carousel and altitude shutter mechanisms are very similar, e.g.:

The EMCS PLC tags used to control their hardware and read back status are very similar, having many of the same items communicating the same information.

The startup and shutdown of their hardware is the same as the EMCS PLC is responsible for required movement of the altitude shutter seals.

Their control in regards to changes of ECS modes (Off, Active and Tracking) and the relation of these to EMCS modes (Off, Point-to-Point, Tracking and Jogging) are the same.

The hardware of the two axes are different (e.g. number of motors, etc), therefore the status returned by the individual axis controllers is different but it does contain items common to both. The above similarities in behavior of the tracking sub-controllers responsible for moving the azimuth carousel and altitude shutter, atst.tcs.ecs.az and atst.tcs.ecs.alt respectively, are implemented in the abstract TrackingMech class, which is extended from the CSF HardwareController class. The individual behavior of the mechanisms is captured in their individual classes (Alt and Az) that are implemented by extending the TrackingMech class. In the FDR ECS design and ECS Alpha release the TrackingMech class was extended from the CSF MotionController class, however during development for the ECS Alpha release it became more evident that the CSF MotionController contains a lot of functionality not required for control of the ECS tracking mechanisms. Motion control of these mechanisms is handled by the EMCS; the ECS tracking controllers require to act as a translation service rather than motion controllers. The translation required is between the control offered to the TCS through the TCS to ECS ICD and the control available to the ECS through the EMCS to ECS ICD. Functionality provided by the CSF MotionController not required by the ECS are:

Control available using both user and raw units – the EMCS mechanisms can only be controlled using user units (degrees).

Control available through both .command and .mode attributes – the ECS only requires to be controlled using .mode.


Provides more modes of operation than required by the ECS, such as index, park, sip (servo-in-position). All ECS modes of operation can be supplied by modeOff, modeActive and modeTracking with a one-to-one correspondence to the .mode attribute submitted by the TCS.

Protects control of hardware using hwLock – due to the requirement of the ECS connection classes to protect access to the PLCIO library, protection against the sending of multiple commands simultaneously to the hardware is already handled within the connection class.

The benefits of not using the CSF MotionController are:

Simplifying the code – when the TrackingMech class extended the MotionController class it required to override many of its super class's methods to provide the behavior required by the ECS.

Updates to the MotionController class will not impact or in any way affect the ECS and therefore no re-testing of tracking functionality will be required when it is modified.

For the above reasons the TrackingMech class as-built does not derived from MontionController but directly from HardwareController. The ECS Final as-built properties used by the tracking mechanism controllers are contained and documented in the file ECS.prop installed with the ECS. The PLC tag properties used by the atst.tcs.ecs.az controller are inherited from ECSPlcTagsAz.prop and atst.tcs.ecs.alt from ECSPlcTagsAlt.prop. All .prop files containing all properties used by ECS controllers are installed with the ECS, see the ECS Operations & Maintenance Manual [AD 6]. As with all ECS Java classes full documentation of the TrackingMech, Alt and Az classes as-built may be viewed using a web-browser by opening the file $ATST/doc/api-docs/java/atst/index.html and navigating to package atst.ecs, once the ECS installation is complete. (for details see [AD 6]).

8.6.3 Sub-controller atst.tcs.ecs.aux

The auxiliary equipment of the enclosure is controlled and monitored by the atst.tcs.ecs.aux controller. This is implemented using the Aux class that extends the CSF HardwareController class. Auxiliary equipment includes enclosure calibration camera, cranes, lights, and Top End Optical Assembly (TEOA) platform. Only the calibration camera and accompanying LED are actively controlled by the auxiliary controller, all other equipment requires only to be monitored. The camera and LED are enabled when a configuration is submitted to the controller with the attribute .camera:enable. While the camera is enabled the camera's x and y position read back from the EMCS PLC are published in the controller's cStatus event in the attribute .camera:position. The ECS Final as-built properties used by the atst.tcs.ecs.aux controller are contained and documented in the file ECS.prop installed with the ECS. The PLC tag properties used by the controller are inherited from ECSPlcTagsAux.prop. All .prop files containing all properties used by ECS controllers are installed with the ECS, see the ECS Operations & Maintenance Manual [AD 6]. As with all ECS Java classes full documentation of the Aux class as-built may be viewed using a web-browser by opening the file $ATST/doc/api-docs/java/atst/index.html and navigating to package atst.ecs, once the ECS installation is complete. (for details see [AD 6]).


8.6.4 Sub-controller atst.tcs.ecs.cover

The aperture cover is controlled by the atst.tcs.ecs.cover controller. This is implemented using the Cover class that extends the CSF HardwareComponent class. The control of the aperture cover involves the opening and closing of the cover when demanded to do so on submission of configuration with attribute atst.tcs.ecs.cover.pos. The ECS Final as-built properties used by the atst.tcs.ecs.cover controller are contained and documented in the file ECS.prop installed with the ECS. The PLC tag properties used by the controller are inherited from ECSPlcTagsCover.prop. All .prop files containing all properties used by ECS controllers are installed with the ECS, see the ECS Operations & Maintenance Manual [AD 6]. As with all ECS Java classes full documentation of the Cover class as-built may be viewed using a web-browser by opening the file $ATST/doc/api-docs/java/atst/index.html and navigating to package atst.ecs, once the ECS installation is complete. (for details see [AD 6]).

8.6.5 Sub-controller atst.tcs.ecs.emcs

The monitoring of the actual state of the EMCS PLC for ECS housekeeping purposes is done by the atst.tcs.ecs.emcs controller. This is implemented using the Emcs class that extends the CSF HardwareController. This controller is not contained in the TCS to ECS ICD 4.4/5.6 [AD 3] and so it is not controlled (has configurations submitted to it) by the TCS or any other system outside of the ECS. Though as a CSF controller it can accept configurations and its events (including cStatus) can be subscribed to outside of the ECS. The EMCS PLC has status which it is important to know to understand the operational capability of the enclosure. A system fault in the PLC will make it impossible to control the enclosure using the EMCS. This controller monitors such status and makes it available to other parts of the ECS and to the outside world. The ECS Final as-built properties used by the atst.tcs.ecs.emcs controller are contained and documented in the file ECS.prop installed with the ECS. The PLC tag properties used by the controller are inherited from ECSPlcTagsEmcs.prop. All .prop files containing all properties used by ECS controllers are installed with the ECS, see the ECS Operations & Maintenance Manual [AD 6]. As with all ECS Java classes full documentation of the Emcs class as-built may be viewed using a web-browser by opening the file $ATST/doc/api-docs/java/atst/index.html and navigating to package atst.ecs, once the ECS installation is complete. (for details see [AD 6]).

8.7 OVERVIEW OF ECS USE OF ABPLC TO COMMUNICATE WITH EMCS

This section gives an overview of all communications occurring between ECS and EMCS based upon controllers’ lifecycle state and current tracking mode. The number of open connections to the EMCS PLC is dependent upon the current lifecycle state of the ECS sub-controllers (as contained in atst.ecs package described in section 8.6), and the ECS tracking mode state of the tracking sub-controllers.


Table 3 shows the open connections, its columns represent the following:

Command / Configuration – identifies the command or configuration that initiates a change to the number of open PLC connections. E.g. when the startup command is received the ECS sub-controllers begin reading their cStatus data from the EMCS and so connections are opened to begin retrieving this data.

Controller – identifies the controller that the connection is opened/closed for.

Operation – describes the operation for which the connection is opened/closed.

Con. Op. – gives the total number of connections opened by this operation.

Con. Cl. – gives the total number of connections closed by this operation.

Total Op. Con. – gives the total number of open connections currently in use.

Command / Configuration

Controller Operation Con. Op.

Con. Cl.

Total Op. Con.

startup atst.tcs.ecs.alt Start read of 1Hz (alt, az and emcs) or 0.1Hz (aux and cover) hardware status data.

1 0 1

atst.tcs.ecs.az 1 0 2

atst.tcs.ecs.aux 1 0 3

atst.tcs.ecs.cover 1 0 4

atst.tcs.ecs.emcs 1 0 5

atst.tcs.ecs.alt Start read of 20Hz current position data.

1 0 6


ECS mode = off atst.tcs.ecs.alt Single write of tag containing position demand.

1 1 7


ECS mode = active

atst.tcs.ecs.alt Single write of tag containing position demand.

1 1 7


ECS mode = tracking

atst.tcs.ecs.alt Start write of 20Hz trajectory stream data.

1 0 8


ECS mode = off when cMode = tracking

atst.tcs.ecs.alt Stop write of 20Hz trajectory stream data.

0 1 8


shutdown atst.tcs.ecs.alt Stop read of 20Hz current position data.

0 1 6


atst.tcs.ecs.alt Stop read of hardware status data.

0 1 4


atst.tcs.ecs.aux 0 1 2

atst.tcs.ecs.cover 0 1 1

atst.tcs.ecs.emcs 0 1 0

Table 3 Open EMCS PLC Connections Based On Controllers’ Lifecycle State and ECS Tracking Mode

As shown in Table 3, during normal observing operations the maximum number of open connections to the EMCS PLC is 9. This is well within the 128 maximum open connections the Allen-Bradley 1756-EN2T EtherNet Interface Module can accept. In addition to connections opened and closed due to the startup/shutdown commands, and change to ECS tracking mode, connections are also opened and closed when certain configurations are submitted.


If a configuration requires a change to enclosure hardware state, other than to position the tracking mechanisms, this results in a write to the EMCS PLC to command it to change the hardware’s state. E.g. if a configuration is submitted to open the aperture cover, the atst.tcs.ecs.cover sub-controller opens a new connection, through its connection object, to send the command to EMCS to open cover. Once this has completed the connection is closed. It is not expected that there will be many such commands happening simultaneously. Moreover, once observing is underway there will be none, as all hardware moved by such operations will be configured before the start of observing. Therefore the number of open connections will remain constant during observing. The following sections give more details of how the abplc package is used to achieve various enclosure operations, including the sequence of events that cause data to be read and written from/to the PLC.


9 S E QU E NC E D I AG R AM S

This section of the document contains the ECS sequence diagrams illustrating how the design detailed in the previous section performs the behavior described in the use cases detailed in section 7. In order to minimize duplication in the diagrams there is not a direct one-to-one relationship between use cases and sequence diagrams, for example many use cases require to read and write PLC tags from/to the EMCS; the same sequence has not been reproduced to depict this for every use case requiring this behavior. The use cases applicable to a sequence diagram are listed in the diagram’s descriptive text.

9.1 ECS SUB-CONTROLLERS USE OF ABPLC TO OPEN CONNECTIONS TO THE EMCS PLC

The ECS sub-controllers first open connections to the EMCS when they receive the startup command, at this time the controllers require to open connections to enable the reading of their hardware status. Additional connections are opened as required and if a connection is lost it will be re-opened. The sequence used when opening a connection between ECS and EMCS is shown in Figure 20. The actions described in this sequence are necessary for Use Case: Startup, see section 7.2.

Figure 20 ECS Open EMCS PLC Connection Sequence Diagram


9.2 ECS CONTROLLERS USE OF ABPLC TO READ HARDWARE STATUS AND CURRENT POSITION

All ECS hardware controllers require to read at a defined frequency the PLC tag containing the status of their hardware from the EMCS. In addition to this, ECS tracking mechanism controllers also require to read the current position tag at a defined frequency. The tags' names and the frequency they are read are contained in the property DB (see 8.2). When the controller’s doStartup() method is called by CSF at startup it calls its connection's startPlcTagReaders() method. This opens a connection to the EMCS PLC that will be used to read the tag (see previous section). Once the connection is open a PlcTagReader thread is created and started to begin the periodic reading of the tag, thread configuration (e.g. period, enabled status, etc.) are obtained from the property DB. All hardware controllers carry out this processing to begin and continue reading of their PLC hardware status tag containing data for their cStatus event. The tracking controllers additionally carry out this processing to begin and continue reading their PLC current position tag containing data for their cPos event. In order to be notified of a read of the current position the ABPlcioConnectionTracking class on creation of the PlcTagReader (used to read the position) passes to it a interrupt handler method to be called each time the tag is read. The interrupt handler called is responsible for setting the controller's in position status based upon current position contained in the read tag. The process used to read both the hardware status and current position tags is the same, with the sole addition of call to interrupt handler when current position is successfully read. This sequence fulfils actions necessary during Use Case: Startup, see section 7.2. All data read from the tags is placed into the controller's cache. The getEventTable() methods of the posting TAB responsible for posting the component’s cStatus event obtain the data for their event table from the component's cache. Likewise the additional posting TAB of the tracking mechanism controllers, responsible for posting the cPos event, obtain the data for their event table from the cache. In this manner the cStatus data, and if applicable the cPos data, are obtained from the EMCS and published in events. The ECS management controller obtains the data for its atst.tcs.ecs.cPos event by calling get() on its sub-controllers to retrieve their cached values that are then placed in the event’s attribute table before it is posted. The sequence diagram for reading of the current position tag as used by tracking mechanisms' connection is shown in Figure 21, this includes information regarding setting of a controller's .inPosition status attribute published in the tracking mechanism controller's cStatus event.


Figure 21 ECS Periodic Read of PLC Tag Sequence Diagram


9.3 ECS TRACKING SUB-CONTROLLERS CONTROL OF ENCLOSURE TRACKING MECHANISMS

The sequence diagram showing the ECS interactions to start tracking and process TCS trajectory events, including sending them to the EMCS, is shown in Figure 22. As noted in the diagram the ECS does not complete a configuration demanding a mode of tracking until the mechanism is in position, however to show that trajectory callback receipt operates independently of configuration processing the return from the submit is shown without connection to the configuration processing. This diagram shows the sequence of events necessary for Use Case: Tracking, see section 7.4, which is also used in Engineering Use Case: Calibrate Enclosure Tracking Mechanisms, see section 7.13.5.

Figure 22 ECS Tracking Using Connection Sequence Diagram


9.4 ECS TRACKING SUB-CONTROLLERS ACTIONS WHEN TCS RECEIVES A NEW TARGET

Figure 23 shows the sequence diagram of the ECS when the TCS receives a new target. The actions are those necessary for Use Case: TCS Receives New Target, see section 7.6.

Figure 23 TCS Receives New Target Sequence Diagram


9.5 ECS COMMANDS ENCLOSURE HARDWARE, E.G. MOVING APERTURE COVER

Figure 24 shows the sequence diagram of an ECS controller demanding enclosure hardware movement. The example shown is the closing of the aperture cover; however a similar sequence is used by any controller demanding an atomic action of enclosure hardware, e.g. the same sequence is carried out to open and close the aperture cover, the only change is to the .pos attribute value passed in the configuration submitted by the operator. The actual connection class used and therefore connection interface method called to demand the hardware movement is dependent upon controller. The demanding of enclosure hardware into the default state at startup, shutdown, and on interlock, will also be carried out using this sequence. This sequence shows part of the operations necessary for the Use Case: Stop Observing, see section 7.9.

Figure 24 ECS Open/Close Aperture Cover Sequence Diagram


9.6 ECS ENTERING AND LEAVING THE ZENITH BLINDSPOT

Figure 25 shows the sequence diagram of the ECS entering and leaving the zenith blind spot. These actions are those necessary for Use Case: Zenith Blind Spot, section 7.7.

Figure 25 ECS Enters Zenith Blindspot Sequence Diagram


9.7 ECS CONTROLLER ACTIONS WHEN INTERLOCK BECOMES ACTIVE

Figure 26 shows the sequence diagram when an ECS interlock becomes active. The sequence shows the actions occurring when an overall enclosure interlock first becomes active and how this is recognized in an ECS controller. The same sequence will occur if a sub-controller’s individual enclosure hardware interlock attribute becomes true. These actions are those necessary for Use Case: Interlock Event, see section 7.8. When a controller recognizes an interlock is active it must set its enclosure hardware into the default state, as stored in the property DB (see section 6.9), the sequence used to command enclosure to assert the default state is shown in section 9.5.

Figure 26 ECS Interlock Becomes Active Sequence Diagram


9.8 ECS TRACKING SUB-CONTROLLER MOVE TO NAMED POSITION

Figure 27 shows the sequence diagram of the ECS moving to a named position such as stow or a service position. The actions shown in this sequence are those necessary for Use Case: Stow Tracking Mechanisms (see section 7.10) and Engineering Use Case: Move to Fixed Position (see section 7.13.1).

Figure 27 ECS Moving to Named Position Sequence Diagram


9.9 ECS TRACKING SUB-CONTROLLER MOVE AT CONSTANT VELOCITY

Figure 28 shows the sequence diagram of the ECS moving a tracking mechanism at constant velocity. This occurs when a tracking mechanism controller receives a configuration containing the .jogVel attribute. The sequence also shows the stopping of the constant velocity move by the submitting of a configuration containing the .mode attribute with value equal to ECS tracking mode Off. This sequence shows the actions necessary for Engineering Use Case: Constant Velocity Move, see section 7.13.3.


Figure 28 ECS Moving Tracking Mechanism at Constant Velocity Sequence Diagram


1 0 E C S JAVA E NG I NE E R I NG S C R E E NS

The ECS includes JES screens that enable complete control and monitoring of the system and its components. This includes all control and monitoring of the ECS and enclosure hardware that is available through the TCS to ECS ICD 4.4/5.6 [AD 3]. In addition to this all control and monitoring of the enclosure hardware that is available to the ECS through the EMCS to ECS ICD 5.0/5.6 [AD 4], is also accessible through the screens. There is also a display showing the enclosure interlock attributes currently being received in the interlock event from the GIS, as described in OCS to GIS ICD 4.2/4.5 [AD 5]. The ECS Final as-built screens, there capabilities and use are fully documented in the ECS Operations & Maintenance Manual [AD 6]. Routine operations, e.g. the startup and shutdown of individual controllers, the setting of the current ECS tracking mode, the submitting of configurations to move to a specific position, etc. are made available directly through graphical widgets. However, these operations and all others available through the ECS are also accessible through free-entry widgets to set attributes and submit configurations. Likewise general interest status, e.g. current lifecycle and health state of components, current position, current hardware status, etc, are displayed directly on the screens and updated at suitable frequency.


1 1 S I M U LATI ON

Simulation of the ECS and enclosure hardware is required for the following purposes:

Interface Simulation – to enable the developers of other ATST systems (e.g. TCS) to operate without having access to the real ECS or enclosure hardware. This requires a simulator that correctly simulates all interfaces the ECS presents to the other ATST systems, namely the TCS to ECS ICD 4.4/5.6 [AD 3].

Hardware Simulation – to enable development and testing of the ECS while all or some enclosure hardware systems are not available. This requires a simulator that conforms to the interface of the ECS with the EMCS, namely ICD 5.0/5.6 [AD 4], and as far as is possible in programming and time constraints, faithfully reproduces the EMCS behavior. E.g. the writing of a PLC tag by the ECS to the hardware simulator causes the same changes to values of PLC tags read from the EMCS as does the real hardware.

Provision of a hardware simulator or EMCS simulator, also enables use of the real ECS with other ATST systems in order to carry out interface testing, without requiring access to enclosure hardware. To users of the ECS the interactions made when using the real EMCS or the EMCS simulator are identical. Providing an enclosure simulator is requirement 5.6-1405 of the ECS Specification SPEC-0082 [AD 1]. An ECS interface simulator, which faithfully adheres to the TCS to ECS ICD, has been produced by OSL under the TCS development contract. Described here is the design of the EMCS simulator and provision for its use within the ECS. It is based upon the virtual PLC that is included in the PLCIO C library (see section 8.1.1) and is therefore termed the Virtual EMCS.

11.1 THE VIRTUAL EMCS

The Virtual EMCS (VEMCS) is the name given to the software designed to provide simulation of the EMCS and enclosure hardware, and present this through the defined EMCS to ECS ICD 5.0/5.6 [AD 4]. The VEMCS has two parts:

1. The C code implementing the PLCIO communications module that replaces the PLCIO CIP module, which is used when communicating with the real EMCS. The module is called vemcs. No changes are made to PLCIO code, only the additional and standalone vemcs module is implemented. The PLCIO API used by the ECS remains the same ensuring all ECS software remains the same when using the VEMCS, apart from the connection address passed to the PLCIO plc_open() function. When connecting to the real enclosure EMCS PLC the ECS hardware controller's connection properties are configured with connection simulation property set to false, this ensures the controller's connection connects to the real EMCS using the IP address also obtained from property DB. When connection's simulation property is set true the connection's address is set to vemcs, which when passed as address parameter in call to PLCIO plc_open() ensures that a connection is made to the ECS VEMCS PLCIO communication module vemcs.

2. The Java CSF controller providing the actual hardware simulation of the simulator. Implementing the simulator as a CSF controller enables the simulator to take full advantage of


all the capabilities available to CSF controllers, e.g. submitting configurations, using scripts, JES screens, logging, etc. The CSF VEMCS controller is atst.tcs.ecs.vemcs.

Following the example of the PLCIO virtual PLC module, current values of all PLC tags contained in the VEMCS, i.e. as defined in the EMCS to ECS ICD, are stored in binary data files on the computer running the VEMCS. Using this method enables the VEMCS to act like real hardware in that it remembers and recovers the same hardware state between runs with the ECS. The atst.tcs.ecs.vemcs controller is notified when the ECS opens/closes a connection and when a tag has been written to the VEMCS through its use of the Java 7 Watch Service API. This API provides methods to watch the contents of a directory and be notified when any file changes are made (i.e. when a file is created, deleted or modified). The vemcs module and atst.tcs.ecs.vemcs controller use a well known location for the tag binary data files used by the simulator and it is the directory containing the write tags’ binary data file that is watched using the Watch Service API. Figure 29 shows a diagrammatic comparison between the software used when operating with the real EMCS and the virtual EMCS.

Figure 29 Comparision between EMCS and VEMCS software operating structure

11.1.1 Design and Implementation of the VEMCS PLCIO Module

The VEMCS PLCIO module vemcs is developed from the PLCIO virtual PLC module and is written in C. The software is contained in the ECS package plciovemcs. It implements the functions called internally by PLCIO when the PLCIO API functions plc_open(), plc_close(), plc_read(),


plc_write() and plc_validaddr() are called to communicate with the PLC. In vemcs these functions do the following:

plc_open() – creates a file in well known (between vemcs module and atst.tcs.ecs.vemcs controller) directory used as location of VEMCS write tag binary data files. The controller is watching this directory using the Java 7 Watch Service and is notified of the file creation. The name of the file created uses a well known format from which the controller can determine the number of connections now open to the VEMCS. The number of connections opened is used to ensure the ECS always closes connection to the PLC when it is shutdown. This function also initializes some internal structures used by the module.

plc_close() – deletes the file created in call to plc_open(), the atst.tcs.ecs.vemcs controller is notified of this through the Watch Service and decrements the number of open channels by 1. When the ECS is shutdown the number of open connections should be zero, if this is not the case than the ECS is not operating correctly. In this way the VEMCS can be used to test for correct ECS behavior not available when using the real EMCS. This function also destroys the internal structures created in plc_open().

plc_read() and plc_write() – the call to either of these PLCIO API functions results in the vemcs function plc_readwrite() being called. The initial behavior of this function is the same irrespective of whether a PLC tag is to be read or written, this is:

o Check that the PLC tag requested to be read or written is a valid PLC tag, i.e. has a tag name recognized by the module. The module only recognizes the tag names as defined in the EMCS to ECS ICD 5.0/5.6 [AD 4]. An error is returned if the tag name is not valid, this is the same behavior as occurs with the real EMCS if an attempt to address an unknown tag is made to the PLC.

o Check the number of bytes requested to be read or written is not greater than the defined size of the PLC tag. An error is returned if the byte size requested is too large. Again, this behavior mimics the behavior of the real EMCS.

o Software structures are opened and initialized to enable access to the tag’s binary data file stored on the computer running the VEMCS.

The function then proceeds to read or write the tag as requested: o When reading a tag the current value of the tag is retrieved from the tag’s binary data

file and returned to the ECS, using the same process as is used when connected to the real EMCS.

o When writing a tag the new value of the tag (passed to the function as an input parameter) is written to the tag’s binary data file. The VEMCS controller atst.tcs.ecs.vemcs is notified of the write through the Java Watch Service. This is the signal to the controller to execute any simulation required to update values of other (read) tags based upon the new value of the tag written (see the following section 11.1.2).

The function completes by closing the software structures opened to complete the read or write.

plc_validaddr() – this function checks that the PLC tag name passed as an input parameter is a valid tag name contained in the VEMCS, if this is not the case an error is returned.

Any errors returned by the above functions of the vemcs module are passed back to the ECS using the same PLCIO error structure that occurs when using the real EMCS. The PLC tags of the vemcs module are defined in a single header file. Any changes to the EMCS to ECS ICD only require a change to the definitions in this header file.


11.1.2 Design and Implementation of the VEMCS CSF Java Controllers

The hardware simulation of the VEMCS takes place in the CSF controller atst.tcs.ecs.vemcs and its sub-controllers. The atst.tcs.ecs.vemcs is the management controller of the VEMCS and is implemented in the Java class VirtualEmcs that extends the CSF MagmentController class. This is the only class using the Java 7 Watch Service to receive notification of file changes made by the vemcs PLCIO module. When it receives notification of a write to a PLC tag it submits a config to its sub-controller responsible for simulating the hardware actions necessary, i.e. updating the associated hardware status to show the hardware has been moved as demanded in the write tag. This and other classes of the implementation are contained in the ECS package vemcs. The classes of this package are shown in Figure 30.

Figure 30 Class Diagram of the VEMCS Controller.


11.1.3 VEMCS Support for User Interactions and ECS Testing

As the atst.tcs.ecs.vemcs is a CSF controller all support and tools offered to CSF controllers are available to atst.tcs.ecs.vemcs. This includes the ability to control it using scripts and JES screens. Using these methods the simulator is used as an instrument for testing the correct behavior of the ECS, both in regards to when the hardware is functioning correctly, and to test how it reacts when the hardware does not function correctly, .e.g. status returned from the hardware does not show demands from the ECS have been completed successfully. The ability of interacting with the simulator using scripts enables such testing to be automated. JES screens are also provided that enable the modification of all PLC read tag data contained in the simulator (i.e. all PLC read tags of the EMCS to ECS ICD) and the motoring of all PLC write tags as received from the ECS.

11.2 TCS SIMULATION REQUIRED BY THE ECS

The ECS subscribes to the TCS trajectory event published by the TCS as defined in the TCS to ECS ICD 4.4/5.6 [AD 3]. The ECS obtains the trajectory stream for its tracking mechanisms from this event, see section 6.14. To enable testing of the ECS without access to a running TCS a JES widget has been created that publishes the trajectory event. This widget is shown in Figure 31 and shall be incorporated into the VEMCS JES screens.

Figure 31 TCS Simulated Trajectory Stream JES Widget

At widget creation the event channel on which the trajectory stream is posted can be configured. The widget contains controls to select the Type of demand required, either Fixed Demand, Ramp or Sine Wave. In the Parameters section of the widget the coefficient attribute names contained in the event can be set; in the above screen-shot they have been given the values azCoeff and altCoeff as defined in the TCS to ECS ICD. The other controls visible in the Parameters section depend upon the type of demand selected. The Controls section of the widget contains buttons to Start and Stop the event and also to create a new track ID that will be posted with the coefficients in the event.


11.3 GIS SIMULATION REQUIRED BY THE ECS

In addition to the TCS the only other external system that the ECS subscribes to events from is the GIS event of the OCS. The ECS subscribes to the interlock event originating from the GIS that contains the enclosure interlock attributes as described in OCS to GIS ICD 4.2/4.5 [AD 5]. The enclosure interlock attribute values are set to true when the GIS is notified of an interlock by the enclosure LIC. To test ECS behavior when notified of an active enclosure interlock the CSF component InterlockPoster has been developed. The InterlockPoster component is contained in the ECS source code CVS module's test directory, that also contains its .prop file and CSF Testharness scripts that can be used to load and unload the component. To trigger the component to raise and lower interlocks the component properties are updated using the set command. In this way the InterlockPoster component can be used from within ECS acceptance and unit test python scripts, see section 12 Testing. When triggered to raise an interlock the component produces an interlock event at the same frequency as the GIS enabling the presence of one or more active interlocks to be simulated. When an attribute is set true the ECS is required to perform its interlock active behavior, see section 5.4.


1 2 TE S TI NG

The ECS Acceptance Test document [AD 7] includes all tests to ensure the ECS meets the requirements specified in [AD 1]. Moreover, the test document includes software unit tests to ensure thorough testing of ECS source code. For tests that can be automated the ECS uses a testing framework of a similar structure as that developed and used by the TCS. Testing is carried out by executing python scripts using the scripting facilities available as part of the CSF, which contains a jython interpreter and therefore gives direct access to all CSF services. For full details see the Testing section of [RD 6]. All software used to carry out testing shall be supplied as part of ECS delivery; this is requirement 5.6-1400 of the ECS Specification SPEC-0082 [AD 1].


1 3 C OM P LI ANC E M ATR I X

The matrix in Table 4 shows how each of the requirements of the ATST ECS Specifications [AD 1] is addressed in this design.

No. Requirement Reference Comment

Overview

5.6-0010 Scope 1 This document refers to the design of the ECS software only; other requirements of Scope shall be met elsewhere.

5.6-0020 Basic Requirements 4, 5, 6, 7,

5.6-0030 Best Software Practices 4.4, 4.5, 6

5.6-0040 Control 6.7, 6.14, 7, 8.1

5.6-0050 Default State 4.2, 6.9, 7.2, 7.8, 7.12, 8.2

5.6-0060 Restart 6.4.3, 6.4.6,7.2

5.6-0070 Health 6.10

5.6-0080 Logging 6.12

5.6-0090 Availability 6.3, 6.4

5.6-0095 Persistence of Data 6.8

Enclosure Mechanical Requirements

5.6-0100 Range of Travel 6.16, 8.6.2

5.6-0110 Zenith 7.7, 9.6

5.6-0120 Rate of Travel – The ECS does not control enclosure mechanisms’ rate of travel – velocity loops are closed in the EMCS. For details see the EMCS Functional Design document [AD 8].

5.6-0130 Pointing 5.2, 6.14, 7.3, 7.6, 8.6.2, 9.3, 9.4

5.6-0140 Tracking and Following 5.2, 6.14, 7.3, 7.6, 8.6.2, 9.3, 9.4

5.6-0150 Slewing 5.2, 6.14, 7.3, 7.6, 8.6.2, 9.3, 9.4

5.6-0160 Position Offset 7.13.2

5.6-0170 In Position 6.15, 7.3, 7.6, 8.6.2

Servo Systems Requirements

5.6-0210 Status Information 5.2, 6.17.3, 8.6, 9.2

5.6-0220 High-Speed Status Information

– This shall be carried out within the EMCS independently of the ECS. For details see the EMCS Functional Design document [AD 8].

Ancillary Mechanical Systems Requirements



5.6-0400 Dome cranes 6.7, 8.6.3

5.6-0410 Cable Wraps 6.7, 8.6.2 The ECS shall not control the cable wrap servo system and brakes as this shall be the responsibility of the EMCS. The ECS shall however monitor cable wrap position and limit sensors.

5.6-0420 Entrance Aperture Cover

6.7, 7.5, 8.6.4, 9.5

5.6-0430 Carousel Entrance Aperture Plate

1 Requirement states “If a carousel entrance aperture plate is used…”, as explained in section 1, it is expected that a moving aperture plate shall not be used. If used the software to control it will follow the same design of the other tracking mechanisms (azimuth carousel and altitude shutter).

Performance Requirements

5.6-1000 Time to Accept or Reject Command

6.1 Configurations are required to be accepted or rejected within 0.1 seconds. This shall be tested during acceptance

5.6-1005 Boot Time 4.1 The ECS is required to boot and act on configuration within 5 minutes of a cold power-off start of its hardware. This shall be tested during acceptance.

5.6-1010 Application of Information

6.1, 6.2 The ECS is required to apply changes due to external information received by configuration or events within 0.1 seconds. This shall be tested during acceptance.

5.6-1015 Contributions to the Error Budget

6.14, 8.6.2, 9.3 Demands sent to the EMCS to position the enclosure will be calculated from TCS trajectory data that provides sub-milliarcsecond accuracy. Demands sent to the EMCS shall be at resolution that ensures positioning capabilities of hardware are fully utilized.

5.6-1020 Computer Resources 4.2, 6.7 The ECS design makes extensive use of the CSF, and is of a size (in CSF components) that places no greater burden on computer resources than other ATST systems. Therefore expectation can be high that the ECS shall not consume more computer resources than any other ATST system.

Operational and Interface Requirements

5.6-1200 Telescope Control System

5.1, 5.2, 7.3, 7.5, 7.6, 7.9, 8.6, 9.3, 9.4, 11.2

The TCS to ECS ICD 4.4/5.6 [AD 3] is referenced extensively throughout this document.



5.6-1210 Common Services Framework

4.5, 6.1, 6.2, 6.3, 8.5, 8.6

5.6-1220 Global Interlock System

5.1, 5.4, 7.8, 9.7, 11.3

5.6-1230 Ethernet on the Control LAN

4.2, 8.1

5.6-1250 Configuration Identifiers

6.1, 6.7

5.6-1300 Engineering Display 6.13, 10

5.6-1305 Time Standard 4.2, 6.14

5.6-1310 Engineering Operations

6.13, 7.13, 9.9, 10

Other Requirements – Acceptance Testing

5.6-1400 Test Software 11.2, 11.3, 12

5.6-1405 Simulation 11

Other Requirements – Documentation

5.6-2000 Final Design See this document

5.6-2010 Public Interfaces The ECS public interfaces are documented in TCS to ECS ICD 4.4/5.6 [AD 3], and EMCS to ECS ICD 5.0/5.6 [AD 4].

5.6-2020 Operator’s Manual The statement of work calls for a draft version of the Software Operations Manual at FDR [AD 6].

Safety Requirements

5.6-3000 Respond to Global Interlock

5.1, 5.4, 7.8, 9.7, 11.3

5.6-3010 Hazard Analysis 5.4, 7.8, 9.7, 11.3

The ECS as a system completely implemented in software can have no responsibilities for the absolute prevention of hazards, though it will use input from the GIS to ensure inappropriate commands are not sent to the EMCS when interlocks are present.

Table 4 Compliance Matrix

atst ecs software design description · enclosure design services for the advanced technology solar...

Documents