atst ecs operations & maintenance manual · enclosure design services for the advanced...

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

Enclosure Control System Operations & Maintenance Manual

IDOM Doc. N.: 15812-MAN-074 Issue: 5.3 Date: March 25th 2014

Contract No: C22019N

Name Signature Date

Written Alastair Borrowman

Mar. 25th 2014

Revised Lander de Bilbao

Mar. 26th 2014

Project Manager Gaizka Murga

Mar. 26th 2014

Principal Tom Lorentz

Mar. 26th 2014

File: 15812-MAN-074-5_3_ECS_Manual Pages: 89

15812-MAN-074-5_3_ECS_Manual.docx; March 25th 2014 2/89

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.

2.1 January 12th 2012 4 Quick Start Guide 5.2.3 Obtaining and Installing the Pre-build PLCIO Libraries 5.2.5.1 Contents of ECS atst/src/java/ atst/ecs 5.2.6 Building the ECS 6.1 Application Configuration 6.2 Controller Configuration 10 Virtual EMCS Simulator APPENDIX A

Aligned with EMCS software simulator release. Software released January 11th 2012 with CVS tag EMCS_Sim_ECS_v0_1.

3 September 28th 2012 All Updated to align with ECS Alpha release.

4 February 8th 2013 All Updated to align with ECS Beta release.

5 June 28th 2013 All Updated to align with ECS Final release.

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

4.5 Building the ECS Software 5.2.6 Building the ECS 11 Virtual EMCS Simulator Appendix A. ECS Software CVS Checkout and Build Script

Remove all reference to the ECS script ecsMkdir as directories used by the VEMCS simulator to store PLC tag binary data files are now created programmatically (if not already present) at VEMCS startup. (ATST JIRA issue ATECS-27.)


Add sections 4.5.1 and 5.2.7

Describe additional steps required when upgrading from a previous ECS release, i.e. removal of old VEMCS simulator PLC tag binary data files. (ATST JIRA issue ATECS-26.)

6.2 Controller Configuration

Add table containing the atst.tcs.ecs configurable property.

In tables containing atst.tcs.ecs.alt and atst.tcs.ecs.az configurable properties:

Note the limit named positions :limitLo and :limitHi equate to EMCS soft-limits and :limitLoLo and :limitHiHi equate to EMCS end-of-travel limits.

add the .inPosToleranceTime property.

7.1 Startup Script

Add note explaining that startup failure message displayed by Testharness is to be expected.

7.4 ECS Conflicting Attributes

In table Conflicting attributes of atst.tcs.ecs.alt and atst.tcs.ecs.az controllers add row describing that when tracking the submitted .trackId cannot equal the currently in use (previously submitted) configuration trackId. (Action item ECS FAT).

7.5 ECS Health In ECS Health Categories table add descriptions of categories ECS_Mode_Mismatch and EMCS_PLC_Time.

8.3.1 ECS Main screen on startup

Update ECS Main screen screen-shot and description.

8.3.3 ECS Main screen Lifecycle and Health tab

Update description of tab's contents to include connection simulation status display and ECS Engineering and VEMCS screen buttons.

8.3.4 ECS Main screen Altitude Shutter tab

Update screen-shot and description of tab's contents to include table containing demands sent to EMCS.

8.3.5 ECS Main screen Azimuth Carousel tab

Update screen-shot.


8.3.7 ECS Main screen Auxiliary Equipment tab

Update screen-shot.

8.3.8 ECS Main screen EMCS tab

Update screen-shot and add information regarding EMCS PLC clock time.

5.2 November 29th 2013 1 Scope Update to reference ECS Final release version 1.2.

4.5.1 & 5.2.7 Upgrading from Previous ECS Releases.

Update VEMCS tag binary data file directory information. Previously files were stored under /var/tmp/atstEcs, they are now stored under $ATST/resources/ecs.


Update ECS Main screen screen-shot to show

on Lifecycle and Health tab the addition of

interlock status information obtained from the EMCS PLC.

8.3.2 ECS Main screen GIS Interlock and EMCS Local Control Status

Update description to make clear the difference between interlock information obtained from the GIS and interlock status obtained from EMCS PLC.


Update description to including information relating to the display of interlock status obtained from the EMCS PLC.

8.3.6 ECS Main screen Apeture Cover tab

Update screen-shot and description to include additional motor drive status information now available in the atst.tcs.ecs.cover.cStatus event.

8.3.8 ECS Main EMCS tab

Update screen-shot and description to include EMCS PLC high speed data acquisition control and data display information.

8.4.1 ECS Engineering AZIMUTH screen

Update screen-shot.

8.4.2 ECS Engineering ALTITUDE screen

Update screen-shot.


8.4.3 ECS Engineering AUXILARAY EQUIPMENT screen

Update screen-shot.

8.4.4 ECS Engineering APERTURE COVER screen

Update screen-shot.

8.4.5 ECS Engineering DATA screen

Update screen-shot showing Auxiliary Equipment controller's status PLC tag.

11 Virtual EMCS Simulator

Update details regarding location of VEMCS tag binary data files. Previously files were stored under /var/tmp, they are now stored under $ATST/resources/ecs.

5.2 March 25th 2014 1 Scope Update to reference ECS Final release version 1.3.

6.2 Controller Configuration

In Table 13 ECS Altitude Shutter Controller atst.tcs.ecs.alt Properties, add property .trajectoryLowerLimit and update saved values of properties .trackingPosDemandPeriod, .sealPressureDeflated and .sealPressureInflated. In Table 14 ECS Azimuth Carousel Controller atst.tcs.ecs.az Properties, update saved value of properties .trackingPosDemandPeriod. In Table 16 ECS Aperture Cover Controller atst.tcs.ecs.cover Properties, update saved values of properties .sealPressureDeflated and .sealPressureInflated.

11.2 VEMCS Configuration

In Table 31 VEMCS Altitude Shutter Controller atst.tcs.ecs.vemcs.alt Properties, update saved values of properties .sealPressureDeflated and .sealPressureInflated. In Table 33 VEMCS Aperture Cover Controller atst.tcs.ecs.vemcs.cover Properties, update saved values of properties .sealPressureDeflated and .sealPressureInflated.


ABBREVIATIONS Acronyms and abbreviations of terms used in the ECS are described below, for a more complete list as used by ATST see [RD 1]. AD Applicable Document API Application Programming Interface ASDT ATST Software Development Tree ATST Advanced Technology Solar Telescope CIP Common Industrial Protocol CLX ControlLogix CM Container Manager (part of ATST CSF software) COTS Commercial, off-the-shelf CSF Common Services Framework CVS Concurrent Version System cw clockwise ccw counter-clockwise 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 Interface LIC Local Interlock Controller 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 TBD To Be Decided TCS Telescope Control System TMA Telescope Mount Assembly VEMCS Virtual EMCS


TABLE OF CONTENTS

1 SCOPE ........................................................................................................................................ 10

2 APPLICABLE AND REFERENCE DOCUMENTS ................................................................ 11

2.1 APPLICABLE DOCUMENTS .....................................................................................................................................11

2.2 REFERENCE DOCUMENTS .....................................................................................................................................11

3 INTRODUCTION ..................................................................................................................... 12

3.1 STYLISTIC CONVENTIONS .....................................................................................................................................12

4 QUICK START GUIDE ............................................................................................................. 14

4.1 SETTING $ATST AND $PATH .............................................................................................................................14

4.2 ADDITIONS TO SITE.CONFIG ................................................................................................................................14

4.3 PLCIO LIBRARY .....................................................................................................................................................14

4.4 OBTAINING ECS SOFTWARE PACKAGES FROM CVS ......................................................................................15

4.5 BUILDING THE ECS SOFTWARE ..........................................................................................................................15 4.5.1 Upgrading from Previous ECS Releases ................................................................................................................16

4.6 LOADING THE ECS APPLICATION DATA ..........................................................................................................16

4.7 ENSURING ECS PROPERTY DB ENTRIES ARE CONSISTENT .........................................................................16

4.8 RUNNING THE ECS FROM THE TESTHARNESS .................................................................................................17

4.9 STARTING THE ECS ENGINEERING SCREENS ..................................................................................................17

4.10 ISSUING COMMANDS TO THE ECS ......................................................................................................................18

5 INSTALLING THE ECS ........................................................................................................... 19

5.1 PREREQUISITES .......................................................................................................................................................19 5.1.1 CSF Installed ........................................................................................................................................................19 5.1.2 PLCIO Installed and Configured ..........................................................................................................................19 5.1.3 Network Configuration ..........................................................................................................................................20

5.2 INSTALLATION FROM CVS....................................................................................................................................20 5.2.1 Environment Variables $ATST and $PATH ....................................................................................................20 5.2.2 Configuration of site.config ......................................................................................................................................20 5.2.3 Obtaining and Installing the Pre-built PLCIO Libraries ......................................................................................21 5.2.4 Obtaining the ECS Source Code ...........................................................................................................................22 5.2.5 Contents of ECS Source Code Directories ..............................................................................................................22 5.2.6 Building the ECS ..................................................................................................................................................28 5.2.7 Upgrading from Previous ECS Releases ................................................................................................................29

6 CONFIGURING THE ECS ...................................................................................................... 30

6.1 APPLICATION CONFIGURATION ..........................................................................................................................30

6.2 CONTROLLER CONFIGURATION .........................................................................................................................31

6.3 PLC TAG CONFIGURATION .................................................................................................................................39

6.4 FACTORY DEFAULT RESET...................................................................................................................................41

7 RUNNING THE ECS ............................................................................................................... 42


7.1 STARTUP SCRIPT .....................................................................................................................................................42

7.2 SHUTTING DOWN THE ECS ..................................................................................................................................42

7.3 ECS CONTROLLERS ...............................................................................................................................................43

7.4 ECS CONFLICTING ATTRIBUTES .........................................................................................................................43

7.5 ECS HEALTH ..........................................................................................................................................................45

7.6 ECS ALARMS ...........................................................................................................................................................47

8 USING THE ECS ENGINEERING INTERFACES .............................................................. 49

8.1 STARTING THE ECS ENGINEERING INTERFACES ...........................................................................................49

8.2 INTERACTING WITH THE ECS ENGINEERING INTERFACES ..........................................................................49

8.3 THE ECS TCS ENGINEERING INTERFACE .......................................................................................................49 8.3.1 ECS Main screen on startup .................................................................................................................................50 8.3.2 ECS Main screen GIS Interlock and EMCS Local Control Status .....................................................................52 8.3.3 ECS Main screen Lifecycle and Health tab ...........................................................................................................53 8.3.4 ECS Main screen Altitude Shutter tab .................................................................................................................53 8.3.5 ECS Main screen Azimuth Carousel tab ..............................................................................................................54 8.3.6 ECS Main screen Aperture Cover tab ...................................................................................................................55 8.3.7 ECS Main screen Auxiliary Equipment tab ........................................................................................................56 8.3.8 ECS Main screen EMCS tab ...............................................................................................................................57 8.3.9 ECS Main screen Generate TCS Trajectory tab....................................................................................................58

8.4 THE ECS EMCS ENGINEERING INTERFACE ...................................................................................................60 8.4.1 ECS Engineering AZIMTH screen .....................................................................................................................61 8.4.2 ECS Engineering ALTITUDE screen ................................................................................................................61 8.4.3 ECS Engineering AUXILARY EQUIPMENT screen ...................................................................................62 8.4.4 ECS Engineering APERTURE COVER screen ..............................................................................................63 8.4.5 ECS Engineering DATA screen ..........................................................................................................................63 8.4.6 ECS Engineering SYSTEM screen ......................................................................................................................65

9 USER SCENARIOS ................................................................................................................... 68

9.1 INTIALIZING THE ECS ..........................................................................................................................................68

9.2 STARTUP ...................................................................................................................................................................68

9.3 START TRACKING AND TRACKING .....................................................................................................................68

9.4 START OBSERVING .................................................................................................................................................68

9.5 TCS RECEIVES NEW TARGET ..............................................................................................................................69

9.6 ZENITH BLIND SPOT .............................................................................................................................................69

9.7 INTERLOCK EVENT................................................................................................................................................69

9.8 STOP OBSERVING ...................................................................................................................................................70

9.9 STOW TRACKING MECHANISMS ..........................................................................................................................70

9.10 STOP TRACKING MECHANISMS ...........................................................................................................................71

9.11 SHUTDOWN .............................................................................................................................................................71

9.12 ENGINEERING: MOVE TO FIXED POSITION .....................................................................................................71

9.13 ENGINEERING: OFFSETTING POSITION ............................................................................................................71


9.14 ENGINEERING: CONSTANT VELOCITY MOVE .................................................................................................72

9.15 ENGINEERING: MOVE TO EMCS LIMIT ...........................................................................................................72

9.16 ENGINEERING: CALIBRATE ENCLOSURE TRACKING MECHANISMS ............................................................72

10 TROUBLE-SHOOTING & DEBUGGING ............................................................................. 74

10.1 ECS CONTROLLER DEBUG LOG CATEGORIES ................................................................................................74 10.1.1 Controller Level Log Debug Categories .............................................................................................................74 10.1.2 Connection Level Log Debug Categories ...........................................................................................................76

10.2 ECS CONTAINER LOG DEBUG CATEGORIES ...................................................................................................78

10.3 TROUBLE-SHOOTING .............................................................................................................................................79 10.3.1 Configuration Processing ...................................................................................................................................79

11 VIRTUAL EMCS SIMULATOR ............................................................................................... 80

11.1 VEMCS CONTROLLERS ........................................................................................................................................81

11.2 VEMCS CONFIGURATION ...................................................................................................................................81

11.3 VEMCS STARTUP AND RUNNING ......................................................................................................................83

11.4 VEMCS JES SCREEN .............................................................................................................................................83

12 UNIT TESTING ....................................................................................................................... 86

12.1 UNIT TEST ENGINEERING SCREEN ....................................................................................................................86

APPENDIX A. ECS SOFTWARE CVS CHECKOUT AND BUILD SCRIPT ............................. 88


1 S C OP E

This document is the Operations and Maintenance Manual of the ATST Enclosure Control System (ECS) software. It defines the operational and maintenance procedures for operational and engineering use of the ECS software by staff of the ATST. The manual includes information on running the ECS in simulation mode when enclosure hardware is unavailable, including installation and use of the Virtual EMCS (VEMCS) simulator software. The operation and maintenance of all ATST Enclosure hardware is outside of the scope of this manual. The operation of enclosure hardware is only detailed herein where necessary to describe use of the software. The description of hardware use in this manual should not be

taken as instructions on the proper use of the hardware. The Enclosure Manual [AD 8] must be read and understood, and supersedes any instructions on hardware operations given in this manual. This version of the document has been prepared for the ECS Final release version 1.3. The ATST CVS repository release tag is ECS_final_v1_3_0, therefore in this manual's instructions detailing commands used to obtain the ECS software from the CVS repository this tag should be used to replace <ECS_RELEASE_TAG>. The ECS Final release version 1.3 is the ECS release prepared for and used during Enclosure Final Acceptance Testing (FAT) II in Bilbao during March 2014, with the addition of the implementation of altitude trajectory lower limit behavior as discussed in JIRA issue TCS-50.


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

APPLICABLE DOCUMENTS 2.1

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 Software Design Description

15812-SPEC-076-5_1

5.1 9 Aug 2013

AD 7 ECS Factory and Site Acceptance Test Plan

15812-TRE- 075-5_2

5.2 29 Nov 2013

AD 8 Enclosure Manual 15812-MAN-090

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

REFERENCE DOCUMENTS 2.2

Title Reference Iss. Date

RD 1 ATST Glossary and Acronym List SPEC-0012

H Mar 2011

RD 2 Java Engineering Screens User Manual TN-0089

B 10 Jan 2013

RD 3 CSF Tools TN-0120

C 29 Jun 2012

RD 4 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 how to operate and maintain the software that constitutes the ATST Enclosure Control System (ECS). Including how to configure and start it, and how to operate it from its engineering screens. The ECS is the control system of the ATST Enclosure and therefore cannot carry out its normal operational work without connection to the enclosure hardware. The ECS is connected to and controls the enclosure hardware through the Enclosure Mechanical Control System (EMCS). If the EMCS is not available the ECS can be run in simulation using the Virtual EMCS (VEMCS) simulator supplied with the ECS. For a complete description of the ECS context, deployment and design see the ECS Software Design Description [AD 6]. The intended audience of this document are:

The users and operators of the ECS who are to run and control it.

The engineers who may need to diagnose and inspect the system when it is not operational.

The reviewers of the ECS.

The developers of the TCS work package. The layout of this document is as follows; Section 4 contains the Quick Start Guide describing in a concise manner how the ECS can be installed, configured and started without describing the details of all actions necessary. Section 5 contains detailed instructions for installing, configuring and starting the ECS, including prerequisites required and how the software is built following a clean check-out from the ATST CVS repository. Section 6 details how the ECS is configured, including details of ECS entries in the application and property tables of the property DB. Also included are details of how to reset these entries to the ECS factory default settings. Section 7 contains Running the ECS instructions, including details of startup script provided. Following on, section 8 gives details of how to use the ECS Engineering Interface and the screens it provides for engineering operations. Section 9 contains the User Scenarios that contain step-by-step instructions on how each of the Use Cases described in the ECS Software Design Description [AD 6] may be accomplished using the provided ECS Engineering Interface. Section 10 contains tips on debugging and trouble-shooting the ECS. Section 11 contains instructions on how to configure and use the Virtual EMCS simulator, which enables full operation of the ECS when access to enclosure hardware is not available. The final section 12 Unit Testing contains instructions for running the ECS testing software.

STYLISTIC CONVENTIONS 3.1

The following styles are used in this document:

bold – in the text for commands, filenames, prefixes/suffixes as they must be typed.

italic – in the text for parts that must be substituted with the real content before being typed.

fixed width – for examples, database attribute names and other identifiers as used in the software.

<name>– in examples for parts that must be substituted with the real content before typing.

Arial Unicode – in the text to identify items as displayed on JES screens.


Bold and italic are also used throughout the text to highlight words.


4 QU I C K S TART G U I D E

The following sub-sections of the manual give a quick guide to installing, configuring and running the ECS application. The final sub-section demonstrates how to start the ECS engineering interface. The instructions do not explain any of the steps taken (as this is a quick start guide); a more thorough explanation is described in the later sections of the manual to which references are given.

SETTING $ATST AND $PATH 4.1

Ensure the environment variables $ATST and $PATH are correctly referencing the required ATST Software Development Tree (ASDT) containing the ATST Canary 5.2 patch 1 release cs and base packages: export ATST=<path to ASDT installation directory>

export PATH=$PATH:$ATST/bin

See section 5.2.1 for more details. NB. The Final release of the ECS has been developed and tested with CSF Canary 5.2 patch 1 obtained from the ATST CVS repository using the CVS tag Canary_5-2p1 and therefore it is expected the ASDT set as $ATST contains this version of the CSF.

ADDITIONS TO SITE.CONFIG 4.2

The ATST_PACKAGE_LIST directive of $ATST/admin/site.config should be updated to include the ECS software packages idom and ecs as well as base, e.g: ATST_PACKAGE_LIST="base idom ecs"

The ATST_JNI_PACKAGES directive of $ATST/admin/site.config must contain the package abplc, e.g: ATST_JNI_PACKAGES="abplc"

Apply any changes made to site.config using: cd $ATST

./admin/createDevel --init-data

See section 5.2.2 for more details.

PLCIO LIBRARY 4.3

The ECS uses the PLCIO library to communicate with the EMCS PLC. If not already available on the ECS computer a pre-built version may be used. A pre-built version is available in the following module that contains licensed software; its use requires a PLCIO runtime license (see section 5.2.3). To checkout the ECS Final release version of this module in the following checkout command replace <ECS_RELEASE_TAG> with ECS_final_v1_3_0.


cd $ATST/..

export CVSROOT=":pserver:<CVS user name>@maunder.tuc.noao.edu:/home/atst/src/idom"

cvs login

cvs co -P -r <ECS_RELEASE_TAG> atst

To install the library issue the following commands: cd $ATST

make gcc_all

See section 5.2.3 for more details regarding the idom CVS module. APPENDIX A contains a script including the above commands that may be used to CVS checkout and build all software of the ECS.

OBTAINING ECS SOFTWARE PACKAGES FROM CVS 4.4

The ECS software packages are contained within a CVS module located in the ATST CVS repository. To obtain the software use the following commands. To checkout the ECS Final release version of this module in the following checkout command replace <ECS_RELEASE_TAG> with ECS_final_v1_3_0. cd $ATST/..

export CVSROOT=":pserver:<CVS user name>@maunder.tuc.noao.edu:/home/atst/src/ecs"

cvs login


Following build of the idom module, described in the previous section, CVS messages of the following form are to be expected in output from above checkout: cvs checkout: existing repository /home/atst/src/base/CVSROOT/Emptydir does not

match /home/atst/src/base/atst

See section 5.2.4 for more details regarding the ecs CVS module. APPENDIX A contains a script including the above commands that may be used to CVS checkout and build all software of the ECS.

BUILDING THE ECS SOFTWARE 4.5

The building of the ECS software is done in three steps:

1. Build the VEMCS PLCIO library: cd $ATST/src/c++/atst/ecs/plciovemcs

make gcc_all

2. Build the ECS classes and JNI:

cd $ATST

make classes

make jni

3. Install the ECS scripts:

cd $ATST/src /java/atst/ecs/scripts make install_scripts


See section 5.2.6 for more details regarding the building of the ECS software. APPENDIX A contains a script including the above commands that may be used to CVS checkout and build all software of the ECS.

4.5.1 Upgrading from Previous ECS Releases

If the PC on to which the latest ECS release is being installed has previously been used to run earlier versions of the ECS the latest release should be installed following the above instructions, in addition the old VEMCS simulator binary data files (see section 11 Virtual EMCS Simulator) must be removed prior to running the new installation. This is done by removing the directories under which these files are stored using the following commands: rm -rf $ATST/resources/ecs/R_tagDataFiles

rm -rf $ATST/resources/ecs/W_tagDataFiles

See section 5.2.7 for more details regarding upgrading from previous ECS releases.

LOADING THE ECS APPLICATION DATA 4.6

For the ECS to function correctly the application tables contained in the Property DB must contain the correct ECS information. To ensure ECS application data are consistent with the current ECS release the currently loaded ECS application data can be removed and current data added using the following ECS scripts (note, for the following to work correctly the CSF ICE services must have been started; e.g. by running the CSF startIceServices script): cd $ATST

ecsAppRm

ecsAppLoad WARNING: the application data of the ECS is incompatible with the TCS’s ECS simulator application data. If following use of the ECS the TCS ECS simulator is to be used then all ECS application data must be removed from the Property DB, e.g. by using the above ecsAppRm script. Failure to do this will prevent the TCS ECS simulators from running. See section 6.1 for more details regarding the ECS application data. Section 6.4 gives details about removing all ECS application data from the property DB and reloading the factory default values.

ENSURING ECS PROPERTY DB ENTRIES ARE CONSISTENT 4.7

For the ECS to function correctly the property tables contained in the Property DB must contain the correct ECS information. To ensure ECS properties in the property table are consistent all currently defined ECS properties can be removed and current data added using the following ECS scripts: cd $ATST

ecsPropsRm

ecsPropsLoad

WARNING: if the ASDT contains the TCS application and its properties have been loaded into the Property DB then the ECS will not function without removing all atst.tcs.ecs properties (using the above script) prior to loading the ECS properties. This is due to the TCS’s ECS simulator


properties being inconsistent with those of the ECS. Likewise, if the TCS and its ECS simulator are to be used following use of the ECS then all ECS properties must be removed before the TCS will operate correctly. See section 6.2 for more details regarding the ECS property DB entries. Section 6.4 gives more details about removing all property data from the property DB and reloading the factory default values.

RUNNING THE ECS FROM THE TESTHARNESS 4.8

The ECS can be run from the CSF test harness using the following commands Testharness

atst> deploy ECS1 localhost java

atst> init ECS1

atst> start ECS1

atst> init atst.tcs.ecs.vemcs

atst> start atst.tcs.ecs.vemcs

atst> init atst.tcs.ecs

atst> start atst.tcs.ecs

When not using the VEMCS simulator the init and start commands issued to atst.tcs.ecs.vemcs are not to be used. NB. When starting and stopping the atst.tcs.ecs controller from the Testharness using the commands start atst.tcs.ecs and shutdown atst.tcs.ecs the harness expects these commands to complete within 10 seconds, however, the setting of the default hardware state that occurs at startup and shutdown takes longer than 10seconds, therefore the following failure message is expected and can be ignored: performing [startup|shutdown]

shutdown on atst.tcs.ecs has not completed in 10 seconds

atst.tcs.ecs failed to shutdown (it is still trying)

[strart|shutdown] failed For more details about starting and running the ECS see section 7. For more information regarding starting and running the VEMCS see section 11.3.

STARTING THE ECS ENGINEERING SCREENS 4.9

The ECS Java Engineering Screens (JES) are started using the following commands, ensure that the terminal from which the screens are to be started has the correct $ATST and $PATH set (see section 4.1): JES -–file=ecs/ECS_Main.xml

The VEMCS simulator JES screens are started using: JES -–file=ecs/VEMCS_Main.xml For details of using the VEMCS see section 11.


WARNING: the ECS JES screens contain many JES widgets each examining data from CSF events generated by the ECS and VEMCS to show the current status of enclosure hardware. In order for these screens to run without process resource problems on a CentsOS 6 system, the system’s limit of user-space threads must be increased from the standard 1024. This is done by editing the file /etc/security/limits.d/90-nproc.conf, replacing the line: * soft nproc 1024 with the line: * soft nproc 4096

This issue is documented in the CSF-devel mailing list message User space thread limit, dated July 18th 2012.

ISSUING COMMANDS TO THE ECS 4.10

To demand the azimuth carousel and altitude shutter mechanisms to actively hold their current position

push the ACTIVE button on the ECS screen (located in the ECS Mode 3-button widget situated in

middle-left of screen's top-half). The overall Mode of the ECS will become active and in a short time

the In Position status will show true. Pushing the OFF button will return the azimuth and altitude

hardware to the off state. NB. When moving the altitude shutter from mode off to active (as is done during the above) the shutter's seals are deflated, the time taken for this to occur will result in the altitude shutter taking

longer to become In Position than does the azimuth carousel.

When using the VEMCS simulator its JES screen can be used to update hardware status values returned to the ECS. For example to set the current velocity of the azimuth carousel’s motor number 6;

select the Az tab on the VEMCS screen and select the Motor #6 tab of the ECS Read Tag – R_azCStatus,

towards the bottom of the table is the tag’s item mtr6Vel, in the Update Value column of this item enter

a new motor velocity value and press return. To see the new value as read from the VEMCS by the

ECS, select the Azimuth Carousel tab on the ECS screen and push the button Motors. This displays a

table showing the current status of all azimuth motors; the Current Velocity value for Motor 6 will now

show the value entered on the VEMCS screen.


5 I NS TALLI NG TH E E C S

The following instructions describe the installation process for the ECS on a COTS PC such as might be used to run the ECS for test purposes. The instructions only cover the installation of the ECS and VEMCS simulator and associated configuration database CSV files, and not the installation of the ATST CSF itself, which is beyond the scope of this document. The installation instructions for the CSF can be found in [AD 10].

PREREQUISITES 5.1

The ECS application runs under the Linux OS within the ATST Common Services Framework (CSF) environment. The current ECS release uses ATST CSF release Canary 5.2 patch 1. The ECS has been developed and is supported on CentOS 6. CentOS is a community supported Linux distribution built from Red Hat’s source distributions. (See www.centos.org).

5.1.1 CSF Installed

Before the ECS can be compiled there must be a full installation of the CSF present on the target system under a ATST Software Development Tree (ASDT). Details of the installation of the CSF can be found in [AD 10]. The current release of the ECS has been developed and tested using CSF release Canary 5.2 patch 1, obtained from the ATST CVS repository using the CVS tag Canary_5-2p1, therefore it is required the ASDT contains this version of the CSF.

5.1.2 PLCIO Installed and Configured

To communicate with the EMCS Allen-Bradley PLC the ECS uses the 3rd party licensed software library PLCIO, supplied by Commercial Timesharing Inc. For purchase information see the PLCIO website www.ctiplcio.com. When purchased this is installed from source and compiled into the C libraries that the ECS links to. Details of the installation of PLCIO from source can be found in [RD 4]. Or, alternatively if a PLCIO runtime license is available the PLCIO libraries required can be installed from pre-built versions available from the ATST CVS repository (see section 5.2.3). The installation of PLCIO from its source is configured using a configure script. When run it prompts for the location of the installation directory, for ease of use with the ECS from an ASDT the location should be specified as: <absolute path to $ATST>/lib/c++/<host arch>/ecs

If the PLCIO libraries are not installed at the above location then the $ATST/admin/site.config directive ATST_JLIB_DIRS must be appended with the actual location of the directory containing the libraries.


5.1.3 Network Configuration

The PC on which the ECS is operated requires to have two network interfaces. One interface is configured to give ECS access to the TCS and to other systems in the ATST wider world. The other is connected to the Enclosure private network and gives direct access to the EMCS.

Enclosure IP Address Configuration 10.2.9.12 IP address of EMCS PLC. 10.2.9.92 IP address of ECS PC's network interface with direct connection to EMCS PLC.

Table 1 Enclosure IP address configuration details.

INSTALLATION FROM CVS 5.2

The ECS is installed into an ASDT alongside other ATST software including all CSF and Base software. The current ECS release uses ATST CSF release Canary 5.2 patch 1, which implies use of Java 7 as this is the version of Java used by Canary 5.2. The current release of the ECS has been developed and tested with CSF Canary 5.2 patch 1 obtained from the ATST CVS repository using the CVS tag Canary_5-2p1 and therefore it expects the ASDT to contain this version of the CSF. The ASDT may also contain other ATST system software, e.g. the TCS, but no other system software is required to build or run the ECS. Though in final operation the ECS will be installed in an ASDT alongside the TCS and all other system software of the ATST.

5.2.1 Environment Variables $ATST and $PATH

The top-most directory of an ASDT must be defined by the environment variable $ATST. Prior to an installation from CVS this variable must be set to the ASDT directory containing the CSF and Base installation you wish to install the ECS within. This is done by: export ATST=<path to ASDT installation directory>

In order to make use of the CSF software tools installed in the ASDT, its bin directory needs to be added to the $PATH environment variable. For example: export PATH=$PATH:$ATST/bin NB. The current release of the ECS has been developed and tested with CSF Canary 5.2 patch 1 obtained from the ATST CVS repository using the CVS tag Canary_5-2p1.

5.2.2 Configuration of site.config

To ensure correct access to the various libraries used by and installed as part of the ECS the ASDT site.config, defined in $ATST/admin/site.config, must contain the correct values. Select your favorite text editor and ensure the following site.config directives are set as described:

ATST_PACKAGE_LIST – this directive contains a list of all packages that are to be installed with the ATST CS core. By default this will include base; the ecs package should be added and also,


if using the pre-built PLCIO libraries (see section 5.2.3), the idom package, e.g: ATST_PACKAGE_LIST="base idom ecs"

ATST_JNI_PACKAGES – this directive contains a list of all directories in the ASDT containing Java Native Interface (JNI) source code. There is one ECS packages that contains JNI code:

o abplc – this package contains the connection classes used by the ECS to connect with the EMCS PLC. It contains JNI source code that implements the software to communicate between the connection’s Java classes and the PLCIO C library used to communicate with the EMCS PLC.

To correctly compile the JNI library built from the above package it must be listed in the directive, e.g.: ATST_JNI_PACKAGES="abplc"

ATST_JLIB_DIRS – see section 5.1.2 regarding setting of this directive if the PLCIO library is not installed within the $ATST/lib directory of the ASDT.

Following any changes to site.config run the createDevel script to update the ASDT, e.g.: cd $ATST

./admin/createDevel --init-data

5.2.3 Obtaining and Installing the Pre-built PLCIO Libraries

To use the pre-built PLCIO libraries the user must have a PLCIO runtime license. See the PLCIO website www.ctiplcio.com for further details. If a full installation of the PLCIO library, used to communicate between the ECS and EMCS PLC, is not available on the installation PC (see 5.1.2), pre-built PLCIO libraries may be used. These can be obtained from the ATST CVS repository atst/src/idom. To check out the pre-built libraries into the current ASDT, having a top level directory called atst, use the following commands. To checkout the ECS Final release version of this module in the following checkout command replace <ECS_RELEASE_TAG> with ECS_final_v1_3_0. cd $ATST/.. export CVSROOT=":pserver:<CVS user name>@maunder.tuc.noao.edu:/home/atst/src/idom"

cvs login

cvs co -P -r <ECS_RELEASE_TAG> atst This will create the directory idom under $ATST/src/c++ containing the files described in Table 2.

Contents of idom module Makefile The CSF package Makefile created by createPackageMake. Makefile.gcc The gcc Makefile containing directives to correctly install library as an idom

package. plc.h

plclib.h

winwrap.h

Header files from PLCIO required when building the ECS abplc package JNI library and the VEMCS simulator contained in ECS package vemcs.

plc_x86_64.lib 64 bit versions of the PLCIO libraries used by the ECS.


plccip_x86_64.lib

plc_i686.lib

plccip_i686.lib 32 bit versions of the PLCIO libraries used by the ECS.

Table 2 Contents of the idom module

Prior to building the ECS the PLCIO libraries and header files must be installed, this is done using the following commands: cd $ATST

make gcc_all

APPENDIX A contains a script including the above commands that may be used to CVS checkout and build all software of the ECS including installing the PLCIO pre-built libraries. When built the header files are installed into $ATST/src/c++/include/idom and the libraries into $ATST/lib/c++/<host arch>/idom.

5.2.4 Obtaining the ECS Source Code

The ECS software is contained in the ATST CVS repository atst/src/ecs. To checkout all ECS source code into the current ASDT, having a top level directory called atst, use the following commands. To checkout the ECS Final release version of this module in the following checkout command replace <ECS_RELEASE_TAG> with ECS_final_v1_3_0. cd $ATST/..

export CVSROOT=":pserver:<CVS user name>@maunder.tuc.noao.edu:/home/atst/src/ecs"

cvs login


Following build of the idom module, described in the previous section, CVS messages of the following form are to be expected in output from above checkout and can be ignored: cvs checkout: existing repository /home/atst/src/base/CVSROOT/Emptydir does not

match /home/atst/src/base/atst

APPENDIX A contains a script including the above commands that may be used to CVS checkout and build all software of the ECS.

5.2.5 Contents of ECS Source Code Directories

The following sub-sections describe the contents of ECS directories created in the ASDT when the CVS checkout command described in section 5.2.4 is issued. The section 5.2.6, that follows, describes how to build the ECS once the ECS software has been checked out.

5.2.5.1 Contents of ECS $ATST/src/java/atst/ecs

Following checkout of the ECS the directory $ATST/src/java/atst/ecs will contain the Java source files of the ECS. The ECS source files are contained within three Java packages:

1. atst.ecs – containing the classes implementing the ECS controllers, see Table 3. 2. atst.ecs.abplc – containing the classes implementing the ECS connection classes used by

the ECS controllers to connect to the EMCS PLC, see Table 4.


3. atst.ecs.vemcs – containing the classes implementing the ECS Virtual EMCS (VEMCS) simulator, see Table 5.

In addition to the ECS Java source package directories the ECS source directory also contains the following sub-directories:

scripts – containing shell and CSF Testharness scripts to assist with various ECS tasks.

test – containing the ECS testing scripts and support software, see section 12 Unit Testing.

widgets – containing custom JES widgets used by the ECS JES engineering interfaces, see section 8 Using the ECS Engineering Interfaces.

The following tables describe the contents of the three ECS Java packages.

Package atst.ecs

File Name Description

Alt.java Class extending the ECS class TrackingMech.java and implementing the altitude shutter controller atst.tcs.ecs.alt.

Aux.java Class extending the CSF Base class HardwareController and implementing the auxiliary equipment controller atst.tcs.ecs.aux.

Az.java Class extending the ECS class TrackingMech.java and implementing the azimuth carousel controller atst.tcs.ecs.az.

Cover.java Class extending the CSF Base class HardwareController and implementing the aperture cover controller atst.tcs.ecs.cover.

ECS.app A comma-separated file containing the ECS application data loaded into the application tables of the property DB.

Ecs.java

Class extending the CSF Base class ManagementController and implementing the ECS top-level management controller atst.tcs.ecs.

ECSPlcTags

[Alt|Aux|Az|Cover|Emcs].prop

EMCS PLC tag metadata properties describing the Enclosure to ECS ICD, used by the respective controller and loaded into the property DB.

ECS.prop

The .prop file of the ECS containing properties of the ECS controllers to be loaded into the property DB. Each controller inherits their EMCS PLC tag metadata by inheriting properties declared in their ECSPlcTags .prop file.

ECStestPlc.prop

Properties used by the ECS when connecting to the Allen-Bradley test PLC hardware (with IP address 10.2.2.15) – not to be used unless access to this PLC is available.

Emcs.java Class extending the CSF Base class HardwareController and implementing the EMCS controller atst.tcs.ecs.emcs.

HealthHelper.java Helper class for handling controller Health.

Makefile Makefile of the atst.tcs.ecs package created by createPackageMake.

PlcTagHelper.java Helper class for handling PLC tags.

TcsToEcsIcdConstants.java

Class defining constants representing items of the TCS to ECS ICD 4.4/5.6 [AD 3]. All ECS controller classes import this class using a Java static import to gain access to the ICD definitions they use to communicate with the TCS.


Package atst.ecs

TrackingMech.java

An abstract class extended from CSF Base class HardwareController and implementing the common ECS tracking mechanism behavior required by altitude shutter and azimuth carousel controllers.

Table 3 Contents of ECS Java package atst.ecs

Package atst.ecs.abplc

File Name Description

ABPlcioChannel.java

Class extending CSF Base class Channel and implementing the connection channel class used by ABPlcioConnection.java and its derived classes.

ABPlcioConnection.java

Abstract class extending CSF Base class Connection and implementing the common connection behavior required by all ECS controllers by implementing interface IABPlcioConnection. From this class all ECS controller specific connection classes are derived.

ABPlcioConnectionAlt.java

Class extending ABPlcioConnectionTracking and implementing IABPlcioConnectionAlt interface to provide the altitude shutter controller specific connection class.

ABPlcioConnectionAux.java

Class extending ABPlcioConnection and implementing IABPlcioConnectionAux interface to provide the auxiliary equipment controller specific connection class.

ABPlcioConnectionAz.java Class extending ABPlcioConnectionTracking to provide the azimuth carousel controller specific connection class.

ABPlcioConnectionCover.java

Class extending ABPlcioConnection and implementing IABPlcioConnectionCover interface to provide the aperture cover controller specific connection class.

ABPlcioConnectionEmcs.java

Class extending ABPlcioConnection and implementing IABPlcioConnectionEmcs interface to provide the EMCS controller specific connection class.

ABPlcioConnection

Tracking.java

Abstract class extending ABPlcioConnection and implementing the IABPlcioConnectionTracking interface to provide the common connection capabilities required by both tracking mechanism controllers (atst.tcs.ecs.alt and atst.tcs.ecs.az).

ABPlcioException

BadPlcTagProperties.java

Exception thrown by PlcTag.java if it is unable to create a PlcTag object from PLC tag metadata contained in the property DB.

ABPlcioExceptionJNI.java Exception thrown by ABPlcioMaster.java JNI methods if they are unable to complete successfully due to a JNI error.

ABPlcioExceptionPLCIO.java Exception thrown by ABPlcioMaster.java JNI methods if they are unable to complete successfully due to a PLCIO error.

ABPlcioMaster.java

The ECS connection master class through which all calls to the JNI code providing Java access to PLCIO C library functions, used to communicate with the EMCS, are made.



EmcsToEcsIcdConstants.java

Class defining constants representing items of the Enclosure to ECS ICD 5.0/5.6 [AD 4]. All ECS connection classes import this class using a Java static import to gain access to the ICD definitions they use to communicate with the Enclosure.

IABPlcioConnection.java Interface providing common connection methods used by all ECS controllers to access the EMCS PLC.

IABPlcioConnectionAlt.java

The altitude shutter controller specific connection interface extending IABPlcioConnection and IABPlcioConnectionTracking to add methods used by this controller to operate its hardware.

IABPlcioConnectionAux.java

The auxiliary equipment controller specific connection interface extending IABPlcioConnection to add methods used by this controller to operate its hardware.

IABPlcioConnection

Cover.java

The aperture cover controller specific connection interface extending IABPlcioConnection to add methods used by this controller to operate its hardware.

IABPlcioConnectionEmcs.java

The EMCS controller specific connection interface extending IABPlcioConnection to add methods used by this controller to operate its hardware.

IABPlcioConnection

Tracking.java

Extends IABPlcioConnection interface to provide methods required by ECS tracking mechanism controllers to operate their hardware.

IABPlcioMaster.java

Interface implemented by ABPlcioMaster.java and through which all ABPlcioChannel.java objects communicate with the EMCS PLC. This interface is required to cross the Java namespace boundary between channels (contained in the controller’s namespace) and the master (contained in the ECS container’s namespace).

IPlcioCall.java

Interface describing the object passed in call to ABPlcioMaster.plcAccess() method (called by ABPlcioChannel to access the EMCS PLC) that contains all information necessary to call any of the PLCIO library functions.

IPlcioPcFormatType.java

Interface describing the contents of the PLCIO library’s pc_format string, which is used to fully describe the data types contained in a PLC tag.

IPlcTag.java

Interface implemented by PlcTag.java. This interface is required as PlcTag.java objects require to cross the Java namespace component/container boundary.

Makefile Makefile of the atst.tcs.ecs.abplc package created by createPackageMake.

Makefile.jni Makefile, created by createJniPackage, identifying that this package contains JNI source code in a jni sub-directory.

PlcioCall.java

Class implementing IPlcioCall interface and used by ABPlcioChannel to pass information to ABPlcioMaster (across the component/container namespace boundary) describing the PLCIO function (and parameters) that is to be called.



PlcioPcFormat.java Abstract class containing definitions and helper methods used to operate with PLCIO pc_format strings.

PlcioPcFormat

TestHarness.java

A standalone java program to test the correct operation of class PlcioPcFormat.java.

PlcioPcFormatType.java Immutable class used for storing type information about PLC tags contained in a PLCIO pc_format string

PlcTag.java Class used to describe a PLC tag used to communicate with the EMCS PLC.

PlcTagReader.java Class used to read a specified EMCS PLC tag at a specified frequency and return its contents via a specified interrupt handler.

jni/

atst_ecs_abplc_

ABPlcioMaster.c

Source file containing implementation of the JNI native methods declared in ABPlcioMaster.java and used to access the PLCIO C library from Java. Compiled into the library libatst_ecs_abplc_ABPlcioMaster.so and installed in $ATST/lib/<host arch>/ecs.

Table 4 Contents of ECS Java package atst.ecs.abplc

Package atst.ecs.vemcs

File Name Description IVirtualEmcs.java Interface containing constants used by the VEMCS.

Makefile Makefile of the atst.tcs.ecs.vemcs package created by createPackageMake.

VEMCS.app

A comma-separated file containing additions required to the ECS application data loaded into the application container table of the property DB when using the VEMCS.

VEMCS.prop The .prop file of the VEMCS containing all properties of its controllers to be loaded into the property database.

VirtualEmcs.java

Class extending the CSF Base class Management Controller and implementing the VEMCS management controller atst.tcs.ecs.vemcs.

VirtualEmcsController.java

Class extending the CSF Base class BaseController and implementing the general behavior required of all atst.tcs.ecs.vemcs sub-controllers.

VirtualEmcsController

Aux.java

Class extending the VirtualEmcsController class and adding behavior required to simulate the EMCS PLC operations relating to the enclosure’s auxiliary equipment.


Cover.java

Class extending the VirtualEmcsController class and adding behavior required to simulate the EMCS PLC operations relating to the enclosure’s aperture cover.


Emcs.java

Class extending the VirtualEmcsController class and adding behavior required to simulate the internal workings of the EMCS PLC, i.e. setting status and receiving commands from the ECS atst.tcs.ecs.emcs controller.


Tracking.java

Class extending the VirtualEmcsController class and adding behavior required to simulate tracking mechanisms. The servo simulating mechanism movement is contained in this class.


Package atst.ecs.vemcs


TrackingAlt.java

Class extending the VirtualEmcsControllerTracking class and adding specific behavior required to simulate the altitude shutter tracking mechanisms.


TrackingAz.java

Class extending the VirtualEmcsControllerTracking class and adding specific behavior required to simulate the azimuth carousel tracking mechanisms.


TrackingServo.java

Class containing the simulated servo implementation of an enclosure tracking mechanism used by VirtualEmcsControllerTracking.


TrackingLimits.java

Class responsible for simulating the current state of EMCS travel limits based upon the current position of the tracking mechanism (as determined by simulation servo in VirtualEmcsControllerTrackingServo).

Table 5 Contents of ECS Java Package atst.ecs.vemcs

5.2.5.2 Contents of ECS $ATST/src/c++/atst/ecs

Following checkout of the ECS the directory containing C++ source files of the ECS will contain a single sub-directory called plciovemcs, which contains the atst.ecs.plciovemcs package. This contains the ECS implementation of the PLCIO communications module vemcs, used instead of the PLCIO’s cip module when operating with the VEMCS simulator. Table 6 details the files of the package.

Package atst.ecs.plciovemcs Makefile The CSF package Makefile created by createPackageMake. Makefile.gcc The gcc Makefile containing directives to correctly build and install library

as an ecs package. The library created is libplcvemcs.so and is installed in $ATST/lib/c++/<host arch>/ecs.

vemcs.c C source file containing implementation of the PLCIO communications module vemcs.

vemcs.h Header file used by vemcs.c containing all EMCS PLC tag information used by vemcs as defined in the Enclosure to ECS ICD 5.0/5.6 [AD 4].

Table 6 Contents of ECS C++ package atst.ecs.plciovemcs

5.2.5.3 Contents of ECS $ATST/resources/screens/ecs

Following checkout of the ECS the ECS Java Engineering Screens (JES) are placed in the directory $ATST/resources/screens/ecs. Table 7 contains details of the main ECS JES screens contained in the directory.


ECS JES Screens ECS_Main.xml The ECS Main screen providing access to TCS level operations. From this

screen all operations detailed in the TCS to ECS ICD 4.4/5.6 [AD 3] can be carried out and monitored. For full details see section 8.3.

ECS_Engineering.xml The ECS Engineering screen providing access to EMCS level operations and ECS system information. From this screen all operations detailed in the Enclosure to ECS ICD 5.0/5.6 [AD 4] can be carried out. For full details see section 8.4.

VEMCS_Main.xml The main screen of the VEMCS simulator. From this screen all VEMCS operations can be carried out and monitored. For full details see section 8.3.

ECS_TestUtility.xml The screen from which all ECS acceptance and unit tests can be run. For full details see section 12.1.

Table 7 Description of ECS JES screens contained in ECS CVS module atst/resources

5.2.5.4 Contents of ECS $ATST/resources/images/ecs

Following checkout of the ECS this directory (and sub-directories) contains images used by the ECS JES screens located in ATST/resources/screens/ecs (see section 5.2.5.3).

5.2.5.5 Contents of ECS $ATST/doc/guides/ecs

Following checkout of the ECS this directory contains the ECS documentation including release notes.

5.2.6 Building the ECS

As all ECS software is contained within CSF packages it is built using the Makefile support contained in CSF, for full details see [AD 10]. Once all ECS software has been obtained as described in the previous sections it is built in three steps. Step 1 relates to building software used by the Virtual EMCS (VEMCS) simulator that are a prerequisite required when building the VEMCS contained in the ECS software.

1. Build the VEMCS PLCIO library: cd $ATST/src/c++/atst/ecs/plciovemcs

make gcc_all

2. Build the ECS classes and JNI:

cd $ATST

make classes

make jni

3. Install the ECS scripts:

cd $ATST/src /java/atst/ecs/scripts make install_scripts

To create the source code documentation use: cd $ATST

make docs


Once created using the above command ECS Javadoc source code documentation will be accessible through a web browser by opening the file $ATST/doc/api-docs/java/atst/index.html, as is all CSF source code documentation. APPENDIX A contains a script including the above commands that may be used to CVS checkout and build all software of the ECS. The individual ECS packages can be built independently by running the various make commands in their source directories.

5.2.7 Upgrading from Previous ECS Releases

If the PC on to which the ECS is being installed has previously been used to run earlier versions of the ECS the latest ECS release should be installed following the instructions documented in the previous sections. Prior to running the new installation the old VEMCS simulator binary data files must be removed. (For details about the VEMCS see section 11 of this manual.) This is done by removing the directories under which these files are stored using the following commands: rm -rf $ATST/resources/ecs/R_tagDataFiles

rm -rf $ATST/resources/ecs/W_tagDataFiles NB. The location of the VEMCS simulator binary data files was changed between ECS release final 1.1 (CVS tag ECS_final_v1_1_0) and release final 1.2 (CVS tag ECS_final_v1_2_0). In earlier releases these files were located under /var/tmp/atstEcs, therefore if upgrading from final 1.1 to a later release this directory can be removed and there will be no directories under $ATST/resources/ecs to be removed.


6 C ONF I G U R ING TH E E C S

This section describes the different configuration settings that affect the ECS. All of the configuration information required by the ECS is maintained within the property DB of the CSF. How this configuration information is maintained is the choice of the ECS operator, but a standard set of factory defaults are provided in CSV format. These factory default values can be reloaded into the database to restore the ECS application to its delivered state. How to restore to factory defaults is described in section 6.4.

APPLICATION CONFIGURATION 6.1

The configuration of a CSF application is achieved by populating the application tables of the property DB, using the correct information relating to the application’s CSF components/controllers and computer host on which they run. The ECS application consists of six CSF controllers, one of which is a management controller. The ECS application is run in a single CSF Java container. The EMCS simulator VEMCS also consists of six CSF controllers, one of which is a management controller. When required to be used the simulator’s controllers are added to the ECS container. For full details of ECS and VEMCS controllers and container deployment see the ECS Software Design Description [AD 6]. All of the application configuration information (i.e. which controllers are loaded into the container, names and classes of controllers, etc.) must be configured before the ECS application can be loaded. The tables below present the information required to configure the ECS application tables. The table columns equate directly with columns of the application host, container and component tables of the property DB.

ECS Host Configuration

Host Name Description

<ecsHost> The host Linux PC of the ECS.

Table 8 ECS Application Host Configuration

ECS Container Configuration

Container Name

Class Name Host Name

Toolbox Loader Description

ECS1 atst.cs.ccm.container.Container <ecsHost> java ice The ECS Java container.

Table 9 ECS Application Container Configuration

ECS Controller Configuration

Component Name Class Name Container Name

Description

atst.tcs.ecs atst.ecs.Ecs ECS1 The top-level ECS management controller.

atst.tcs.ecs.alt atst.ecs.Alt ECS1 The altitude shutter controller.

atst.tcs.ecs.az atst.ecs.Az ECS1 The azimuth carousel controller.

atst.tcs.ecs.aux atst.ecs.Aux ECS1 The auxiliary equipment controller.

atst.tcs.ecs.cover atst.ecs.Cover ECS1 The aperture cover controller.


ECS Controller Configuration


Description

atst.tcs.ecs.emcs atst.ecs.Emcs ECS1 The EMCS controller.

Table 10 ECS Application Controller Configuration

VEMCS Controller Configuration


Description

atst.tcs.ecs.vemcs atst.ecs.vemcs. VirtualEmcs

ECS1 The VEMCS management controller.

atst.tcs.ecs.vemcs.alt atst.ecs.vemcs. VirtualEmcsController TrackingAlt

ECS1 The VEMCS altitude shutter controller.

atst.tcs.ecs.vemcs.az atst.ecs.vemcs. VirtualEmcsController TrackingAz

ECS1 The VEMCS azimuth carousel controller.

atst.tcs.ecs.vemcs.aux atst.ecs.vemcs. VirtualEmcsControllerAux

ECS1 The VEMCS auxiliary equipment controller.

atst.tcs.ecs.vemcs.cover atst.ecs.vemcs. VirtualEmcsControllerCover

ECS1 The VEMCS aperture cover controller.

atst.tcs.ecs.vemcs.emcs atst.ecs.vemcs. VirtualEmcsControllerEmcs

ECS1 The VEMCS EMCS controller.

Table 11 Addition to ECS Application Controller Configuration required when using VEMCS

The information provided in the above tables is delivered with the ECS application in the form of two CSV formatted files. The application data required for the ECS is contained in file ECS.app, located in the atst.ecs package (see Table 3 in section 5.2.5.1). The additional data required to be added to the ECS application to run the VEMCS simulator is contained in file VEMCS.app, located in the atst.ecs.vemcs package (see Table 5 in section 5.2.5.1).

CONTROLLER CONFIGURATION 6.2

Each controller of the ECS application has configuration data items relevant to its operation, these are stored in the property table of the property DB. All controller configuration data must be configured before the application can be successfully started. This includes (but is not limited to) the management controller configuration including definition of the sub-controllers that it manages. Also present is specific information required by each of the controllers, e.g. IP address of EMCS PLC, travel limits of azimuth carousel etc. All properties required by the ECS, including the VEMCS, are included with the ECS software in .prop files. These files follow the recognized CSF comma-separated format for loading into the property DB using the CSF PropertyReader tool (see [RD 3]). An overview of the contents of the ECS .prop files are documented in the tables describing the contents of the ECS, as checked out from CVS, contained in section 5.2.4 of this document. Each property defined in the .prop files is fully described and documented within the description column of the property, therefore, in order to ensure this


information is not duplicated it is not reproduced in this document; the user is instructed to look directly at the .prop file contents to inspect the properties in use by the ECS. For correct configuration of the ECS prior to first-time use with enclosure hardware, or following changes to enclosure hardware, a small number of ECS properties may need modifying. The only columns of the property that shall require modification are saved values, limits and/or defaults. The properties are documented in the following tables; each table contains properties specific to a single ECS controller and gives the name of the .prop file they are contained in.

ECS Management Controller: atst.tcs.ecs (ECS.prop)

Property Name Type Access Description Saved values Limits Defaults . healthMode TestPause

real r-- The pause in seconds the cHealth postingTAB should not test ECS .mode matches sub-controllers' .mode following submit of config containing .mode.

3.0

Table 12 ECS Management Controller atst.tcs.ecs Properties

Altitude Shutter Controller: atst.tcs.ecs.alt (ECS.prop)

Property Name Type Access Description Saved values Limits Defaults .connection: address

string r-- The EMCS connection address.

10.2.9.12

.connection: isSimulated

boolean r-- Turn on/off connection simulation - when true VEMCS simulator is used.

true

.pos real r-x Position demand (degrees). 7.0, 90.5

.oPos real r-x Offset position demand (degrees).

-45.0, 45.0

.jogVel real r-x The velocity demand (degrees/second)

-2.0, 2.0

.namedPos:stow real r-- Value of named position ‘stow’.

90.0

.namedPos:service1 real r-- Value of named position ‘service1’ – engaged position of upper counterweight latch.

20.0

.namedPos:service2 real r-- Value of named position ‘service2’ – engaged position of lower counterweight latch.

40.0

.namedPos:service3 real r-- Value of named position ‘service3’ – engaged position of secondary latch.

60.0

.namedPos:service4 real r-- Value of named position ‘service4’ – engaged position of tertiary latch.

80.0

.namedPos:service5 real r-- Value of named position ‘service5’ – position aperture plate is horizontal.

73.0



Property Name Type Access Description Saved values Limits Defaults .namedPos:limitLoLo real r-- Value of named position

‘limitLoLo’. Saved value equates to EMCS end-of-travel limit.

5.0

.namedPos:limitLo real r-- Value of named position ‘limitLo’. Saved value equates to EMCS soft-limit.

7.0

.namedPos:limitHi real r-- Value of named position ‘limitHi’. Saved value equates to EMCS soft-limit.

90.5

.namedPos:limitHiHI real r-- Value of named position ‘limitHiHi’. Saved value equates to EMCS end-of-travel limit.

92.0

.posTol real r-x The configuration .posTol value used to demand position tolerance used when setting .inPosition (degrees).

0.05

.velTol real r-x The configuration .velTol value used to demand velocity tolerance used when setting .inPosition (degrees/sec)

0.05

.inPosToleranceTime real r-- The time in seconds for which the position and velocity have to remain within .posTol and .velTol before .inPosition is set true.

3.0

.emcsModePtoP Tolerance

real r-- When mode is tracking the value in degrees which when the absolute difference between demand position and current position is greater than the EMCS mode Point-to-Point will be demanded, otherwise EMCS mode Tracking is demanded.

0.9

. sealPressure Deflated

real r-- The pressure below which the seal is determined to be deflated (mBar).

10.0

. sealPressure Inflated

real r-- The pressure above which the seal is determined to be inflated (mBar).

240.0



Property Name Type Access Description Saved values Limits Defaults .trajectoryLowerLimit real r-- The lower demand limit

(degrees) used when tracking, actual demand will always be clipped to .pos lower range value, but demand value between this property's value and .pos lower range will not cause tracking to be stopped

6.8

.trackingPosDemand Period

real r-- The period in seconds between writes to the EMCS of the W_Pos tag when tracking - a value of 0.05 or below will result in all trajectory events received from the TCS causing a write of the tag.

0.2

.timeoutModeOff real r-- The timeout in which the EMCS must respond as expected when .mode=off is submitted (seconds). NB. When .mode=off is submitted the EMCS inflates the altitude shutter seals and therefore timeout must include sufficient time for this to occur.

32.0

.timeoutModeActive real r-- The timeout in which the EMCS must respond as expected when .mode=active is submitted (seconds). I.e. position returned by EMCS is such that ECS can set .inPosition to true. NB. When .mode=active is submitted the EMCS deflates the altitude shutter seals and therefore timeout must include sufficient time for this to occur.

120.0

.timeoutMode Tracking

real r-- The timeout in which the EMCS must respond as expected when .mode=tracking is submitted (seconds). I.e. position returned by EMCS is such that ECS can set .inPosition to true.

210.0



Property Name Type Access Description Saved values Limits Defaults .timeoutSeals real r-- The timeout in which the

EMCS must respond as expected when .seals=[inflated|deflated] is submitted (seconds).

30.0

.trajectoryCallback Alarm

real r-- The time in seconds that if no TCS trajectory event callback is received the TrajectoryCallback alarm is raised.

0.5

.trajectoryLatency Alarm

real r-- The time in seconds that if processing time between trajectory event arrival and sending demand to EMCS PLC exceeds then TrajectoryLatency alarm is raised.

0.05

Table 13 ECS Altitude Shutter Controller atst.tcs.ecs.alt Properties

Azimuth Carousel Controller: atst.tcs.ecs.az (ECS.prop)

Property Name Type Access Description Saved values Limits Defaults .connection:address string r-- The EMCS connection

address. 10.2.9.12



true

.pos real r-x Position demand (degrees). -85.0, 305.0

.oPos real r-x Offset position demand (degrees).

-100.0, 100.0

.jogVel real r-x The velocity demand (degrees/second)

-2.0, 2.0

.namedPos:stow real r-- Value of named position ‘stow’.

90.0

.namedPos:service1 real r-- Value of named position ‘service1’ – maintenance hatch position bogie 1 (enclosure coordinate degree position 160 cw wrap).

270.0


235.0


200.0



Property Name Type Access Description Saved values Limits Defaults .namedPos:service4 real r-- Value of named position

‘service4’ – maintenance hatch position bogie 4 (enclosure coordinate degree position 55 cw wrap).

165.0


130.0

.namedPos:service6 real r-- Value of named position ‘service6’ – maintenance hatch position bogie 6 (enclosure coordinate degree position 340 ccw wrap).

90.0


55.0


20.0


-10.0


-50.0

.namedPos:limitLoLo real r-- Value of named position ‘limitLoLo’. Saved value equates to EMCS end-of-travel limit.

-87.0

.namedPos:limitLo real r-- Value of named position ‘limitLo’. Saved value equates to EMCS soft-limit.

-85.0

.namedPos:limitHi real r-- Value of named position ‘limitHi’. Saved value equates to EMCS soft-limit.

305.0



Property Name Type Access Description Saved values Limits Defaults .namedPos:limitHiHI real r-- Value of named position

‘limitHiHi’. Saved value equates to EMCS end-of-travel limit.

307.0

.posTol real r-x The configuration .posTol value used to demand position tolerance used when setting .inPosition (degrees).

0.05

.velTol real r-x The configuration .velTol value used to demand velocity tolerance used when setting .inPosition (degrees/sec)

0.05

.inPosToleranceTime real r-- The time in seconds for which the position and velocity have to remain within .posTol and .velTol before .inPosition is set true.

3.0

.emcsModePtoP Tolerance

real r-- When mode is tracking the value in degrees which when the absolute difference between demand position and current position is greater than the EMCS mode Point-to-Point will be demanded, otherwise EMCS mode Tracking is demanded.

0.9

.trackingPosDemand Period

real r-- The period in seconds between writes to the EMCS of the W_Pos tag when tracking - a value of 0.05 or below will result in all trajectory events received from the TCS causing a write of the tag.

0.2

.timeoutModeOff real r-- The timeout in which the EMCS must respond as expected when .mode=off is submitted (seconds).

5.0

.timeoutModeActive real r-- The timeout in which the EMCS must respond as expected when .mode=active is submitted (seconds). I.e. position returned by EMCS is such that ECS can set .inPosition to true.

300.0



Property Name Type Access Description Saved values Limits Defaults .timeoutMode Tracking

real r-- The timeout in which the EMCS must respond as expected when .mode=tracking is submitted (seconds). I.e. position returned by EMCS is such that ECS can set .inPosition to true.

480.0

.trajectoryCallback Alarm

real r-- The time in seconds that if no TCS trajectory event callback is received the TrajectoryCallback alarm is raised.

0.5

.trajectoryLatency Alarm

real r-- The time in seconds that if processing time between trajectory event arrival and sending demand to EMCS PLC exceeds then TrajectoryLatency alarm is raised.

0.05

Table 14 ECS Azimuth Carousel Controller atst.tcs.ecs.az Properties

Auxiliary Equipment Controller: atst.tcs.ecs.aux (ECS.prop)



10.2.9.12



true

.camera: timeoutEnable

real r-- The timeout in which the EMCS must respond as expected when .camera:enable=[off|on] is submitted (seconds).

15.0

Table 15 ECS Auxiliary Controller atst.tcs.ecs.aux Properties

Aperture Cover Controller: atst.tcs.ecs.cover (ECS.prop)



10.2.9.12



true

.timeoutCover real r-- The timeout in which the EMCS must respond as expected when .pos=[opened|closed] is submitted (seconds).

30.0


Aperture Cover Controller: atst.tcs.ecs.cover (ECS.prop)

Property Name Type Access Description Saved values Limits Defaults . sealPressure Deflated

real r-- The pressure below which the seal is determined to be deflated (mBar).

10.0

. sealPressure Inflated

real r-- The pressure above which the seal is determined to be inflated (mBar).

240.0

Table 16 ECS Aperture Cover Controller atst.tcs.ecs.cover Properties

EMCS Controller: atst.tcs.ecs.emcs (ECS.prop)



10.2.9.12



true

Table 17 ECS EMCS Controller atst.tcs.ecs.emcs Properties

PLC TAG CONFIGURATION 6.3

Communication between ECS and EMCS uses the native Allen-Bradley ControlLogix PLC data structure the PLC tag. The Enclosure to ECS ICD 5.0/5.6 [AD 4] defines all data transferred using the interface in terms of PLC tags. The ECS uses the PLCIO library to read PLC tags from and write PLC tags to the EMCS PLC. A PLC tag is defined by its name, length and the data types of its contents. As the ECS uses the PLCIO library to communicate using PLC tags the ECS uses its pc_format string to encode information from the ICD (regarding PLC tag contents) into format usable for PLC tag processing. The PLCIO 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 has 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. See the PLCIO User Manual for more information regarding pc_format strings and the showcip utility [RD 4].


The ECS stores all information relating to the PLC tags it uses, including pc_format string in the property DB. PLC tag information is stored in the property DB using a strict naming format. This enables the generic none-controller specific abplc package PlcTag class to be used to provide access to all tag information. All tag properties in the property DB begin with the string ‘.tag’, and all properties relating to a specific tag begin with ‘.tag:<tagName>’. The <tagName> is the name specified in the Enclosure to ECS ICD 5.0/5.6 [AD 4]. For example, all properties relating to the tag used to write position demands to the altitude shutter begin atst.tcs.ecs.alt.tag:W_altPos. All tags that a specific controller uses are in the property ‘.tagList’. Table 18 describes the generic format of controller PLC tag metadata properties for each tag defined for the controller’s use in the Enclosure to ECS ICD.

Property Name Type Access Description

.tagList string r-- List of EMCS PLC tag names used by this controller. Tag names must match those defined in the Enclosure to ECS ICD 5.0/5.6 [AD 4].

.tag:<tagName> string r-- For each tag named in the .tagList a tag property exists, if it does not the ECS does not use the tag.

.tag:<tagName> :pcformat

string r-- The PLCIO pc_format string describing all data items contained in this tag (see above).

.tag:<tagName> :direction

string r-- The direction, either read or write, that the tag may be communicated with the EMCS.

.tag:<tagName> :plcioTimeout

real r-- The timeout in seconds used in all PLCIO plc_read() or plc_write() calls when communicating this tag with the EMCS PLC

.tag:<tagName> :connectionStatus

boolean r-- True once connection channel to EMCS PLC has been opened for this tag, otherwise false.

.tag:<tagName> :lastUpdateTime

string r-- The time this tag was last read from or written to the EMCS PLC tag.

.tag:<tagName> :itemList

string r-- List of all data items contained in this tag. Item names follow closely those used in the Enclosure to ECS ICD but do not need to match them exactly, as unlike tag names, item names are not used to gain access to data from the EMCS. They are simply an identifier for a specific byte (or sequence of bytes) that stores a specific data item contained in the tag.

.tag:<tagName> :<itemName>

[boolean | integer | real]

r-- For each data item named in tag’s :itemList a property exists. If this tag defines its .direction as write, this property contains the default value of this tag data item.

.tag.<tagName> :<itemName>:bitPos

integer r-- When data item is of type boolean this property contains the item’s bit position in the current tag member.

Additional properties of tags read at defined interval by a Posting TAB:

.tag:<tagName> :interval

real r-- The interval in seconds at which the tag is to be read from the EMCS PLC.


Property Name Type Access Description

.tag:<tagName> :enabled

boolean rw- When true the tag is read from the EMCS PLC at interval defined in :interval.

.tag:<tagName> :reconnectInterval

real r-- The interval in seconds at which attempts will be made to open channel to read tag if channel is unable to be opened.

Table 18 Controller PLC generic tag metadata property format.

All PLC tag properties used by ECS controllers and representing the current Enclosure to ECS ICD are included with the ECS software in ECSPlcTag .prop files, see Table 3, section 5.2.5.1.

FACTORY DEFAULT RESET 6.4

To perform a factory default reset of the ECS the .app and .prop files discussed in sections 6.1 and 6.2 are required:

ECS.app – file containing ECS factory default values for application tables of property DB.

VEMCS.app – file containing VEMCS simulator factory default values for application tables

of property DB.

ECSPlcTags[Alt|Aux|Az|Cover|Emcs].prop – file containing the respective controller’s EMCS PLC tag metadata properties describing the Enclosure to ECS ICD, used by the

controller . Properties contained in these files shall not be changed unless a change to the

the ICD 5.0/5.6 (see [AD 4]) is made.

ECS.prop – file containing ECS factory default values for controller property table of

property DB.

VEMCS.prop – file containing VEMCS simulator factory default values for controller

property table of property DB To ensure the data in these files are the only data loaded into the application tables and property table of the property DB, all current values in the DB relating to the ECS can be deleted using the following ECS scripts contained in the ecs package scripts directory:

ecsAppRm – used to delete all ECS and VEMCS entries in the application tables.

ecsPropsRm – used to delete all ECS and VEMCS entries in the property tables. To reload the data from provided files the AppReader and PropertyReader applications are used. These applications are provided as part of the CSF infrastructure. The following ECS scripts use these applications to load all necessary data:

ecsAppLoad – used to load the application tables.

ecsPropsLoad – used to load the property tables. All ECS script (.sh) source files are located in the ECS scripts directory $ATST/src/java/atst/ecs/scripts and installed from this directory into $ATST/bin at ECS build time (see section 5.2.6).


7 RU NNI NG TH E E C S

STARTUP SCRIPT 7.1

The ECS application can be started as a standalone application (without the need for container managers) by using the ECS startup script. The script is located here:

$ATST/src/java/atst/ecs/scripts/ecsStart.sh

and once installed into $ATST/bin (see section 5.2.6) is run by issuing the command: ecsStart

The script starts the ECS application and the VEMCS simulator (see section 11). The JES screens can also be automatically started with the script. The following command line options are available for the script:

--noVEMCS – do not start the EMCS simulator (VEMCS) prior to starting the ECS.

--jes – start the ECS Main JES display.

--jesVEMCS – start the VEMCS simulator JES main display. To use the script to start the ECS, VEMCS and associated JES screens the following command would be used: ecsStart --jes --jesVEMCS

The script is a bash script that can be executed from any terminal, it starts the CSF Testharness and executes a Testharness script to issue the relevant Testharness commands to startup the ECS application. Following completion of the startup script the Testharness command-line remains accessible through the terminal in which the script was run (the Testharness is documented in [RD 3]). NB. When starting the atst.tcs.ecs controller from the Testharness using the commands startup atst.tcs.ecs (as done in above ecsStart script) the harness expects the command to complete within 10 seconds, however, the setting of the default hardware state that occurs at startup (and shutdown) takes longer than 10 seconds, therefore the following failure message is expected and can be ignored: performing startup

startup on atst.tcs.ecs has not completed in 10 seconds

atst.tcs.ecs failed to start (it is still trying)

start failed

SHUTTING DOWN THE ECS 7.2

Following use of the startup script described in the previous section the ECS is shutdown by issuing the following commands at the Testharness prompt:


atst> shutdown atst.tcs.ecs

atst> uninit atst.tcs.ecs

atst> shutdown atst.tcs.ecs.vemcs

atst> uninit atst.tcs.ecs.vemcs

NB. When stopping the atst.tcs.ecs controller from the Testharness using the commands shutdown atst.tcs.ecs the harness expects the command to complete within 10 seconds, however, the setting of the default hardware state that occurs at shutdown (and startup) takes longer than 10 seconds, therefore the following failure message is expected and can be ignored: performing shutdown

shutdown on atst.tcs.ecs has not completed in 10 seconds

atst.tcs.ecs failed to shutdown (it is still trying)

shutdown failed Alternatively the JES screens’ lifecycle widgets can be used to shutdown and uninitialize the ECS and VEMCS management controllers. To exit the ECS container and Testharness issue the following commands at the Testharness prompt: atst> drop ECS1

atst> quit

ECS CONTROLLERS 7.3

The ECS application uses a number of CSF controllers, which are managed by a single management controller. Each controller is responsible for a specific area of ECS responsibilities equating to a specific part of the enclosure. A brief description of the ECS controllers and their responsibilities are given below, for full details see the ECS Software Design Description [AD 6].

atst.tcs.ecs – this is the top-level management controller of the ECS. It manages the lifecycle of all other ECS components and all configurations for the ECS from the TCS (using ICD 4.4/5.6 [AD 3]) are submitted to this controller.

atst.tcs.ecs.alt – this is the atst.tcs.ecs sub-controller responsible for all operations of the altitude shutter.

atst.tcs.ecs.az – this is the atst.tcs.ecs sub-controller responsible for all operations of the azimuth carousel.

atst.tcs.ecs.aux – this is the atst.tcs.ecs sub-controller responsible for all operations of the auxiliary equipment of the enclosure including the calibration camera.

atst.tcs.ecs.cover – this is the atst.tcs.ecs sub-controller responsible for all operations of the aperture cover.

atst.tcs.ecs.emcs – this is the atst.tcs.ecs sub-controller responsible for ensuring the EMCS PLC is in the correct state for ECS operations.

ECS CONFLICTING ATTRIBUTES 7.4

The attributes that the ECS accepts to control the enclosure, and events it publishes to return enclosure status, are detailed in the TCS to ECS ICD 4.4/5.6 [AD 3]. The top-level ECS application management controller is the atst.tcs.ecs and all configurations for the ECS application from the TCS are submitted


to this controller. As a management controller it propagates attributes that are destined for its sub-controllers to the specified controller. Some of the ECS attributes are mutually-exclusive, i.e. they cannot be submitted in the same configuration as their combination cannot be interpreted without contradiction. A configuration containing conflicting attributes submitted to the ECS will be rejected. The tables below detail TCS to ECS ICD attributes that may be given conflicting values that will not be accepted by the ECS. Details of conflicting attributes can also be found in the TCS to ECS ICD.

ECS Management Controller: atst.tcs.ecs

Attributes Conflict

.mode and .trackId Attribute .mode=tracking or configuration is rejected.

.mode and .namedPos Attribute .mode=active or configuration is rejected.

.trackId Current ECS .mode must be tracking or configuration is rejected.

.namedPos Current ECS .mode must be active or configuration is rejected.

Table 19 Conflicting attributes of atst.tcs.ecs controller

Altitude Shutter Controller: atst.tcs.ecs.alt and Azimuth Carousel Controller: atst.tcs.ecs.az

Attributes Conflict

.mode and .trackId Attribute .mode=tracking or configuration is rejected.

.mode and .namedPos Attribute .mode=active or configuration is rejected.

.mode and .pos Attribute .mode=active or configuration is rejected.

.trackId Configuration is rejected if controller is currently tracking and the .trackId value equals value of the currently in use configuration trackId (i.e. this trackId equals the last submitted trackId).

.oPos and any other attributes

Attribute .oPos is rejected if the configuration contains any other attributes.

.jogVel and any other attributes

Attribute .jogVel is rejected if the configuration contains any other attributes.

.pos .namedPos .oPos

.jogVel If configuration contains more than one of these attributes it is rejected.

[.pos | .namedPos | .oPos | .jogVel]

Current ECS .mode must be active or configuration is rejected.

[.posTol | .velTol] Current ECS .mode must be off or configuration is rejected.

Additional conflicts of the Altitude Shutter Controller: atst.tcs.ecs.alt

.seal and .mode If .seal=inflate .mode must be off or configuration is rejected.

.seal If .seal=inflate current ECS .mode must be off or configuration is rejected.

Table 20 Conflicting attributes of atst.tcs.ecs.alt and atst.tcs.ecs.az controllers

The aperture cover controller atst.tcs.ecs.cover and auxiliary equipment controller atst.tcs.ecs.aux have no conflicting attributes.


ECS HEALTH 7.5

All ECS controllers use the CSF health service (see [AD 9]) to maintain the their health condition. Each controller uses the CSF Health.set() method to set its health. If any conditions indicating poor health are recognized the controller’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 general criterion for the setting of a component’s health is based upon the current state of the hardware for which the controller is responsible. If the status of the hardware shows a failure of hardware has occurred then health will be set ILL or BAD depending upon the severity. This contrasts with the controller raising an alarm, which will occur when hardware has not failed but for other reasons the mechanism is not able to respond as requested, e.g. a limit has been reached, etc. In regards to the health of a controller based upon the status of hardware for which the controller is responsible, the following set of criteria is used:

GOOD if hardware status is showing hardware can be fully controlled as required for operational purposes, e.g. no hardware failures are present.

ILL if hardware status is showing state of the hardware will enable control but not using its full capabilities, e.g. one azimuth carousel motor drive is showing a failure.

BAD if hardware status is showing hardware will be unable to operate and observing will be unable to occur, e.g. failure of lubrication-pump that prevents movement of mechanism.

In accordance with CSF guide lines the health of ECS controllers does NOT depend on the health of any controllers lower in the hierarchy e.g. the ECS management controller atst.tcs.ecs does not automatically set its health to BAD if any of its sub-controllers set their health to BAD. Each ECS controller uses a number of health categories of which each may be set GOOD, ILL or BAD. The health categories used by ECS controllers are listed in Table 21.

Health Category Description Controllers

Calibration_ Camera_HW

Used by ECS auxiliary equipment controller when the EMCS PLC reports a failure in the calibration camera hardware.

atst.tcs.ecs.aux

cStatus_Data Used by ECS controllers when failure occurs getting data for cStatus event.

All

cPos_Data Used by ECS controllers when failure occurs getting data for cPos event.

atst.tcs.ecs atst.tcs.ecs.alt atst.tcs.ecs.az

Default_State Used by ECS controllers when failure occurs setting hardware to default state. This does not relate to problems due to hardware failures but to the ECS's inability to demand the hardware into the default state and clarify that it has obtained the default state, e.g. because the controller is not currently able to read the current hardware status.

atst.tcs.ecs.alt atst.tcs.ecs.az atst.tcs.ecs.cover atst.tcs.ecs.aux


Health Category Description Controllers

Drive_HW Used by ECS controllers when a failure occurs in their drive hardware, including power, motor, brakes, over-current, encoder, etc.

atst.tcs.ecs.alt atst.tcs.ecs.az atst.tcs.ecs.cover

ECS_SubControllers Used by the ECS management controller when the ECS's capabilities are limited due to problems with the management controller's sub-controllers. E.g. unable to connect to one or more of its sub-controllers.

atst.tcs.ecs

ECS_Mode_Mismatch Used by the ECS management controller when its configured .mode is different from the altitude shutter and/or azimuth carousel sub-controllers' .mode.

atst.tcs.ecs

EMCS_Channel_Err Used by ECS controllers when a request to communicate with the EMCS PLC fails, i.e. opening/closing channel or reading/writing to/from the PLC returns an error.

atst.tcs.ecs.alt atst.tcs.ecs.az atst.tcs.ecs.cover atst.tcs.ecs.aux atst.tcs.ecs.emcs

EMCS_Connection Used by ECS controllers when unable to connect to the EMCS PLC.


EMCS_PLC_Failure Used by ECS EMCS controller when the EMCS PLC reports an internal failure.

atst.tcs.ecs.emcs

EMCS_PLC_Time Used by ECS EMCS controller when unable to successfully set the EMCS PLC time at controller startup.

atst.tcs.ecs.emcs

Enclosure_Lights Used by ECS auxiliary equipment controller when the EMCS PLC reports any enclosure lights are on

atst.tcs.ecs.aux

EnclosureToEcs IcdMissmatch

Used by ECS management controller when the Enclosure to ECS ICD 5.0/5.6 in use by the EMCS PLC is different than that in use by the ECS.

atst.tcs.ecs

Interlocked Used by ECS controllers when unable to demand hardware movement and correctly ascertain current hardware status due to controller's interlock being raised.

atst.tcs.ecs.alt atst.tcs.ecs.az atst.tcs.ecs.cover atst.tcs.ecs.aux

Seals_HW Used by ECS controllers when failure occurs in their seal hardware.

atst.tcs.ecs.alt atst.tcs.ecs.cover

Shutter_Latches_HW Used by ECS altitude shutter controller when the EMCS PLC reports a failure in the shutter latch hardware.

atst.tcs.ecs.alt

Table 21 ECS Health Categories.


The current health status of all ECS controllers is displayed on the ECS JES engineering interfaces described in section 8 of this document, specifically 8.3.3 ECS Main screen Lifecycle and Health tab and 8.4.6.1 ECS Engineering SYSTEM screen's Health Information. All ECS controllers publish their current health status in their .cHealth event. When controller's health is GOOD this event contains the attribute .health containing current health value. When the controller's health is not GOOD the event also contains the attribute .reason with value containing all current reasons for health being ILL or BAD. This event is used by the screen described in section 8.4.6.1 to display the cause(s) for a controller's health not being GOOD.

ECS ALARMS 7.6

ECS controllers use the CSF alarm service (see [AD 9]) to raise alarms. Controllers 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 7.5) ); 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. The alarms that the ECS generates are described in Table 22.

Alarm Posted By Description

EMCS in Local Control

atst.tcs.ecs.emcs The EMCS PLC may be controlled locally from its HMI, when this is the case it will not accept any demands to move enclosure hardware from the ECS, therefore all configurations submitted to the ECS management controller atst.tcs.ecs will be rejected. The EMCS controller atst.tcs.ecs.emcs ascertains the current local control status of the EMCS PLC from a data item contained in its read tag R_emcsCStatus, when this item is true the controller raises this alarm.

TCS Trajectory Data is Null

atst.tcs.ecs.alt atst.tcs.ecs.az

When ECS is tracking the tracking mechanism controllers subscribe to the TCS trajectory event to obtain the coefficients used to calculate position demand for the tracking axis. If the coefficient for the axis in the event is null then this alarm is raised.

TCS Trajectory Data Out-of-Range


The coefficient received in the TCS trajectory event is interpolated by the tracking controller's connection to obtain the actual position demand and calculate the velocity to demand the mechanism. If the coefficient produces a position or velocity demand out-of-range then this alarm is raised.


Alarm Posted By Description

Tracking Position Demand Channel Closed


When tracking is started on receipt of configuration containing .mode=tracking, the tracking controllers open a channel to the EMCS PLC to write their W_Pos tag containing tracking position demands. If at any time while tracking continues the channel becomes unavailable this alarm is raised.

Tracking Latency atst.tcs.ecs.alt atst.tcs.ecs.az

When tracking the tracking controller monitors the time taken between the time TCS trajectory event is received and time position demand is sent to the hardware, if this time exceeds the value of controller's property .trajectoryLatencyAlarm this alarm is raised.

Track IDs Not Equal


The TCS trajectory event contains the attribute .trackId, if the value of this attribute does not match the value submitted in configuration using attribute .trackId for longer than controller's property .trackIdsNotEqualAlarm value, then this alarm is raised.

Trajectory Callback


Once tracking has been started if the tracking controller does not receive a TCS trajectory event for longer than controller's property .trajectoryCallbackAlarm value, then this alarm is raised.

Table 22 ECS Alarms.


8 U S I NG TH E E C S E NG I NE E R I NG I NTE R FAC E S

This section details how to operate the ECS using the provided ECS Engineering Interfaces. The engineering screens provide full access to all the ECS capabilities offered to the TCS through the TCS to ECS ICD 4.4/5.6 [AD 3]. In addition they offer engineering only capabilities that are outside the scope of normal operations carried out by the TCS. For instructions on how to use the screens to perform various enclosure operations see section 9 User Scenarios. All ECS engineering screens are implemented using the Java Engineering Screen (JES) toolkit provided as part of the CSF, for details see [RD 2]. Therefore, their look-and-feel will be familiar to any user with previous experience of JES based interfaces.

STARTING THE ECS ENGINEERING INTERFACES 8.1

The ECS JES screens are started using the following commands, ensure that the terminal from which the screens are to be started has the correct $ATST and $PATH set (see section 5.2.1). To start the ECS Main screen providing access to all TCS level operations (i.e. as defined in TCS to ECS ICD 4.4/5.6 [AD 3]) use the command: JES –-file=ecs/ECS_Main.xml

To start the screen providing access to all EMCS level operations (i.e. as defined in the Enclosure to ECS ICD 5.0/5.6 [AD 4]) use the command: JES –-file=ecs/ECS_Engineering.xml

The VEMCS simulator JES screen is started using: JES –-file=ecs/vemcs/VEMCS_Main.xml

INTERACTING WITH THE ECS ENGINEERING INTERFACES 8.2

As the ECS engineering interfaces are implemented using JES their general operation is the same as all JES screens. For full instructions on using the JES see the JES User Manual [RD 2].

THE ECS TCS ENGINEERING INTERFACE 8.3

The ECS Main screen provides access to the ECS using the attributes and events as defined in the TCS to ECS ICD 4.4/5.6 [AD 3]. All configurations submitted by the screen are submitted to the ECS management controller atst.tcs.ecs; no configurations are submitted directly to the management controller's sub-controllers, in this way the screen mimics how the TCS submits configurations to the ECS. NB. The screenshots shown in this section of the document are taken with the ECS connected to the EMCS simulator (VEMCS). Prior to a user explicitly setting the status representing specific enclosure


hardware (i.e. read by the ECS and published in cStatus events) the VEMCS sets values to a default value; routinely a Boolean value will be set to false and a floating point value to 999.999. Therefore, the ECS screenshots shown here will display these values for hardware status of the enclosure that the VEMCS does not actively simulate. Generally the VMECS only simulates enclosure hardware status necessary to simulate behavior required for TCS operations, however, all VEMCS values can be updated by the user if required through the VEMCS_Main JES screen and/or by submitting configurations to the VEMCS controllers (for details see section 11 Virtual EMCS Simulator).


Figure 1 shows the JES screen ECS_Main.xml as it appears when initially started using command detailed in section 8.1. The upper-half of the screen contains widgets displaying overall status and giving access to commands of the ECS (made available by the ECS management controller atst.tcs.ecs). The lower-half of the screen contains a tabbed-panel giving access to specific areas of the ECS. The

tabs Altitude Shutter, Azimuth Carousel, Aperture Cover, Auxiliary Equipment and EMCS provide status and

commands provided by the ECS management controller’s sub-controllers. The tab Generate TCS

Trajectory is used to provide a simulated TCS trajectory event for the ECS that can be used during

testing. Each of the tabs are described in subsequent sections of this document.


Figure 1 ECS Main screen on startup.

The ECS Mode custom configuration JES widget submits to the ECS a configuration containing the

attribute .mode with value equal to the button pushed:

OFF results in the ECS tracking mechanism controllers (atst.tcs.ecs.alt controlling the altitude

shutter and atst.tcs.ecs.az controlling the azimuth carousel) placing their hardware into the off (default) state, with motors powered off and brakes engaged.

ACTIVE results in the tracking mechanism controllers placing their hardware into the active

state, with motors powered on, brakes disengaged and EMCS PLC servos actively holding position at the hardware's position when the ECS controller received the configuration.

TRACKING results in a configuration being submitted to start the tracking mechanisms tracking

the TCS trajectory demands published in the event atst.tcs.ecsTrajectory. The .trackId attribute that must be submitted in a configuration containing .mode=tracking (see section 7.4 ECS Conflicting Attributes), will be given a value equal to the trackId currently being published in the atst.tcs.ecsTrajectory event. If no TCS trajectory event is currently being published the configuration submitted to the ECS will be rejected as it contains .mode=tracking but no


.trackId attribute. Rejection of the configuration will be notified to the user in the widget's

Report: display item.

The ECS Move custom configuration JES widget submits to the ECS a configuration containing the

attribute .mode=active together with attribute [.alt|.az].pos or [.alt|.az].namedPos:

.alt.pos is submitted when checkbox Altitude Shutter is selected and a position demand value is

entered in Position: text entry box.

.alt.namedPos is submitted when checkbox Altitude Shutter is selected and Position: text entry box

contains no value. The named position demanded in the configuration is equal to the named position selected from the drop-down list.

.az.pos is submitted when checkbox Azimuth Carousel is selected and a position demand value is

entered in Position: text entry box.

.az.namedPos is submitted when checkbox Azimuth Carousel is selected and Position: text entry

box contains no value. The named position demanded in the configuration is equal to the named position selected from the drop-down list.

If checkbox Altitude Shutter is selected while checkbox Azimuth Carousel is unselected, or vice-a-versa,

the axis not selected will be demanded to actively hold its current position. This is due to the submitted configuration always containing .mode=active.

Following submit of configurations using the ECS Mode and ECS Move widgets the status of the

altitude shutter and azimuth carousel will update in the tables on the screen located above the widgets,

once In Position is true for both controllers the overall ECS In Position will become true.

The TCS Trajectory table Track ID and Timestamp display the current values published in the TCS

trajectory event. The character "?" (question mark) will be displayed until valid TCS trajectory event data have been received (this is a property of all JES widgets configured to receive event data, see [RD 2])

8.3.2 ECS Main screen GIS Interlock and EMCS Local Control Status

The overall ECS GIS interlock is shown in the Enc. Interlock display item positioned towards top-left of

the ECS Main screen. It will become true (colored red) when the atst.gis.interlock event signals the ECS interlock has been raised by publishing the .ecsInterlock attribute with value true. When the interlock is raised the ECS controllers will immediately demand their default (de-powered, none moving) state and for the duration the interlock remains raised the ECS will accept no configuration. The ECS hardware sub-controllers also respond in the same manner to their individual interlock attributes, the status of which is displayed above the controller's respective tab on the screen. Please note, the Lifecycle and Health tab contains the status of various enclosure interlocks as obtained from the EMCS PLC not the GIS. It is to be expected that the alerting of an interlock by the GIS will occur in unison with the corresponding notification from the EMCS PLC, however, the method of communication used between ECS and EMCS PLC is not fail-safe, therefore if communication is lost between PLC and ECS and an interlock occurs the interlock information provided by the GIS will not


match the interlock status obtained from the EMCS PLC. The ECS only asserts its default state when notified of an interlock by the GIS. No action is taken by the ECS on change to interlock status obtained from the EMCS PLC. The enclosure hardware can also be controlled locally to the hardware (as opposed to remotely using

the ECS) through the EMCS HMI. When the EMCS is under local control the Enclosure Hardware

Under Local Control display item will be true (colored red) and the ECS management controller will

accept no configurations to move enclosure hardware.


The Lifecycle and Health tab of the ECS Main screen (see Figure 1) displays JES lifecycle and health

widgets for all ECS sub-controllers and the ECS container (in which all ECS software controllers run).

Issuing lifecycle change commands (Initialize, Start, Shutdown, Uninitialize) to the ECS management

controller using the JES lifecycle widget in top-left of screen, will cause all of the sub-controllers’ lifecycles to change as demanded and this will be displayed on the Lifecycle tab. As noted in previous section 8.3.2 ECS Main screen GIS Interlock and EMCS Local Control Status this tab contains enclosure interlock status obtained from the EMCS PLC. It is provided for information purposes only and forms no part of the enclosure interlock chain. The ECS only reacts to an interlock (i.e. asserts its default state) when notified of an interlock by the GIS, it takes no action on change to interlock status obtained from the EMCS PLC.

Also displayed on this tab is the Connection simulation status of the ECS sub-controllers. A controller

with connection simulation status of true signals that this controller's connection is currently connected

to the VEMCS simulator (see section 11 Virtual EMCS Simulator) not the real enclosure's EMCS PLC. A controller's simulation status depends upon value of property .connection:isSimulated (see section 6.2 Controller Configuration). The buttons ECS Eng. Screen and VEMCS Screen when pushed open the ECS Engineering (see section 8.4) and VEMCS (see section 11.4) JES screens respectively.

8.3.4 ECS Main screen Altitude Shutter tab

Figure 2 shows the ECS Main screen’s Altitude Shutter tab accessing the altitude shutter sub-controller

atst.tcs.ecs.alt. As with all of the sub-controller tabs, this tab provides access to the sub-controller using the interface defined for the controller in the TCS to ECS ICD [AD 3]. The top of the panel displays current altitude shutter enclosure hardware status as published in the atst.tcs.ecs.alt.cStatus event. Below the hardware status are the following JES custom configuration widgets:

Altitude Shutter Mode – this operates in the same manner as the ECS Mode widget but results in

configuration demanding only the altitude shutter's mode.

Altitude Shutter Move – this widget allows the user to submit a configuration containing any of

the positional ICD attributes; .pos, .namedPos, .oPos and .jogVel. The radio buttons are used to select the type of positional move required; the appropriate entry item becomes available when


button is selected. Pressing the Submit button submits the configuration to the ECS

management controller.

Altitude Shutter Seal Inflation – use this widget to submit configuration to control the inflated

and deflated status of the seals. NB. The EMCS PLC has responsibility for deflating the seals prior to disengaging brakes and powering on mechanism's motors when .mode=[active|tracking] is submitted and likewise when movement is stopped when .mode=off is submitted the EMCS inflates the seals.

Altitude Shutter InPosition Tolerances – depending upon checkbox[s] selected submits a

configuration to modify the tolerance used when determining .inPosition status published in the controller's cStatus event. When a checkbox is selected the saved value of the attribute in the

property DB is retrieved and displayed in the Saved Value display item.

Positioned between the Altitude Shutter Move and Altitude Shutter InPosition Tolerances widgets is the

To EMCS table. This displays the current values the ECS is sending to the EMCS PLC in the axis' Pos

tag. The Pos tag is used by the ECS to communicate to the EMCS the demanded position required. The values demanded depend upon the last configuration submitted to the ECS. For full details of how the ECS uses and communicated PLC tags see the ECS SDD [AD 6].

Pressing the buttons Motors or Seals & Latches display screens showing their respective status as

published in the atst.tcs.ecs.alt.cStatus event.

Figure 2 ECS Main screen Altitude Shutter tab.

8.3.5 ECS Main screen Azimuth Carousel tab

Figure 3 shows the ECS Main screen’s Azimuth Carousel tab accessing the azimuth carousel sub-

controller atst.tcs.ecs.az. The layout and operation of the widgets are the same as those described in the

previous section for the Altitude Shutter tab, without the altitude shutter specific items relating to the

seals and latches.


Figure 3 ECS Main screen Azimuth Carousel tab.

8.3.6 ECS Main screen Aperture Cover tab

Figure 4 shows the ECS Main screen’s Aperture Cover tab accessing the aperture cover sub-controller

atst.tcs.ecs.cover. The top of the panel displays current aperture cover enclosure hardware status, including motor drive information as published in the atst.tcs.ecs.cover.cStatus event. The current position

status of the cover is always visible towards the top-left of ECS Main screen in the Aperture Cover

display item, so that it is accessible when not viewing the aperture cover's specific tab. The aperture cover is only in state closed when the cover's position is in the closed state and the cover's seal is inflated. Likewise, the cover is only in the open state when its position is open and the cover's seal is deflated.

The JES custom configuration widget Aperture Cover Demand submits configurations to the ECS

containing attribute .cover.pos with value open or close to demand the cover's position.


Figure 4 ECS Main screen Aperture Cover tab.

8.3.7 ECS Main screen Auxiliary Equipment tab

Figure 5 shows the ECS Main screen’s Auxiliary Equipment tab accessing the auxiliary equipment sub-

controller atst.tcs.ecs.aux. The top of the panel displays current auxiliary equipment enclosure hardware status as published in the atst.tcs.ecs.aux.cStatus event. When the calibration camera is not enabled the event does not contain the camera's X and Y position errors.

The JES custom configuration widget Calibration Camera Enable submits configurations to the ECS

containing attribute .aux.camera:enable with value on or off to demand the camera's state.

Figure 5 ECS Main screen Auxiliary Equipment tab.


8.3.8 ECS Main screen EMCS tab

Figure 6 shows the ECS Main screen's EMCS tab accessing the EMCS sub-controller atst.tcs.ecs.emcs.

This controller does not form a part of the TCS to ECS ICD, i.e. it accepts no configurable attributes from the TCS and publishes no events that systems outside of the ECS subscribe to; it provides access to internal ECS operations relating to the enclosure's EMCS PLC, e.g. monitoring of the PLC system status.

The EMCS PLC Time display shows the current clock time of the EMCS PLC as read from the PLC in

the R_emcsCStatus tag. When connected to the real EMCS PLC hardware this will update at the rate of 1Hz, i.e. the rate the R_emcsCStatus tag is read from the PLC, however, when connected to the VEMCS simulator the time will only update when explicitly demanded to do so from the ECS, i.e. at

ECS startup or when the Update EMCS PLC Time button is pushed.

When the Update EMCS PLC Time button is pushed of the Set EMCS PLC Time custom configuration

widget the EMCS sub-controller atst.tcs.ecs.emcs obtains the current time by calling AtstDate.getCurrent(). This is then sent to the EMCS PLC using the write tag W_emcsCmds.

The EMCS PLC High Speed Logging custom configuration widget is used to demand the EMCS PLC to

start (turn on) and stop (turn off) its high speed data acquisition. The current status of the EMCS PLC

high speed logging is displayed above the custom configuration widget and can be one of notRunning,

running or finished. Above this is displayed the name of the file on the EMCS PLC in which the data

gathered during acquisition has been stored. In the screen-shot in Figure 6 the file name displayed is

HighSpeedAcquisitionFileNotWritten, which is the default value returned by the VEMCS simulator prior

to demanding the high speed logging to be started.

Figure 6 ECS Main screen EMCS tab.


8.3.9 ECS Main screen Generate TCS Trajectory tab

This tab displays the JES custom widget TCS simulated trajectory stream that enables the user to

configure a TCS trajectory event stream in the correct format for the ECS. This enables the ECS tracking capabilities to be tested without having access to the TCS. The tab is shown in Figure 7. Figure 7 shows the tab configured and generating a TCS trajectory event stream. The top-half of the

widget contains items to configure the trajectory stream that is generated. The Type of stream selected;

Fixed Demand, Ramp or Sine Wave, updates the Parameters displayed to enable the particular stream

type to be configured as required. In this screen shot a Ramp is being used, with demands for the

azimuth carousel starting at -100.0 degrees and progressing to 100.0 at a rate of 0.05 degrees/second. The altitude shutter demands will begin at 12.3 degrees and progress to 88.9 at a rate of 0.05 degrees/second.

The lower-half of the widget contains buttons to Start and Stop the event and the ID button. The ID

button when pushed generates a new .trackId attribute value (see TCS to ECS ICD [AD 3]) that will be sent with the trajectory stream coefficients in the generated event. For the ECS to obtain in position of true the .trackId sent in the TCS trajectory event and submitted in a configuration to the ECS must match. Therefore, to demand the ECS to track the trajectory stream being generated as shown by widget in Figure 7 a configuration containing the .trackId=trackID.6435.307 would be submitted to the ECS management controller. For example, using the CSF Testharness this could be achieved using the following commands: atst> new config trackCfg

atst> add trackCfg "atst.tcs.ecs.mode" "tracking"

atst> add trackCfg "atst.tcs.ecs.trackId" "trackID.6435.307"

atst> submit atst.tcs.ecs trackCfg

Alternatively once the TCS trajectory event has been started, pushing the TRACKING button in the ECS

Mode JES custom widget (towards top-left of ECS Main screen), will query the event to obtain the

current .trackId from the trajectory and submit the correct configuration to the ECS to begin tracking.


Figure 7 ECS Main screen Generate TCS Trajectory tab.


THE ECS EMCS ENGINEERING INTERFACE 8.4

This section of the document describes the ECS screens provided to give access to all ECS interactions made available through the Enclosure to ECS ICD 5.0/5.6 [AD 4]. The screens also give access to the all attributes and events as defined in the TCS to ECS ICD 4.4/5.6 [AD 3] in a manner that is less constrained than the ECS Main screen described in section 8.3. Figure 8 shows the JES screen ECS_Engineering.xml as it appears when initially started using command detailed in section 8.1.

Figure 8 ECS Engineering screen

All the buttons positioned in the blue bar at the bottom of the screen when pushed open a new screen.

The buttons AZIMUTH, ALTITIDE, AUX EQU... and COVER open screens giving direct access to the

respective ECS controllers responsible for that part of the enclosure hardware. Each screen enables the user to submit configurations directly to the ECS hardware sub-controllers, in contrast to the ECS Main screen that only submits configurations to the ECS management controller atst.tcs.ecs. All four of the ECS engineering hardware sub-controller screens follow a similar pattern; the left-half of the screen contains a JES custom configuration widget allowing the user to construct and submit configurations to the controller using the Enclosure to ECS ICD interface items (contained in EMCS PLC write tags), or using the TCS to ECS ICD attributes. On the right-half of the screen is displayed the enclosure hardware status as read from the EMCS PLC using the read tags defined in the Enclosure to ECS ICD and the status event(s) published by the controller as defined in the TCS to ECS ICD. The status event displays are updated at the rate defined for publication of the event in the TCS to ECS ICD. Update to the display of EMCS PLC read tag data is only done on user request by pushing of

button Get Cache Values. As the button name suggests, the pushing of this button only displays the

current value of the tag stored in the controller's CSF Cache; it does not cause the tag to be re-read from the EMCS PLC. Read tags are read by the ECS from the EMCS PLC at frequency to ensure data required for the TCS status events is always updated prior to event publication.


The buttons DATA and SYSTEM give access to information regarding the current configuration and working capability of the ECS and enclosure. The following sections give more individual detail about all screens accessible from the ECS Engineering screen.

8.4.1 ECS Engineering AZIMTH screen

Pushing the button AZIMTH on the ECS Engineering screen displays the azimuth carousel engineering

screen shown in Figure 9.

Figure 9 ECS Engineering AZIMUTH screen

The screen submits configurations directly to the azimuth carousel controller atst.tcs.ecs.az and displays all attributes published in the controller's cPos and cStatus events. The controller controls the enclosure's azimuth carousel by writing the EMCS PLC tags W_azCmds and W_azPos and reads back the current hardware status using the tags R_azCStatus and R_azCPos.

8.4.2 ECS Engineering ALTITUDE screen

Pushing the button ALTITIDE on the ECS Engineering screen displays the altitude shutter engineering



Figure 10 ECS Engineering ALTITUDE screen

The screen submits configurations directly to the altitude shutter controller atst.tcs.ecs.alt and displays all attributes published in the controller's cPos and cStatus events. The controller controls the enclosure's altitude shutter by writing the EMCS PLC tags W_altCmds and W_altPos and reads back the current hardware status using the tags R_altCStatus and R_altCPos.

8.4.3 ECS Engineering AUXILARY EQUIPMENT screen

Pushing the button AUX EQU... on the ECS Engineering screen displays the auxiliary equipment

engineering screen shown in Figure 11.

Figure 11 Engineering AUXILIARY EQUIPMENT screen

The screen submits configurations directly to the auxiliary equipment controller atst.tcs.ecs.aux and displays all attributes published in the controller's cStatus event. The cStatus event atst.tcs.ecs.aux.cStatus is published by the controller at the rate defined for it in the TCS to ECS ICD of 0.1Hz, for this reason the display of the cStatus attributes may remain blank for some seconds when the screen is first opened while it waits for an event to be published. The controller controls the


enclosure's calibration camera by writing the EMCS PLC tag W_auxCmds and reads back the current hardware status using the tag R_auxCStatus.

8.4.4 ECS Engineering APERTURE COVER screen

Pushing the button COVER on the ECS Engineering screen displays the aperture cover engineering


Figure 12 Engineering APERTURE COVER screen

The screen submits configurations directly to the aperture cover controller atst.tcs.ecs.cover and displays all attributes published in the controller's cStatus event. The cStatus event atst.tcs.ecs.cover.cStatus is published by the controller at the rate defined for it in the TCS to ECS ICD of 0.1Hz, for this reason the display of the cStatus attributes may remain blank for some seconds when the screen is first opened while it waits for an event to be published. The controller controls the enclosure's aperture cover by writing the EMCS PLC tag W_coverCmds and reads back the current hardware status using the tag R_coverCStatus.

8.4.5 ECS Engineering DATA screen

Pushing the button DATA on the ECS Engineering screen displays the DATA screen shown in Figure

13. This screen gives full access to all data (PLC tags) being transferred between the ECS controllers and the EMCS PLC using the Enclosure to ECS ICD 5.0/5.6 [AD 4]. All PLC tags used by a controller to write data to the EMCS to demand hardware movement and read from the EMCS to obtain hardware status are accessible.


Figure 13 ECS Engineering DATA screen

The large buttons on the screen (e.g. ICD Version, Az Commands, etc) relate directly to a PLC tag of a

controller, pushing one of these buttons will display a screen showing all information used by the ECS to communicate the tag (read at controller initialization from the Property DB) and the value of the

tag’s data items currently in the controller’s CSF Cache (read on user-demand when screen’s Get Cache

Values button is pressed). Figure 14 shows the screen displayed when the auxiliary equipment

controller’s status PLC read tag is displayed by pushing the button Aux Status. The same format of

screen is used for all PLC read tags of all controllers. Pushing the button Read Tag submits a

configuration to the controller to demand the tag to be read from the EMCS PLC. The data read from

the PLC is placed in the controller’s CSF Cache and is displayed by pushing the button Get Cache

Values. However, other processes in the controller may also be currently reading the tag, e.g. to obtain

data required for controller’s cStatus event, and therefore it is not necessarily the case that the Read Tag

button has to be pushed to see a change to the tag’s data item Cache values when Get Cache Values

button is pressed.

Figure 14 ECS Engineering DATA screen showing Auxiliary Equipment controller's status PLC tag


Figure 15 shows the screen displayed when the azimuth carousel’s button Az Pos Demand is pushed.

The same format of screen is used for all EMCS PLC write tags of all controllers. It operates in the same manner as a PLC read tag data screen with the additional ability to update the values of the tag’s data items being written by the ECS to the EMCS PLC. The new value of a tag data item is entered into

the data item’s row of the Write Value table on right-side of screen. Pushing the button Write Tag

submits to the controller a configuration to demand the tag to be written to the EMCS PLC. The

values contained in Write Value table are used to update the tag data items values in the controller’s CSF

Cache and the tag is then written to the PLC. It is a constraint of transferring data using PLC tags that the whole tag must be written; it is not possible to write an individual tag data item to the PLC,

therefore tag data items that do not have a value in the Write Value table will be given their current

Cache value when the tag is written. As is the case with PLC read tags other ECS processes of the

controller may be updating the write tag’s Cache values and so pushing the Get Cache Values button

may display new tag data item values even when the Write Tag button has not been pressed. For

example, when the azimuth carousel controller is tracking the position and velocity tag data items will be updated in the Cache at a rate of 20Hz (frequency the tag is written to the PLC to send the trajectory position demands).

Figure 15 ECS Engineering Data screen showing Azimuth Carousel controller's position demand PLC tag

All PLC tag metadata (e.g. PLCIO pcformat, data item names, etc) displayed on the tag data screens are obtained from the respective controller at screen creation (i.e. when their button on the DATA screen is pushed); the only data configured in the screen are the controller and tag name. Therefore changes to PLC tag metadata stored in the Property DB and contained in the ECSPlcTags .prop files (see Table 3) will be displayed by the screens without any changes to their JES .xml files. The JES .xml files of the screens are located in the $ATST/resources/screens/ecs directory and begin with the prefix ECS_Data. All screens use the ECS custom JES widgets implemented in JesEcsDataPlcTagRead.java and JesEcsDataPlcTagWrite.java (or classes derived from them) located in $ATST/src/java/atst/ecs/widgets.

8.4.6 ECS Engineering SYSTEM screen

Pushing the button SYSTEM on the ECS Engineering screen displays the ECS system information

screen shown in Figure 16. The current lifecycle and health state of each ECS controller is displayed, as

is also shown on the ECS Main screen’s Lifecycle and Health tab (see section 8.3.3).


Figure 16 ECS Engineering SYSTEM screen

8.4.6.1 ECS Engineering SYSTEM screen's Health Information

Pushing a controller’s Health Information button displays a screen showing current health details of the

controller. The screen displayed when the ECS management controller's Health Information button is

pressed is shown in Figure 17. This shows the screen displayed when the controller's health is bad due to being unable to connect to its aperture cover sub-controller. To update the health information

displayed on the screen push the button Update health information.

Figure 17 ECS Engineering SYSTEM screen showing ECS management controller’s health.

The controller EMCS health information screens obtain all data displayed from the controller at screen creation time (i.e. when their button on the SYSTEM screen is pushed); the only data configured in the screen is the controller name. The JES .xml files of the screens are located in the $ATST/resources/screens/ecs directory and begin with the prefix ECS_CompHealth. All screens use the ECS custom JES widget implemented in JesEcsControllerHealthInfo.java located in $ATST/src/java/atst/ecs/widgets.

8.4.6.2 ECS Engineering SYSTEM screen's Connection to EMCS

Pushing a controller’s Connection to EMCS button displays a screen showing the current status of all

connections the controller is currently using to communicate with the EMCS. The screen displayed

when the altitude shutter’s Connection to EMCS button is pressed is shown in Figure 18. This shows the

controller currently has three open channels to the EMCS; two channels to read the PLC tags R_altCStatus and R_altCPos and a channel to write the W_altPos tag. These channels are those required to be opened when the controller is tracking, i.e. the TCS has submitted a configuration containing the attribute .mode with value tracking. The screen also shows that the controller is using


two PlcTag reader objects, instantiated from atst.ecs.abplc package class PlcTagReader.java (see Table 4), which are used to read the PLC tags containing data required for the controller’s cStatus and cPos events.

Figure 18 ECS Engineering SYSTEM screen showing Altitude Shutter controller’s EMCS connection information

The controller EMCS connection screens obtain all data displayed from the controller at screen creation time (i.e. when their button on the SYSTEM screen is pushed); the only data configured in the screen is the controller name. Therefore any changes to the controller’s connection details (e.g. the connection address) will be displayed on the screen without any changes to their JES .xml files. The JES .xml files of the screens are located in the $ATST/resources/screens/ecs directory and begin with the prefix ECS_Connection. All screens use the ECS custom JES widget implemented in JesEcsConnection.java located in $ATST/src/java/atst/ecs/widgets.

8.4.6.3 ECS Engineering SYSTEM screen's Controller Debug slider

The controller debug configuration sliders used on the ECS system screen are a modified version of the JES debug slider widget (see [RD 2]). They operate in the same manner as the JES debug slider apart

from the Category entry being replaced with a drop-down list populated at screen creation time with the

log debug categories used by the controller. The widget obtains the list of categories in use by a controller by doing a get of property specified when widget is placed on the screen during its development. All ECS controllers place their debug categories in use in the property .logCatList during initialization and startup. For this reason if the screen is started prior to controllers being in the running state not all log categories may be listed; if the list is empty pressing return in the editable pull-down list will cause the widget to do a get of its specified property, moreover as the list is editable the user can manually add any log category required. For details regarding log debug categories and their use see section 10.1 ECS Controller Debug Log Categories.


9 U S E R S C E NAR I OS

This section describes how the ECS may be used, from the ECS engineering interfaces, in various user scenarios. The user scenarios described here originate from the Use Cases described in the ECS Software Design Description [AD 6]. Each user scenario takes a use case and describes the operations the user must follow to accomplish the use case, by interacting with the ECS through the ECS JES screens.

INTIALIZING THE ECS 9.1

To initialize the ECS and all its sub-controllers use the ECS Main screen (see Figure 1, section 8.3.1).

Right-click the ECS Management Controller JES lifecycle widget (top-left of screen) and select Initialize

from the pull-down menu. This will change all ECS controllers from the uninitialized to initialized state,

which will be shown on the ECS Main screen Lifecycle and Health tab (see 8.3.3).

STARTUP 9.2

To startup the ECS and all its sub-controllers use the ECS Main screen (see Figure 1, section 8.3.1).

Right-click the ECS Management Controller JES lifecycle widget (top-left of screen) and select Start from

the pull-down menu. This will change all ECS controllers from the initialized to running state, which

will be shown on the ECS Main screen Lifecycle and Health tab (see 8.3.3).

START TRACKING AND TRACKING 9.3

On the ECS Main screen select the TCS Generate Trajectory tab and configure the TCS trajectory used

by the ECS using the TCS simulated trajectory stream JES custom widget (see section 8.3.9). Once the

trajectory event has been started push the TRACKING button (in ECS Mode JES custom widget). This

creates and submits to the ECS the correct configuration to demand all tracking axes to begin tracking the trajectory stream.

The TCS Trajectory, Alt Shutter and Az Carousel status displayed in top-right of the ECS Main screen

shall update showing that the ECS is now tracking and In Position goes to true.

START OBSERVING 9.4

On the ECS Main screen select the Aperture Cover tab and demand the ECS to open the aperture cover

by pushing the Open button in the Aperture Cover Demand JES custom widget (see section 8.3.6). Once

the cover is in the open position this will be shown in the Aperture Cover display item at top of screen

and observing can begin.


TCS RECEIVES NEW TARGET 9.5

This scenario involves the user demanding a different trackId than is being published in the TCS trajectory event. When the ECS tracking controllers receive miss-matching trackIds for longer than value of property .trackIdsNotEqualAlarm (default 0.5 seconds) the controllers stop tracking by demanding .mode=off and raise an alarm. To prevent this behavior occurring during this scenario the property's value must be increased to value sufficient to give user time to carry the change from good to bad to good trackId. Prior to beginning the operations of this scenario use the CSF PropertyEditor tool to modify the value of atst.tcs.ecs.alt.trackIdsNotEqualAlarm and atst.tcs.ecs.az.trackIdsNotEqualAlarm to value 60 seconds. The change to the property must be done while controller's mode is off. Start the ECS tracking following the instructions given in user scenario 9.3 Start Tracking and Tracking.

Once In Position becomes true the trackId contained in the trajectory event can be changed by pushing

the ID button on the TCS Generate Trajectory tab. The change to trackId is shown in the TCS Trajectory

table's Track ID column and In Position goes false. To submit a configuration containing the right trackId

(to ensure a match to the trajectory event’s trackId) push the TRACKING button in the ECS Mode JES

custom widget. This will cause In Position to go true as the ECS is now tracking the new target matching

both in position tolerances and trackIds. Note that during the time In Position was false the ECS

tracking mechanisms continued tracking the demands contained in the trajectory event and matching

their position tolerances; only the miss-match of trackIds was causing In Position to be false, it is for this

reason that In Position goes immediately true when trackIds do match without the necessity to wait

value of property .inPosToleranceTime (default value 3 seconds,) as would be the case if in position tolerances were not maintained. Return the . trackIdsNotEqualAlarm properties to their original values using either the PropertyEditor or by shutting down, uninitializing and restarting the controllers.

ZENITH BLIND SPOT 9.6

It is not possible to generate the TCS trajectory stream necessary to cause the ECS to track through the

zenith using the widget contained on the TCS Generate Trajectory tab. However, the ECS acceptance

test for ECS user requirement 5.6-0110 Zenith (see [AD 7]) does this and can be run and witnessed to view ECS behavior when tracking through the zenith.

INTERLOCK EVENT 9.7

To generate the atst.gis.interlock event containing any of the ECS interlock attributes the ECS Testharness script InterlockPosterLoadAndStart.th can be used to start the ECS InterlockPost test component. The script and the source code of the component (Java class InterlockPoster.java) are located in the $ATST/src/java/atst/ecs/test directory. To use the script issue the following command at the Testharness command line: atst> run src/java/atst/ecs/test/InterlockPosterLoadAndStart.th


The script starts the component test.ctrl.interlockpost and also contains the definitions of a number of attribute tables that may be used to instruct the component to post any of the ECS interlock attributes in event atst.gis.interlock. By default on startup the component posts no ECS interlock attributes.

Prior to posting an interlock event place the ECS into mode active using the ACTIVE button in the ECS

Mode JES custom widget. Once In Position goes true instruct the InterlockPost component to raise the

ECS interlock by using the following command at the Testharness command line: atst> set test.ctrl.interlockpost ecsInterlockTrue

On the ECS Main screen the Enc. Interlock will become true as will all specific Enc. Interlock displays, as

the overall ECS interlock has been raised. The Mode will become off and In Position false, also sub-

controller's health will go from GOOD to BAD (not EMCS controller atst.tcs.ecs.emcs as this has no associated interlocks). To lower the interlock issue the following command at the Testharness command line: atst> set test.ctrl.interlockpost ecsInterlockFalse

On the ECS Main screen the Enc. Interlock will go false as will all specific Enc. Interlock displays. The

Mode will remain off and In Position false, but sub-controller's health will return to GOOD.

The InterlockPost test component can be stopped and unloaded using the following Testharness script: atst> run src/java/atst/ecs/test/InterlockPosterStop.th

STOP OBSERVING 9.8

On the ECS Main screen select the Aperture Cover tab and demand the ECS to close the aperture cover

by pushing the Close button in the Aperture Cover Demand JES custom widget (see section 8.3.6). Once

the cover is in the closed position this will be shown in the Aperture Cover display item at top of screen

signaling observing has been stopped.

STOW TRACKING MECHANISMS 9.9

To stow all tracking mechanisms use the ECS Move JES custom widget in the ECS Main screen; select

checkboxes Altitude Shutter and Azimuth Carousel and from the drop-down named position list select

stow. Pushing the Submit button will submit configuration to the ECS containing

.[alt,az].namedPos=stow. This will demand the ECS tracking mechanisms to move to their stow

position. The completion of this shall be visible by In Position going true.


STOP TRACKING MECHANISMS 9.10

To stop all tracking mechanisms push the OFF button in ECS Mode JES custom widget on the ECS

Main screen. This will submit to the ECS a configuration stopping all movement, this shall be reflected in the status shown on the ECS Main screen.

SHUTDOWN 9.11

To shutdown the ECS and all its sub-controllers right-click the ECS Management Controller JES lifecycle

widget (top-left of ECS Main screen) and select Shutdown from the pull-down menu. This will change

all ECS controllers from the running to the initialized state, which will be shown on the ECS Main

screen Lifecycle and Health tab.

ENGINEERING: MOVE TO FIXED POSITION 9.12

To move either or both the altitude shutter and azimuth carousel use the ECS Move JES custom widget

in the ECS Main screen. Select checkbox Altitude Shutter and/or Azimuth Carousel depending upon

mechanisms to be moved. If a fixed degree position is required enter this in the Position: text entry box.

If a named position is required select it from the drop-down list. Pushing the Submit button will submit

configuration to the ECS to begin movement.

The completion of the move shall be visible by In Position going true and Report: displaying done.

ENGINEERING: OFFSETTING POSITION 9.13

On the ECS Main screen select either the Altitude Shutter (see section 8.3.4) or Azimuth Carousel (see

section 8.3.5) tab depending upon mechanism to be offset.

On the Altitude Shutter/Azimuth Carousel Mode JES custom widget push button ACTIVE and wait for

Report: to display done.

On the Altitude Shutter/Azimuth Carousel Move JES custom widget select the radio button Offset. In the

Offset deg: text entry box enter the position offset required. Press the Submit button to submit

configuration to the ECS to begin movement.

The updated demands sent to the EMCS PLC following the submit will be visible in the To EMCS table

of the selected tab. The completion of the move shall be visible by In Position going true and Report:

displaying done.


ENGINEERING: CONSTANT VELOCITY MOVE 9.14

On the ECS Main screen select either the Altitude Shutter (see section 8.3.4) or Azimuth Carousel (see

section 8.3.5) tab depending upon mechanism to be moved.

On the Altitude Shutter/Azimuth Carousel Mode JES custom widget push button ACTIVE and wait for

Report: to display done.

On the Altitude Shutter/Azimuth Carousel Move JES custom widget select the radio button Jog Velocity.

In the Jog deg/s: text entry box enter the constant move velocity required. Press the Submit button to

submit configuration to the ECS to begin movement.


of the selected tab. The configuration will complete with Report: displaying done once the mechanism is

moving at velocity demanded within velocity tolerance (specified in controller's property .velTol).

To stop the constant velocity move enter another position using the Move JES custom widget or press

the OFF button in the Mode custom widget.

ENGINEERING: MOVE TO EMCS LIMIT 9.15

If a move beyond the normal operational range of the ECS is to be carried out, i.e. past the enclosure's EMCS soft limit using the ECS named position limitLoLo or limitHiHi, the EMCS limit test mode must be enabled using the EMCS HMI before demanding the move using the ECS. Once the EMCS limit

test mode is enabled the ECS Main screen Limits Override will display true.

To move either or both the altitude shutter and azimuth carousel use the ECS Move JES custom widget

in the ECS Main screen. Select checkbox Altitude Shutter and/or Azimuth Carousel depending upon

mechanisms to be moved. From the named position drop-down list select the name of the limit to be

moved to. Pushing the Submit button will submit configuration to the ECS to begin movement to the

limit.


of the selected tab. The completion of the move shall be visible by In Position going true and Report:

displaying done.

ENGINEERING: CALIBRATE ENCLOSURE TRACKING 9.16MECHANISMS

At time of ECS Final release the TCS does not implement a pointing model for the ECS and therefore it is not possible to fully describe all actions necessary to carry out this user scenario. However, the


enclosure calibration camera can be enabled by the ECS and position errors read back, see section 8.3.7 ECS Main screen Auxiliary Equipment tab.


1 0 TROU B LE - S H OOTI NG & D E BU G G I NG

This section contains information to assist with diagnosing problems that might occur when running the ECS.

ECS CONTROLLER DEBUG LOG CATEGORIES 10.1

The ECS makes extensive use of the CSF log service with each ECS controller using a number of specific log debug categories. This enables the engineer to turn on and off debug messages relating to specific areas of the controller's operation. The log debug categories in use by ECS controllers can be split into two areas:

1. Controller level debug categories. 2. Connection level debug categories.

10.1.1 Controller Level Log Debug Categories

The ECS controller level debug categories provide debug from processing within the ECS Java controller classes contained in the ecs Java package, see section 5.2.5.1 Contents of ECS $ATST/src/java/atst/ecs , specifically Table 3 for details of classes this package contains. At this level all ECS controllers use the CSF log debug category LIFECYCLE to display debug messages during changes to controller's lifecycle. Setting this debug category to level 2 causes all ECS controllers to produce debug message at beginning and end of methods called due to a change in lifecycle, e.g. doInit(), doStartup(), etc. All ECS controllers also use a general log debug category as detailed in Table 1. For example, setting this debug category of a controller to level 2 will produce messages describing configuration processing carried out by doSubmit(), doCanRun() and doAction() methods.

Debug Category Description Controller

ECS The general log debug category of the ECS management controller.

atst.tcs.ecs

TRACKING_MECH The general log debug category of the ECS tracking mechanism controllers.


AUX The general log debug category of the ECS auxiliary equipment controller.

atst.tcs.ecs.aux

COVER The general log debug category of the ECS aperture cover controller.

atst.tcs.ecs.cover

EMCS The general log debug category of the ECS EMCS controller.

atst.tcs.ecs.emcs

Table 23 ECS controller level general log debug categories.

In addition to the general log debug category each controller uses other debug categories to produce log messages regarding specific areas of processing, e.g. the production of the attribute table posted in controller's cStatus event. The log debug category used for this specific processing are created by


suffixing the general log debug category by the processing the debug relates to, therefore the debug category ECS_CSTATUS is used by the ECS management controller atst.tcs.ecs to produce debug messages detailing creation of the atst.tcs.ecs.cStatus attribute table. The general format of the specific log debug categories is <general log category><specific log category>. The specific log categories used by ECS controllers are detailed in Table 24.

Debug Category Suffix

Description Controller

_CSTATUS Log debug category producing messages relating to creation of the controller's attribute table posted in its cStatus event.

All

_CPOS Log debug category producing messages relating to creation of the controller's attribute table posted in its cPos event.

atst.tcs.ecs atst.tcs.ecs.alt atst.tcs.ecs.az

_HEALTH Log debug category producing messages relating to testing and setting of controller's health.

All

_INPOS Log debug category producing messages relating to the setting of ECS management controller's in position status.

atst.tcs.ecs

_INTERLOCK Log debug category producing messages relating to processing resulting in the raising or lowering of controller's interlock.

atst.tcs.ecs atst.tcs.ecs.alt atst.tcs.ecs.az atst.tcs.ecs.cover atst.tcs.ecs.aux

Table 24 ECS controller level specfic log debug category suffixes.

The remaining log debug categories used at the ECS controller level are used to produce messages relating to processing carried out by each ECS hardware controllers' PLC tag helper. Each hardware controller uses a PLC tag helper object created from the ecs package Java class PlcTagHelper.java. This provides common functionality used by all hardware controllers, e.g. to obtain cStatus attribute values from PLC tag data, etc. Table 25 details all PLC tag helper log debug categories used by ECS controllers.


PLCTAG_HELPER The general log debug category of the ECS hardware controller's PLC tag helper.


PLCTAG_HELPER _HEALTH

Log debug category of the PLC tag helper relating to setting of controller health.


PLCTAG_HELPER _CSTATUS

Log debug category of the PLC tag helper relating to creation of controller's cStatus attribute table using PLC tag data item values.




PLCTAG_HELPER _CPOS

Log debug category of the PLC tag helper relating to creation of controller's cPos attribute table using PLC tag data item values.


Table 25 ECS controller level PLC tag helper log debug categories.

10.1.2 Connection Level Log Debug Categories

The ECS connection level debug categories provide debug from processing of the ECS Java connection classes contained in the abplc Java package, see section 5.2.5.1 Contents of ECS $ATST/src/java/atst/ecs , specifically Table 4 for details of classes this package contains. All ECS hardware controller specific connection classes are derived from the ABPlcioConnection class that provides the common connection behavior required by all controllers. Table 26 details all ABPlcioConnection log debug categories used by all ECS hardware controllers

Debug Category Description

ABPLCIO_CONNECTION The general log debug category of the ABPlcioConnection class. May be used to follow configuration processing to the connection from controller's doAction().

ABPLCIO_CONNECTION _PLC_READ

Produces log messages while processing read of EMCS PLC tag following controller receiving configuration containing read request. I.e. during normal TCS operation this will produce no output but will produce output during testing, for example by use of ECS Engineering DATA screens (see section 8.4.5) by

the pushing of Read Tag button as displayed in Figure 14.

ABPLCIO_CONNECTION _PLC_WRITE

Produces log messages while processing write of EMCS PLC tag following controller receiving configuration containing write request. I.e. during normal TCS operation this will produce no output but will produce output during testing, for example by use of ECS Engineering DATA screens (see section 8.4.5) by

the pushing of Write Tag button as displayed in Figure 15.

ABPLCIO_CONNECTION _PLCIO

When set to level 1 or above signals the connection to turn on the PLCIO library's debug. This can only be done when the connection is first opened during controller startup, therefore this debug category must be set prior to controller startup to have any effect. When switched on the PLCIO debug messages will appear in file /var/tmp/plcio.log on the ECS host PC.

Table 26 ECS connection level ABPlcioConnection log debug categories.

In addition to the common connection log debug categories each hardware controller's specific connection class has its own category, these are detailed in Table 27.


ABPLCIO_CONNECTION _ALT

Log debug category of the altitude shutter controller's connection.

atst.tcs.ecs.alt



– The azimuth carousel controller's specific connection has no additional debug categories - it uses only ABPlcioConnection's and ABPlcioConnectionTracking's (see below).

atst.tcs.ecs.az

ABPLCIO_CONNECTION _COVER

Log debug category of the aperture cover controller's connection.

atst.tcs.ecs.cover

ABPLCIO_CONNECTION _AUX

Log debug category of the auxiliary equipment controller's connection.

atst.tcs.ecs.aux

ABPLCIO_CONNECTION _EMCS

Log debug category of the EMCS controller's connection.

atst.tcs.ecs.emcs

Table 27 ECS connection level controller specific connection log debug categories.

The tracking mechanism controllers' specific connection class is not derived directly from ABPlcioConnection, as are the other hardware controllers, but from ABPlcioConnectionTracking. This class provides the common tracking connection behaviour required by both tracking mechanism controllers atst.tcs.ecs.alt and atst.tcs.ecs.az. To enable specific debug messages relating to tracking these two controllers use the debug categories detailed in Table 28.


ABPLCIO_CONNECTION _TRACKING

The general log debug category of the ABPlcioConnectionTracking class. May be used to follow configuration processing to the connection from controller's doAction().

ABPLCIO_CONNECTION _ TRACKING_POS_DEMAND

Produces log messages giving details of position demand sent to the EMCS by writing controller's W_Pos tag.

ABPLCIO_CONNECTION _ TRACKING_INPOS

Produces log messages giving details relating to the setting of controllers in position status.

ABPLCIO_CONNECTION _ TRACKING _EVENT_TIMING_TEST

Produces log messages to enable testing of time taken from arrival of TCS trajectory to writing of position demand to EMCS PLC when tracking.

Table 28 ECS connection level ABPlcioConnectionTracking log debug categories.

The remaining connection level debug categories relating to specific operations carried out by the hardware controller's connection are detailed in Table 29.


ABPLCIO_CHANNEL Log debug relating to communication across connection's channels.

atst.tcs.ecs.alt atst.tcs.ecs.az atst.tcs.ecs.cover atst.tcs.ecs.aux atst.tcs.ecs.az.emcs

PLC_TAG Log debug relating to the EMCS PLC tags used by the connection.




PLC_TAG_ITEM Log debug relating to the individual data items contained in a PLC tag. Only used during controller startup, therefore this debug category must be set prior to controller startup to have any effect.


PCFORMAT Log debug relating to the PLCIO pcformt string used to describe contents of PLC tag. Only used during controller startup, therefore this debug category must be set prior to controller startup to have any effect.


PLCTAG_READER _CSTATUS

Log debug relating to the periodic reading of the PLC CStatus tag containing current hardware status.


PLCTAG_READER _CPOS

Log debug relating to the periodic reading of the PLC CPos tag containing current hardware position.


Table 29 ECS connection level specific log debug categories.

ECS CONTAINER LOG DEBUG CATEGORIES 10.2

The ECS uses JNI (Java Native Interface) software to call the functions of the PLCIO C library used to communicate with the EMCS PLC. This operates in the container namespace not the controller namespace (see the ECS Software Design Description [AD 6] for details). Log debug messages from processing in the container namespace use the categories detailed in Table 30.


ABPLCIO_MASTER The general log debug category of the ABPlcioMaster class that calls the JNI code used to call the PLCIO C library functions..

ABPLCIO_MASTER _PLC_READ

Produces log messages giving details of processing relating to the reading of PLC tags using PLCIO function plc_read().

ABPLCIO_MASTER _PLC_WRITE

Produces log messages giving details of processing relating to the reading of PLC tags using PLCIO function plc_write().

ABPLCIO_MASTER _JNI

Produces log messages from within the JNI C code that calls the PLCIO library functions.

Table 30 ECS container log debug categories.

To use the ECS container log debug categories the debug of the ECS1 container must be set, as opposed to the debug of an ECS controller. For example to set the ABPLCIO_MASTER_JNI log debug category to level 4 the following command is used at the Testharness command line: atst> debug ECS1 4 ABPLCIO_MASTER_JNI


TROUBLE-SHOOTING 10.3

10.3.1 Configuration Processing

To diagnose unexpected configuration processing following submit of configuration to the ECS the following may be done:

1. Set the ECS management controller's ECS log debug category to level 2 and the general log debug category of the ECS sub-controller expected to process the configuration to level 2, see Table 23 for log debug categories available. E.g. if the auxiliary controller is the sub-controller which will be acting upon the configuration set atst.tcs.ecs.aux debug category AUX to level 2. Controller debug categories can be set using the ECS Engineering SYSTEM screen as described in section 8.4.6.3 ECS Engineering SYSTEM screen's Controller Debug slider.

2. Submit the configuration to the ECS management controller atst.tcs.ecs and view debug messages produced using the CSF LogView utility.

3. If debug messages do not provide answer to unexpected configuration processing to view processing occurring in the connection, due to configuration actions, the log debug category of the controller's connection can be set to level 2, see Table 27 for log debug categories available. E.g. if the auxiliary controller is the sub-controller which will be acting upon the configuration set atst.tcs.ecs.aux debug category ABPLCIO_CONNECTION_AUX to level 2.


5. If debug messages do not provide answer to unexpected configuration processing the values contained in the PLC tag that will be written using the connection channel, can be viewed by setting the controller's log debug category PLC_TAG to level 4.

6. Submit the configuration to the ECS management controller atst.tcs.ecs and view debug messages produced using the CSF LogView utility. The PLC_TAG debug category messages will include not only those generated by the configuration submitted but also from any other tags being read or written at the time (e.g. the controller's R_CStatus tag).

7. If debug messages do not provide answer to unexpected configuration processing view connection channel write information by setting the controller's debug log category ABPLCIO_CHANNEL to level 4.


9. If debug messages do not provide answer to unexpected configuration processing have a cup of coffee and think about a career in flower arranging.


1 1 V I RTUAL E M C S S I M U LATO R

The Virtual EMCS (VEMCS) simulator provided with the ECS application may be used when access to enclosure hardware is not available. Use of the simulator provides the ability to operate the ECS independently of any hardware. To simulate the EMCS the VEMCS implements the same interface as the EMCS defined in the Enclosure to ECS ICD 5.0/5.6 [AD 4]. The VEMCS has two parts:

1. A replacement for the PLCIO communications module used to open/close connections and read/write PLC tags to/from the EMCS PLC. When using the real EMCS the PLCIO communications module used is cip. When using the VEMCS this is replaced by the vemcs PLCIO communications module developed specifically for the ECS. Using this makes no change to the PLCIO API used by the ECS as no direct access to a PLCIO communications module is made from outside PLCIO. The module provides functions called internally by PLCIO when required to communicate with the PLC. When using the cip module this results in CIP messages being sent to the PLC over EtherNetIP. When using the vemcs module this results in binary data files on the local PC being read/written and accessed by the VirtualEmcs CSF controller atst.tcs.ecs.vemcs to provide EMCS simulation. The vemcs module is used when the .connection:isSimulated property of a controller is set to true (see tables containing controller properties in section 6.2). The module is implemented in C and contained in the ECS package atst.ecs.plciovemcs, see section 5.2.5.2, Table 6.

2. The Java CSF management controller atst.tcs.ecs.vemcs and its sub-controllers. The management controller is implemented in the class VirtualEmcs.java contained in the ECS package atst.ecs.vemcs, see section 5.2.5.1, Table 5. This controller manages the other VEMCS controllers that implement simulation of specific parts of the enclosure and accepts configurations to change values of PLC read tags read by the ECS. It obtains the demands from the ECS by reading the binary data files, containing EMCS PLC write tags, updated by the vemcs PLCIO module when a tag is written by the ECS. The atst.tcs.ecs.vemcs management controller is notified of changes to the EMCS PLC write tag binary data files through its use of the Java 7 Watch Service API. The management controller then creates a configuration containing the name of the write tag and submits this to its sub-controller responsible for simulating the hardware relating to the tag. During simulation the sub-controller updates the hardware status by updating the binary data files containing EMCS PLC read tags, that are subsequently read by the vemcs module when the ECS requests a read of the tag.

The binary data files used by the vemcs module and VEMCS controllers are stored in the directory $ATST/resources/ecs on the ECS PC host. The directory structure required is created by the VEMCS management controller at startup (if not already available). If not present the binary data files relating to a controller's PLC tags are created when the controller is started, otherwise files already present are used so that the simulator remembers hardware status, including mechanism positions, between uses.


VEMCS CONTROLLERS 11.1

The VEMCS Java controllers are:

atst.tcs.ecs.vemcs – this is the top-level management controller of the VEMCS. It manages the lifecycle of all other VEMCS controllers and accepts configurations to update PLC tags read by the ECS. The controller is instantiated from the Java class VirtualEmcs.java that extends the CSF ManagementController class.

atst.tcs.ecs.vemcs.alt – is the controller that simulates the actions of the enclosure altitude shutter mechanism. It is instantiated from the Java class VirtualEmcsControllerTrackingAlt.java that extends the VirtualEmcsControllerTracking class.

atst.tcs.ecs.vemcs.az – is the controller that simulates the actions of the enclosure azimuth carousel mechanism. It is instantiated from the Java class VirtualEmcsControllerTrackingAz.java that extends the VirtualEmcsControllerTracking class.

atst.tcs.ecs.vemcs.aux – is the controller that simulates the actions of the enclosure auxiliary equipment. It is instantiated from the Java class VirtualEmcsControllerAux.java.

atst.tcs.ecs.vemcs.cover – is the controller that simulates the actions of the enclosure aperture cover mechanism. It is instantiated from the Java class VirtualEmcsControllerCover.java.

atst.tcs.ecs.vemcs.emcs – is the controller that simulates the system responsibilities placed on the enclosure EMCS PLC, e.g. reporting whether EMCS is in local control, or has failed, etc. It is instantiated from the Java class VirtualEmcsControllerEmcs.java.

VEMCS CONFIGURATION 11.2

The VEMCS CSF controllers are loaded into the ECS container (ECS1), see section 6.1 for details of how this is configured to add the VEMCS controllers. The controllers are configured from entries in the property tables of the property DB (in the same manner as the ECS controllers, see section 6.2 of this document). The file ecs/vemcs/VEMCS.prop contains all properties used by the VEMCS. To modify the VEMCS simulation behavior a number of the controllers' properties may be modified. The properties are documented in the following tables; each table contains properties specific to a single VEMCS controller.

VEMCS Altitude Shutter Controller: atst.tcs.ecs.vemcs.alt (VEMCS.prop)

Property Name Type Access Description Saved values Limits Defaults .limit:horizonFinal real r-- Horizon limit final. 4.0

.limit:horizonEOT real r-- Horizon limit end-of-travel. 5.0

.limit:horizonSW real r-- Horizon limit software. 7.0

.limit:horizonSD real r-- Horizon limit slow-down. 10.0

.limit:zenithSD real r-- Zenith limit slow-down. 89.0

.limit:zenithSW real r-- Zenith limit software. 90.5

.limit:zenithEOT real r-- Zenith limit end-of-travel. 92.0

.limit:zenithFinal real r-- Zenith limit final. 93.0

.servo:enabled boolean rw- Enable/disable start of tracking servo in controller's doStartup().

true


VEMCS Altitude Shutter Controller: atst.tcs.ecs.vemcs.alt (VEMCS.prop)

Property Name Type Access Description Saved values Limits Defaults .sealMoveTime real rw- Time taken by simulator to

inflate/deflate seals in receipt of W_altCmds tag item cmd=[8|9] (seconds).

10.0 0.0, 40.0

.sealPressureDeflated real rw- The seal pressure reported by the VEMCS when the seals are in the deflated state (Pascal).

0.0

.sealPressureInflated real rw- The seal pressure reported by the VEMCS when the seals are in the inflated state (Pascal)

250.0

Table 31 VEMCS Altitude Shutter Controller atst.tcs.ecs.vemcs.alt Properties.

VEMCS Azimuth Carousel Controller: atst.tcs.ecs.vemcs.az (VEMCS.prop)

Property Name Type Access Description Saved values Limits Defaults .limit:ccwFinal real r-- Counter-clockwise limit

final. -90.0

.limit:ccwEOT real r-- Counter-clockwise limit end-of-travel.

-87.0

.limit:ccwSW real r-- Counter-clockwise limit software.

-85.0

.limit:ccwSD real r-- Counter-clockwise limit slow-down.

-83.5

.limit:cwSD real r-- Clockwise limit slow-down. 303.5

.limit:cwSW real r-- Clockwise limit software. 305.0

.limit:cwEOT real r-- Clockwise limit end-of-travel.

307.0

.limit:cwFinal real r-- Clockwise limit final. 310.0

.servo:enabled boolean rw- Enable/disable start of tracking servo in controller's doStartup().

true

Table 32 VEMCS Azimuth Carousel Controller atst.tcs.ecs.vemcs.az Properties.

VEMCS Aperture Cover Controller: atst.tcs.ecs.vemcs.cover (VEMCS.prop)

Property Name Type Access Description Saved values Limits Defaults .coverMoveTime real rw- Time taken by simulator to

close/open aperture cover in receipt of W_coverCmds tag item cmd=[0|1|2|3] (seconds)

8.0

.sealMoveTime real rw- Time taken by simulator to inflate/deflate aperture cover seal in receipt of W_coverCmds tag item cmd=[0|1|4|5] (seconds)

3.0 0.0, 40.0


VEMCS Aperture Cover Controller: atst.tcs.ecs.vemcs.cover (VEMCS.prop)

Property Name Type Access Description Saved values Limits Defaults .sealPressureDeflated real rw- The seal pressure reported

by the VEMCS when the seal is in the deflated state (Pascal).

0.0

.sealPressureInflated real rw- The seal pressure reported by the VEMCS when the seals is in the inflated state (Pascal)

250.0

Table 33 VEMCS Aperture Cover Controller atst.tcs.ecs.vemcs.cover Properties.

The VEMCS management controller atst.tcs.ecs.vemcs, VEMCS auxiliary equipment controller atst.tcs.ecs.vemcs.aux and VEMCS EMCS controller atst.tcs.ecs.vemcs.emcs have no properties that require configuring or that modify VEMCS simulation behavior.

VEMCS STARTUP AND RUNNING 11.3

To start the VEMCS and its JES screen use the ECS startup script ecsStart documented in section 7.1 of this manual.

Use the VEMCS JES screen (see Figure 19) to initialize the VEMCS by right-clicking on the VEMCS

Management Controller JES lifecycle widget (top-left of screen) and selecting Initialize from the pull-

down menu. This will change all VEMCS controllers from the uninitialized to initialized state. To start

the VEMCS right-click on the same lifecycle widget and select Start. This will change all VEMCS

controllers from the initialized to the running state. To shutdown and uninitialize the VEMCS use the same lifecycle control widget and select the required command from the pull-down menu. For full instructions on shutting down all software started by the ecsStart script see section 7.2 of this manual.

VEMCS JES SCREEN 11.4

The VEMCS JES screen is shown in Figure 19 as it appears following completion of the ECS startup script when using the --jesVEMS option (see section 7.1). The purpose of the VEMCS screen is:

To show values of the EMCS PLC tags being written by the ECS to the EMCS.

To enable the interactive update of the EMCS PLC tags being read by the ECS from the EMCS.

Therefore all EMCS PLC write tag data items and read tag data items, as defined in the Enclosure to ECS ICD (see [AD 4]) are accessible from the screen.


Figure 19 VEMCS JES Screen

The VEMCS JES screen consists of three sections:

1. Top-left – contains the VEMCS Management Controller JES lifecycle and health widgets. Also in

this section is displayed the number of Open PLCIO connections to the VEMCS, i.e. the number

of connections that have been opened by the ECS calling the PLCIO plc_open() function. When the ECS is not running this number will be zero.

2. Top-right – contains a JES configuration widget that can be used to modify any value of any ECS read tag contained in the Enclosure to ECS ICD. The configuration widget contains the attributes:

updateTag – this attribute will accept the name of any ECS read tag. The names of

the ECS read tags are shown on the hardware controller tabs, e.g. the Alt tab shows the

ECS read tag names R_altCPos and R_altCStatus, these are both valid values for the

updateTag attribute.

updateTagItem – this attribute accepts the name of any ECS read tag data item of

the tag named in attribute updateTag. All read tag data item names are shown on the

hardware controller tabs, e.g. the R_altCPos tag contains the data items ID, cMode,


cPos, cPosErr, cVel and CVelErr. Any of these are valid item names if the updateTag

attribute value is R_altCPos.

updateTagItemValue – this attribute accepts the new value the tag data item named

in attribute updateTagItem is required to be set to.

E.g. to set the altitude shutter’s altCPos tag item cMode to EMCS mode Point-to-Point the following configuration would be submitted:

updateTag = R_altCPos

updateTagItem = cMode

updateTagItemValue = 2

These attributes belong to the VEMCS management controller and so the configuration widget submits the configuration to atst.tcs.ecs.vemcs. The management controller propagates the

configuration to the appropriate sub-controller based upon the tag named in the updateTag

attribute 3. Lower-half – contains a tab control with one tab for each VEMCS sub-controller responsible

for simulation of one part of the enclosure hardware. Each tab contains JES lifecycle and health widgets for the controller and widgets allowing the user to modify any value of an EMCS tag read by the ECS (containing hardware status). Also displayed are the current values of the ECS write tags containing the values written by the ECS. Each write tag has an

associated Last write time displaying the last time this tag was written by the ECS. On VEMCS

startup this will display the value Not written by the ECS, showing the user that the data item

values displayed for this write tag are those written by the ECS when the VEMCS was last running, i.e. they are the values read from the tag’s binary data files stored on the PC running the software when the VEMCS was started.

The Alt and Az tabs contain Servo Enabled Status displaying the current status of the sub-

controller's simulator servo as configured by the sub-controller's .servo:enabled property. When enabled the servo simulates axis movement by responding to position demands received in the W_[alt|az]Pos tag and updating the hardware position in the R_[alt|az]CPos tag and brake and power status in the R_[alt|az]CStatus tag.


1 2 U NI T TE S TI NG

The ECS is supplied with a set of testing scripts and an engineering screen that can be used to execute the tests. The tests are written in the python scripting language and utilize the scripting facilities provided as part of the CSF infrastructure. This provides access to all CSF services and can be used to interact with CSF applications. A complete description of the CSF scripting facilities can be found in the CSF User’s Manual [AD 9]. For details of the testing infrastructure implementation see the ECS Software Design Description [AD 6]. The test scripts submit configurations to the ECS application and capture the results through the use of the CSF connection and event services. The results of the test scripts are logged using the CSF logging service and can be reviewed using standard CSF logging facilities. The scripts are stored in the test/ directory of the ECS application. For details of actual tests available see ECS Factory and Site Acceptance Test Plan [AD 7], Unit Test section.

UNIT TEST ENGINEERING SCREEN 12.1

Figure 19 shows the ECS Test Utility engineering screen with a selection of ECS unit tests loaded. The screen is started using the command: JES --file=ecs/ECS_TestUtility.xml

A test script is loaded by pushing the Add button (top-left of screen) and selecting the desired script

using the displayed file dialogue. Once loaded the selected test will appear in the Test Library list box.

To run a test select it from the Test Library list box and press the Run button. As the test is executed

messages are logged as are the results of individual test steps. The log messages are displayed in the results table in the lower-half of the screen. Some tests require operator input; if this is the case a dialog box will open requesting the operator to enter the necessary information. The test will halt execution until the operator has entered the information requested and clicked on the requested button. The test scripts are located in the directory $ATST/src/java/atst/ecs/test. Knowledge of the python scripting language is required to update the test scripts.


Figure 20 The ECS Test engineering screen.


AP P E ND I X A . E C S S OF TWAR E C V S C H E C KOU T AND BU I LD S C R I P T

This appendix contains a bash script that may be used to CVS checkout and build all software of the ECS, including the software contained in the CVS idom and ecs modules. The script is written to checkout the contents of the two modules into an already present ASDT containing the ATST cs and base modules. It uses the same commands as detailed in sections 4.3, 4.4 and 4.5 of the Quick Start Guide contained in section 4, and 5.2.3, 5.2.4 and 5.2.6 of the Installation from CVS instructions contained in section 5.2. Prior to use replace <enter CVS use name here> with your CVS user name. The top-level directory containing the ASDT must be named atst, if this is not the case the cvs co command arguments must be edited to correctly reference the location of the ASDT. #!/bin/bash

# Script to do clean-checkout and build of Idom and

# ECS Final release CVS modules.

#

# Created by Alastair Borrowman from an original by Alan Greer (OSL).

#

# Takes one optional argument: Username

# Defaults to aborrowman

#

# All checkout commands use the -P prune option

#

# Actions:

# 1. Checks out idom module into the CSF tree.

# 2. Builds the idom module.

# 3. Checks out ecs module into the CSF tree.

# 4. Builds the ecs module.

# 5. Create directories used by ECS in /var/tmp

# Get command line arguments

args=("$@")

if [ -z ${args[0]} ]; then

USERNAME=<enter CVS use name here>

else

USERNAME=${args[0]}

fi

# set ECS release to Final

ECS_RELEASE=ECS_final_v1_3_0

# cd to parent directory of $ATST - must work even if $ATST does not exist

ATST_P_DIR="$(dirname $ATST)"

cd $ATST_P_DIR

echo Checking out $ECS_RELEASE release into $PWD

# checkout Idom:

cd $ATST_P_DIR

export CVSROOT=:pserver:[email protected]:/home/atst/src/idom

cvs co -P -r $ECS_RELEASE atst


# Install Idom module - must be done in $ATST to ensure

# idom install directory is created

cd $ATST

make gcc_all

# checkout ECS

cd $ATST_P_DIR

export CVSROOT=:pserver:[email protected]:/home/atst/src/ecs

cvs co -P -r $ECS_RELEASE atst

# build VEMCS PLCIO library

cd $ATST/src/c++/atst/ecs/plciovemcs

make gcc_all

# build ECS

cd $ATST

make classes

make jni

make docs

cd $ATST/src/java/atst/ecs/scripts

make install_scripts

atst ecs operations & maintenance manual · enclosure design services for the advanced...

Documents