go+: the gbt observer’s interface project charter (int0205-001) thursday, may 23, 2002 ray creager...

GO+: The GBT Observer’s InterfaceProject Charter (INT0205-001)

Thursday, May 23, 2002Ray Creager ([email protected])Melinda Mello ([email protected])

Nicole Radziwill ([email protected])Mark Clark ([email protected])

mailto:[email protected]



2

Project Overview

System Baseline

Solution Components Vision

Software Modules

Architecture

Delivery Approach Phase 0

Phase 1

Schedule

Project Summary

This Charter focuses onwhat will be delivered in

Phase 0, given anoverall strategic andarchitectural vision

3

Project OverviewProblem Statement & Vision Summary

GO+ will enable observers to utilize their time on the GBT in the most effective ways, and help them navigate through the myriad of applications that span telescope setup through data reduction and visualization.

Why is this necessary? As more Observers visit Green Bank to conduct experiments, NRAO

Commissioners and Astronomers should not have to spend the bulk of their time providing guidance through the systems. At present, this is a critical issue.

NRAO GB aims to have “fully functioning telescope” by early fall. In order to accomplish this, a robust astronomer’s interface must be in place.

Strategic Goals: Make the procedures for using the GBT as clear as possible, to both

novice and expert users. Build a structure to accommodate the long-term NRAO vision, which

includes remote observing and flexible scheduling.

GO+ will enable observers to utilize their time on the GBT in the most effective ways, and help them navigate through the myriad of applications that span telescope setup through data reduction and visualization.

Why is this necessary? As more Observers visit Green Bank to conduct experiments, NRAO

Commissioners and Astronomers should not have to spend the bulk of their time providing guidance through the systems. At present, this is a critical issue.

NRAO GB aims to have “fully functioning telescope” by early fall. In order to accomplish this, a robust astronomer’s interface must be in place.

Strategic Goals: Make the procedures for using the GBT as clear as possible, to both

novice and expert users. Build a structure to accommodate the long-term NRAO vision, which

includes remote observing and flexible scheduling.

4

Project OverviewTarget Audience

Astronomers who visit the GBT as Observers fall into one of the following categories:

1. Standard Users (80%)Novice users know the source they wish to observe, the observing procedure, and the

fundamentals about front end and back end equipment to be used. They do not care about the details of tweaking power or configuring the IF system. They just want to see data from their scans as rapidly as possible.

2. Intermediate Users (10%)Intermediate users know the source they wish to observe, the observing procedure, and the

fundamentals about front end and back end equipment to be used. They may care about isolated details of tweaking power or configuring the IF system.

3. Expert Users (10%)Expert users know all about the M&C system and desire a level of control nearly equivalent to

that of the engineer. They may want to tweak

The new Observer’s Interface will cater to Standard Users only in its initial releases. Intermediate and Expert Users are expected to use Glish or CLEO for their additional configuration needs.

Astronomers who visit the GBT as Observers fall into one of the following categories:

1. Standard Users (80%)Novice users know the source they wish to observe, the observing procedure, and the

fundamentals about front end and back end equipment to be used. They do not care about the details of tweaking power or configuring the IF system. They just want to see data from their scans as rapidly as possible.

2. Intermediate Users (10%)Intermediate users know the source they wish to observe, the observing procedure, and the

fundamentals about front end and back end equipment to be used. They may care about isolated details of tweaking power or configuring the IF system.

3. Expert Users (10%)Expert users know all about the M&C system and desire a level of control nearly equivalent to

that of the engineer. They may want to tweak

The new Observer’s Interface will cater to Standard Users only in its initial releases. Intermediate and Expert Users are expected to use Glish or CLEO for their additional configuration needs.

5

Project OverviewDesign Goals

Improve Security

Enable Scalability

Achieve Component Independence • Devise and implement a Service-Oriented Architecture (SOA) for more effective future

development

Reduce Systems Overhead• Interact only with devices that are central to an observation

Prevent Network Bottlenecks by Design• Utilize thin transports and industry standard technologies

Accommodate Remote Observing and Flexible Scheduling• Build a framework that does not prohibit these future needs

Support Organizational Alignment• Choose tools and techniques that support e2e/Data Management goals

Improve Security

Enable Scalability

Achieve Component Independence • Devise and implement a Service-Oriented Architecture (SOA) for more effective future

development

Reduce Systems Overhead• Interact only with devices that are central to an observation

Prevent Network Bottlenecks by Design• Utilize thin transports and industry standard technologies

Accommodate Remote Observing and Flexible Scheduling• Build a framework that does not prohibit these future needs

Support Organizational Alignment• Choose tools and techniques that support e2e/Data Management goals

6

Project Overview: Delivery ApproachHow do we achieve the Vision?

Conduct a Proof-of-Concept Exercise

Phase 0: Architectural Demonstration (June - July 2002) Prototype the New Architectural Framework Provide New GUI Proof-of-Concept on One Observation

Construct a Production System

Phase 1: Rapid Configurability (July - Aug 2002) Add Capabilities to Handle Continuum & Spectral Line Observing Enable Automated M&C Configuration for Standard Observing

Phase 2+: Comprehensive Capabilities (Sept – Dec 2002) Support for all Security Modes Support for VLBI Add Capabilities to Handle Pulsar Observing Add Source & Configuration Catalogs

Achieve Long-Term Strategic Goals

Phase N: Expanding the Infrastructure (2003+) Remote Observing and Flexible Scheduling

Conduct a Proof-of-Concept Exercise

Phase 0: Architectural Demonstration (June - July 2002) Prototype the New Architectural Framework Provide New GUI Proof-of-Concept on One Observation

Construct a Production System

Phase 1: Rapid Configurability (July - Aug 2002) Add Capabilities to Handle Continuum & Spectral Line Observing Enable Automated M&C Configuration for Standard Observing

Phase 2+: Comprehensive Capabilities (Sept – Dec 2002) Support for all Security Modes Support for VLBI Add Capabilities to Handle Pulsar Observing Add Source & Configuration Catalogs

Achieve Long-Term Strategic Goals

Phase N: Expanding the Infrastructure (2003+) Remote Observing and Flexible Scheduling

7

Project Overview: The ProductKey Features of the Observer’s Interface

Phase 1 Results in Release 1 (Q3 2002)

Automated Configuration for: 2 Primary Observing Modes (Continuum/Spectral Line), 8 Key Observing Procedures and 4 Switching Mechanisms

Automated Initialization and Balancing of M&C System

Fully Functioning Spectrometer

Fully Functioning LO1

Data Integrity

Architectural Improvements for Faster System Startup

Architectural Basis for Flexible Scheduling through Database-Centric Object Model

Architectural Basis for Remote Observing across a TCP/IP Network

Architectural Improvements Enabling Multiple Programmers to Work Simultaneously

A Faster, More Reliable Application

Support for Standard Observing

Enabling Future Development

Phase 2 Results in Release 2 (Q4 2002)

Automated Configuration for Pulsar Observing Modes and Observing Procedures

A Searchable Configuration Catalog of Customized Scripts used by NRAO Astronomers and Commissioners

Fully Functioning Pulsar Capabilities

Additional Features TBD

Help for Intermediate Observers

Phase 0 Results in Prototype for Demonstration Only

8

Project Overview: Software Development Life Cycle Overview

STAGE 1: ANALYSIS STAGE 2: DESIGN STAGE 3

STAGE 5

STAGE 4

Requirements Gathering

(Jan 92 – Jan 02)

Fisher & Lockman, 1992: “Observer Monitor and Control Requirements” – GBT Memo 81

Balser, Fisher, Minter & Prestage, 2001: “GBT Observe Initial System Requirements” – GBT Software Project Note 18.1

Strategy & Architecture

(Apr 02 – May 02)

Articulate Vision

Identify and Describe Use Cases

Baseline GO Architecture and Functionality

Identify Strategic Vision for Architecture

Devise Approach

Development

(Jul 02 – Aug 02)

Validation & Training

(Aug 02 – mid Sep 02)

Production Rollout

(mid Sep 02)

Prototype Development

(Jun-Jul 02)

Identify Demo Scenario

Prepare GUI Mockup

Provide Live Demo

Gap Analysis

(Jul-Aug 02)

Allow commissioners and astronomers to tweak look, feel and functionality of prototype interface

Use Gap Analysis to plan development of Phase 1 Functionality

Project Moves into Phase 1

Phase 0 BeginsUpon Completed

Architecture

Release 1Available

9

System Baseline: Current Application TopologyCritical Issues Regarding Existing Application

Observers currently use GO (GBT Observe) to conduct observations.

GO is a collection of one main Glish script and approximately 50 supporting Glish scripts. They cross-reference each other deeply, making it difficult for two or more programmers to work simultaneously.

Critical Impact: Getting new development done faster often involves adding more people to a project. If we can’t add more people because of system design problems, we’re stuck before we start!

Upon startup, GO talks to every device in the M&C system even if the astronomer’s observation doesn’t require it.

Critical Impact: It makes the interface go very slow, and the interface will crash if there’s a problem with any one device!

There’s a lot of duplicated code in the application. Critical Impact: The application runs more slowly and less reliably. There’s more room for

unexpected syntax errors while fixing old bugs OR adding new capabilities. Adding new functionality requires being a detective and fishing important pieces out of old code. Why be detectives when we can be architects?

Observers currently use GO (GBT Observe) to conduct observations.

GO is a collection of one main Glish script and approximately 50 supporting Glish scripts. They cross-reference each other deeply, making it difficult for two or more programmers to work simultaneously.

Critical Impact: Getting new development done faster often involves adding more people to a project. If we can’t add more people because of system design problems, we’re stuck before we start!

Upon startup, GO talks to every device in the M&C system even if the astronomer’s observation doesn’t require it.

Critical Impact: It makes the interface go very slow, and the interface will crash if there’s a problem with any one device!

There’s a lot of duplicated code in the application. Critical Impact: The application runs more slowly and less reliably. There’s more room for

unexpected syntax errors while fixing old bugs OR adding new capabilities. Adding new functionality requires being a detective and fishing important pieces out of old code. Why be detectives when we can be architects?

10

GO

Glish session

Glish bus

EphemeridesUser tablego_miscygfits_gygor_gIARDS client Glish/Tk

glishd

IARDS client

Go FITS file

M&C DeviceManager

Observation context

Glish bus

Glish session

IARDS

IARDS session

GBT Filler

Glish bus

Glish session

AIPS++

GBT FillerFITS Files

Meas. Set

Meas. Set

Data Processing

System Baseline: Current Application TopologyApplication Architecture for GO

11

System Baseline: Current Application TopologyThe Solution

Keep the solid, proven parts driving GO; improve upon possible bottlenecks!

What we’ll keep:GO Keywords and Help MessagesBasic Look and Feel of Panels and Panel HierarchyConcept of Observing TablesObserving Procedures in Glish

What we’ll upgrade: The GO GUI. We’ll preserve the concept, but construct the GUI in a Rapid Development

Environment for added efficiency and to enable development by a whole team at once.

What we’ll improve: Minimize the transactions between the Observer’s Interface and the M&C system. There are

too many right now – that’s what’s slowing things down! Eliminate unnecessary forked processes. This is under the covers, but it’s slowing things

down too.

What we’ll add: A database to localize use of GO keywords and help messages A layered architecture that will speed things up tremendously and enable future capabilities

like flexible scheduling and remote observing A configuration layer – the root of why everyone wants to improve GO in the first place!

Keep the solid, proven parts driving GO; improve upon possible bottlenecks!

What we’ll keep:GO Keywords and Help MessagesBasic Look and Feel of Panels and Panel HierarchyConcept of Observing TablesObserving Procedures in Glish

What we’ll upgrade: The GO GUI. We’ll preserve the concept, but construct the GUI in a Rapid Development

Environment for added efficiency and to enable development by a whole team at once.

What we’ll improve: Minimize the transactions between the Observer’s Interface and the M&C system. There are

too many right now – that’s what’s slowing things down! Eliminate unnecessary forked processes. This is under the covers, but it’s slowing things

down too.

What we’ll add: A database to localize use of GO keywords and help messages A layered architecture that will speed things up tremendously and enable future capabilities

like flexible scheduling and remote observing A configuration layer – the root of why everyone wants to improve GO in the first place!

12

Solution Components: VisionA Framework for Supporting the Overall NRAO Vision

The target solution will:

Implement an Object-Entity Model, which will Enable the abstraction of key Terms, Incorporate a Five Layer Architecture, and Effect multiple Security Modes to support all user types, and Support many Use Cases to facilitate functionality.

Phase 0 will only support a live demonstration of one simple observing scenario to the NRAO GB community.

– The product is not intended to serve as a production system– Components servicing Phase 0 will, however, be used as the skeleton for Phase 1

development

The target solution will:

Implement an Object-Entity Model, which will Enable the abstraction of key Terms, Incorporate a Five Layer Architecture, and Effect multiple Security Modes to support all user types, and Support many Use Cases to facilitate functionality.

Phase 0 will only support a live demonstration of one simple observing scenario to the NRAO GB community.

– The product is not intended to serve as a production system– Components servicing Phase 0 will, however, be used as the skeleton for Phase 1

development

13

Solution Components: Vision (2)Object-Entity Model

Object-Entity models are data abstractions that allow the developer to segment the architecture of the application. We will use 3 Entities in this product:

– Observation: This object encapsulates data entirely in the context of an astronomical observation. It is telescope independent.

– Configuration: (possibly a special case of Observation Entity). Similar to an observation entity, except with no actual observation component. Used to test observation configurations

– Scan: Derived from the Observation Entity, these are used by the Application Services level and the M&C system to configure and execute the individual scans that make up an observation.

14

Solution Components: Vision (3)The following terms have been used throughout this solution strategy

• Astronomer/Observer: The individual responsible for conducting an observation.• Expert Observing: Unique modes of observing which will make up 20% of the use of the telescope• Keyword: Variable unique to the observation program representing an astronomical concept for configuring

the telescope.• Observation: A set of scans which produces a data set that can be reduced, calibrated, and analyzed in

an astronomically meaningful way. There can be many observations per session. An observation is the result from completing an observing procedure.

• Observing Procedure: A function that specifies how to move the telescope and collect data. May control one or more scans. When an observing procedure is execute, an observation results.

• Parameter: Variable in the Ygor/M&C system representing a device-related quantity for configuring a device.

• Primary Parameters: For a given device configuration, the minimum subset of the device's parameter set which fully defines an observable configuration.

• Project: The complete scope of work to be done by a visiting observer under one proposal. More than one Astronomer/Observer may conduct work on a single project.

• Proposal: A research plan submitted by the Astronomer/Observer to NRAO requesting observation time on the GBT.

• Scan: A contiguous period of data collection defined by a finite set of pre-defined variables (parameters). There can be many scans per observation.

• Session: A block of time over which the observer interactively or non-interactively conducts one or more observations.

• Standard Observing: Typical modes of observing which will make up 80% of the use of the telescope

15

Solution Components: Vision (4)Five Layer Architecture

• The 5-layer architecture confers many advantages to the developer, including:– Minimizes Risk, by decoupling modules from other modules and the

technologies used to implement them– Promotes Code Reuse. Component modules are minimally coupled to the

rest of the system.– Distributes Network and CPU Load.– Speeds Development, by enabling use of existing components

• These attributes will help us develop a flexible solution that will scale well and readily adapt to new/changing requirements, all the while remaining relatively immune to technology changes

• The Model View Controller (MVC) paradigm used by this architecture breaks a logical application into three parts: the model, the view, and the controller. The model is used to manage information and notify observers when that information changes. It contains only data and functionality that are related by a common purpose (the observation). The view presents the model to the user. The Controller collects user input for the purpose of instructing the view and model objects to perform tasks that the user desires of them.

16

Solution Components: Vision (5)Security Modes

Three security modes will be available after Phase 1:

• Master: This user retains complete control of the telescope and can not be interrupted by anyone other than the telescope operator. There may be one or more Master users at a time (for example, PI and Co-PI) who see the same instance of the Observer’s Interface.

• Viewer: This user can see everything the Master is doing but cannot control the telescope through the Observer’s Interface. Useful for the operator, who can control the telescope through the operator’s interface.

• Traveler: This user is not actively connected to NRAO systems, but can use information locally available in his or her copy of the Observer’s Interface to construct internally consistent M&C configurations or astronomical observations to be scheduled.

17

Solution Components: Vision (6)Use Cases Supported

Use Case Name

Phase 0 Phase 1

New Capability

Expanded Capability

New Capability

Expanded Capability

User logs into the system as Master User constructs Configuration System configures M&C from Configuration User constructs Observation System constructs Configuration from Observation System checks health of relevant devices System constructs Scan from Observation System executes Scan User initializes relevant devices User reviews status of relevant devices User monitors antenna movement and environment information User executes external observation tables to manage an observation Not supported in Phases 0 or 1

User executes glish scripts directly to manage an observation Not supported in Phases 0 or 1

User logs in as Viewer or Traveler Not supported in Phases 0 or 1

18

Solution Components: Software ModulesEach component plays a role in the Envisioned Application Architecture

Layer Component Name Contains Uses Capabilities Technology

Presentation Astronomer’s GUI Observation Constructor Allows observer to construct standard observations

Java (JBuilder)

Status Panel Message Viewer Displays Go/No-go information on devices

Monitor Display Displays system data

Observation Table Constructor

Allows observer to construct an observation table

Observation Queue Manager’s GUI

Interface for flexible scheduling manager

Command Line Glish

Application Observation Compiler Table Interpreter Takes data in active memory and creates an XML tagged observation entity as file or data stream. In doing so, enforces observation consistency.

Cache Data Validation Information Used to validate observation parameters entered by user.

Configuration Information Used to check observations for self-consistency

Monitor client Front end for the Monitor data

Status client Front end for the Status information

Messaging client Front end for the Message data

Event Forwarder Forwards selected GUI events from the Observation Construction Display to the Looking Glass service, to be relayed to another instance of the Observation Construction Display

19

Solution Components: Software Modules (2)Each component plays a role in the Envisioned Application Architecture


Application Services

Observation Manager State Machine Maintains state information of Observation Manager

User Manager Handles user authentication

Queue Manager Manages observation entities that have been scheduled for future execution

Entity Manager

Scan Mapper Creates M&C compatible XML tagged scans from an observation entity

Scan Executor Takes XML tagged scan data and carries out the appropriate M&C commands to conduct a scan

Looking Glass Reflects Observation Construction Display GUI events to another instance of the Observation Construction Display

Monitor Interface Marshals appropriate M&C device data and makes it available to the Astronomer’s GUI

Status Interface Marshals appropriate M&C status information and makes it available to the Astronomer’s GUI

Messaging Interface Marshals appropriate M&C messages information and makes it available to the Astronomer’s GUI

FITS Writer Writes scan FITS file later use by filler

Glish

20

Solution Components: Software Modules (3)Each component plays a role in the Envisioned Application Architecture


Data Services XML Data Exchange An XML based interface to the database layer, which understands objects in the Object-Entity model

Database Observations Observation and Scan data Stores observations that have been submitted

User data Stores user data for use in authenticating an observer

Configurations Device base states Default states for all M&C devices

Observation procedures Library of common observation procedures (track, peak etc.)

Parameter mappings Data on how to map observation parameters to M&C device parameters

Source catalogs Information on sources that have been observed prior to the present observation, or candidates for calibration

Ephemerides

21

Solution Components: Software Modules (4)Modules Needed for Demo Scenario

Layer Component Name

Concept Inputs Outputs In Owner

Presentation GO+ GUI A graphical user interface used to construct system configurations and observations, and receive real-time feedback from

Astronomical metakeywords and definitions of observation procedures by the observer.

N/A Java Dave

Application Entity Compiler Validates GUI input to make sure individual chunks of data are within range, constructs Observation and Configuration XML entities.

Sends XML to Entity Manager

Java

Event Driver Handles all control connections over the network for GUI and Entity compiler, including login. Event Driver is also used to communicate with the real-time data display (such as IARDS), or to send the XML constructed over the network to the Entity Manager.

Java

Presentation/Application Deployment

Deployment Infrastructure

Java Web Start

Application Services

Entity Manager Knows how to route, handle and log Observation and Configuration entities;

Partially complete or fully complete Observation or Configuration Entities

Melinda

* Scan Mapper A logical wrapper around the Configuration Database. It integrates information about cabling, switches, filters and other subsystems with M&C configuration data selected from the Configuration database based on the observer’s metakeyword input. It knows how to return devices back to their base states (initialization).

C++

* Scan Executor Must be capable of interpreting complete Configuration entities

C++ Ray

Data Services MySQL/C Data Service

C Melinda

Data Configuration Database

MySQL

Astronomical Database

MySQL Amy

External M&C System C++ Mark/Joe

RT Data Display Eric

22

Data Layer (MySQL)

Data Services Layer

Application Services Layer

Internal: Run entirely on server side at NRAO GBExternal: Web-deployed interface run entirely on client side

Application Layer (Observation API)

Presentation Layer (UI)

M&C System

FITSWriter

LookingGlass

EventForwarder

Scan ExecutorMonitorInterface

StatusInterface

MessagingInterface

Messagingclient

Statusclient

Monitorclient

Monitoringdisplay Messages

Data Exchange

Status Display

GO+ Application

Glish CLI

CONFIGURATIONSOBSERVATIONS

Observation/ConfigurationConstruction DisplayQueue Manager’s GUI

Entity Compiler

Layered Architecture

RPC

Presentation Layer

yg

or_

gGlish CLI

display

* Details of specific observations and scans that make up those observations; user data for access to system

* Details of device base states, observation procedures, parameter mappings and source catalogs

Modules that interface directly to M&C System:

Databases partially populated in Phase 1

Entity Manager

State Machine

QueueManager

EntityManager

UserManager

ConfigurationInformation

Data ValidationInformation

CacheLogin

ModuleEventDriver

XML viaSOAP

Scan Mapper

(in-process communication)

23

Data Layer (MySQL)

Data Services Layer


Internal: Run entirely on server side at NRAO GBExternal: Web-deployed interface run entirely on client side



M&C System

FITSWriter

LookingGlass

EventForwarder


StatusInterface

MessagingInterface

Messagingclient

Statusclient

Monitorclient


Data Exchange

Status Display

GO+ Application

Glish CLI


Observation/ConfigurationConstruction DisplayQueue Manager’s GUI

Entity Compiler

Demo Scenario as Implemented

RPC

Presentation Layer

yg

or_

gGlish CLI

display





Entity Manager

State Machine

QueueManager

EntityManager

UserManager



CacheLogin

ModuleEventDriver

XML viaSOAP

gSOAP

Scan Mapper(currentlycontains

data exchangecode)

(in-process communication)

24

Data Layer (MySQL)

Data Services Layer


Internal: Run entirely on server side at NRAO GBExternal: Web-based interface run entirely on client side

XML-RPC



M&C System

ObservationTo

Scan Mapper

FITSWriter

LookingGlass

Table Interpreter

EventForwarder


StatusInterface

MessagingInterface

Messagingclient

Statusclient

Monitorclient

Monitoringdisplay

Messages

Cache

XML Data Exchange

Status Display

Astronomer’s GUI

Glish CLI




ObservationConstruction DisplayQueue Manager’s GUI

Observation Compiler

Phase 0

RPC

Presentation Layer

yg

or_

g

Obs TableConstructor

Glish CLIdisplay





To be completed by Phase 0Out of scope for Phase 0

Components requiring no development

Observation Manager

State Machine

QueueManager

EntityManager

UserManager

25

Data Layer (MySQL)

Data Services Layer



XML-RPC



M&C System

Scan Mapper

FITSWriter

LookingGlass

EventForwarder


StatusInterface

MessagingInterface

Messagingclient

Statusclient

Monitorclient


Data Exchange

Status Display

GO+ Application

Glish CLI



Entity Compiler

Phase 1

RPC

Presentation Layer

yg

or_

gGlish CLI

display







Entity Manager

State Machine

QueueManager

EntityManager

UserManager



Cache

26

Data Layer (MySQL)

Data Services Layer



XML-RPC



M&C System

ObservationTo

Scan Mapper

FITSWriter

LookingGlass

Table Interpreter

EventForwarder


StatusInterface

MessagingInterface

Messagingclient

Statusclient

Monitorclient

Monitoringdisplay

Messages

Cache

XML Data Exchange

Status Display

Astronomer’s GUI

Glish CLI






Phase 2

RPC

Presentation Layer

yg

or_

g


Glish CLIdisplay







Observation Manager

State Machine

QueueManager

EntityManager

UserManager

27

Data Layer (MySQL)

Data Services Layer



XML-RPC



M&C System

ObservationTo

Scan Mapper

FITSWriter

LookingGlass

Table Interpreter

EventForwarder


StatusInterface

MessagingInterface

Messagingclient

Statusclient

Monitorclient

Monitoringdisplay

Messages

Cache

XML Data Exchange

Status Display

Astronomer’s GUI

Glish CLI






Phase N

RPC

Presentation Layer

yg

or_

g


Glish CLIdisplay





To be completed by Phase NOut of scope for Phase N


Observation Manager

State Machine

QueueManager

EntityManager

UserManager

28

Delivery Approach: Phase 0Overview

We are using an eight week Prototype Development Approach in which one observing scenario is rapidly developed within the new architecture as a proof of concept.

Weekly tests will be performed to validate system components:

1. Configure M&CScan Executor takes Configuration Entity as input and accurately configures the M&C system in one action

2. Initialize M&CScan Executor takes a prepackaged Configuration Entity as input and accurately initializes the M&C system in one action

3. Run a ScanScan Executor takes Scan Entity as input and accurately executes an observing procedure

4. Generate a Scan Entity from Observation/Configuration EntitiesScan Mapper takes astronomically based entities and produces a Scan Entity that is digestible by M&C

We are using an eight week Prototype Development Approach in which one observing scenario is rapidly developed within the new architecture as a proof of concept.

Weekly tests will be performed to validate system components:

1. Configure M&CScan Executor takes Configuration Entity as input and accurately configures the M&C system in one action

2. Initialize M&CScan Executor takes a prepackaged Configuration Entity as input and accurately initializes the M&C system in one action

3. Run a ScanScan Executor takes Scan Entity as input and accurately executes an observing procedure

4. Generate a Scan Entity from Observation/Configuration EntitiesScan Mapper takes astronomically based entities and produces a Scan Entity that is digestible by M&C

29

Delivery Approach: Phase 0 AssumptionsArchitectural Demonstration

• Physical Architecture– A minimalist approach will be used– System will not yet be database driven or include a data services layer– Application layer cache will not be included

• Telescope Access Control– No security mechanisms will be implemented; “honor system” will still be in place

• Observation Construction– User will only be able to construct one type of observation– Attempts to use devices not supported in the demo scenario will not result in an observation

• M&C Configuration– Configuration capabilities will only be provided for devices critical to demo scenario

• M&C Initialization– Initialization capabilities will only be provided for devices critical to demo scenario

• Testing Configuration– No support in Phase 0

• Tweaking Configuration– No support in Phase 0

• Conduct Observation– No events will be sent to IARDS for real-time display

30

Delivery Approach: Phase 0 TasksOverview

Identify Demo Scenario• Articulate contents of Observation, Configuration and Scan Entities for this scenario only• Identify default M&C parameter settings for pertinent devices• Assess whether automated IF routing should be done as App Service or in M&C System• Identify default IF path, alternate paths and rules for selection

Presentation Layer• Produce GUI mockup for Control, Monitor and Status Panels• Build configuration panel with automated configuration logic

Application Layer• Produce prototype for Observation Compiler

Application Services Layer• Produce prototype for Observation Manager• Produce prototype for Observation to Scan Mapper• Produce prototype for Scan Executor

Data Services Layer• Produce prototype for database-independent XML Data Exchange

Data Layer• Produce Foundational Data Structures and Databases

Milestone: Solution Demonstration• Involve commissioners in an active design review session prior to start of Phase 1

Identify Demo Scenario• Articulate contents of Observation, Configuration and Scan Entities for this scenario only• Identify default M&C parameter settings for pertinent devices• Assess whether automated IF routing should be done as App Service or in M&C System• Identify default IF path, alternate paths and rules for selection

Presentation Layer• Produce GUI mockup for Control, Monitor and Status Panels• Build configuration panel with automated configuration logic

Application Layer• Produce prototype for Observation Compiler

Application Services Layer• Produce prototype for Observation Manager• Produce prototype for Observation to Scan Mapper• Produce prototype for Scan Executor

Data Services Layer• Produce prototype for database-independent XML Data Exchange

Data Layer• Produce Foundational Data Structures and Databases

Milestone: Solution Demonstration• Involve commissioners in an active design review session prior to start of Phase 1

31

Delivery ApproachThe delivery approach provides priority benefits as early as possible:

Week Task Stage Who

May 27-31 Finish Use Cases, Identify Demo Scenario & XML Data Entities 2: Design Ray, Melinda, Mark

June 3-7 Identify M&C Configuration for Demo Scenario

Create XML Data Entities for Demo Scenario

GUI Mockup

2: Design Mark

Ray, Melinda

Nicole

June 10-14 Prototype One-step Configure/Initialize M&C

GUI Mockup

2: Design Ray, Melinda

Nicole

June 17-21 Prototype Scan Mapper

GUI Mockup


Nicole, Toney

June 24-28 Prototype Observation Compiler

GUI Mockup


Nicole, Toney

July 1-5 Conduct end-to-end tests of prototype 2: Design All

July 8-12 Conduct live demonstration of prototype; begin gap analysis 2: Design All

Sep 2-6 Validate & Test Release 1; Production Rollout 5: Rollout All

0

1

Releases

Phase 1 Development

Gap Analysis is the Project Artifact resulting from a dedicated, community-oriented design review; it tells us exactly what we need to know for iterating on the design

of the prototype.

go+: the gbt observer’s interface project charter (int0205-001) thursday, may 23, 2002 ray creager...

Documents

n nrao gb

n strategic goals

n schedule project summary

expert users

novice users

intermediate users

standard users

longterm nrao vision