GUPPI Controller Design

Overview

GUPPI software is to have a layered architecture, with an external client at the top level and the IBOB/BEE2/CASPER hardware controllers at the bottom level. These layers aim to provide cleanly separated concerns, which in turn should ease rapid development.

Simple Diagram

As of 24 Jan 2008:
GUPPISoftwareLayers.png

Simplified diagram showing GUPPI software modules and respective responsibilities.

A class diagram is to be provided further into development...

Server-Client Level

High-level access to GUPPI

GUPPI Server

Responsibilities:
  • GUPPI Controller Exposure - exposes the public controller operations to the client.

GUPPI Client

Responsibilities:
  • External Interface - provides the external client with a portal/API to the GUPPI server.

Server-to-Client Interface

Type: SOAP service

Server will act as a SOAP service, and the client (e.g. the GUPPI manager, or a command line client) will act as a SOAP client.

Controller-to-Server Interface

Type: SOAP service agent

The "controller" will be the service agent which delegates the server's SOAP requests to the appropriate devices.

Data & Control Level

Core "business logic" of GUPPI

GUPPI Controller

Responsibilities:
  • User Functionality Logic - central point of implementation for user functions and configuration of the instrument.
  • Hardware Parameter Exposure - exposes hardware monitor & control parameters of the common hardware interface.
  • Data Acquisition Control - provides instructions to the Data Acquisition module.
  • Data Acquisition Parameter Exposure - exposes select monitor parameters of the Data Acquisition module.

GUPPI Data Acquisition Module

Responsibilities:
  • Data Storage - writes collected data to disk.
  • Data Quick-Look Access - provides a means to access snapshot data.
  • Data Acquisition Parameter Access - provides select monitor parameters, such as a heartbeat, recording status, disk usage, etc.

Controller-to-Data-Acquisition Interface

Type: Shared memory

TBD.

Hardware-to-Controller Interface

Type: programming methods/functions, providing Python dictionary syntax

Requirements:
  • Get a list of parameters.
  • Get a parameter's value by name/key.
  • Set a parameter's value by name/key and target value.
  • Get a list of available personalities (aka profiles, most notably the BORPH files on the BEE2; *.bof)

Controller semantics:
  • get() - returns a list of currently visible parameters; =['key1', 'key2', ..., 'keyN']
  • get(key) - returns the value of the parameter which matches the key
  • set(key, value) - sets the value of the parameter which matches the key
    • Alternate syntax using dictionary
  • load() - returns a list of currently available (non-running) personalities
  • load(personality) - attempts to load the specified personality; returns 'False' if the personality fails to load properly
  • unload() - returns a list of running personalities
  • unload(personality) - attempts to unload the specified personality; returns 'False' if the personality cannot be uniquely identified or if the personality is not running
  • profiles() - returns a list of all known personalities and a status code in the form ['personality,c', ...] where
    • 'personality' is the name of the personality, e.g. 'BEE2/b2_GDSP_U1_4K_800_A_XA_fpga1_2008_Jul_30_1356.bof'
    • 'c' is the personality's status code: 'r' for running, 'a' for available, or 'u' for unknown
  • profiles(personality) - returns the same information as above, but for only the specified personality

GUPPI Common Hardware Interface Level

Common hardware interface to GUPPI's boards

Common Interface

Responsibilities:
  • Common Parameter Access - combines the parameters of each of the hardware boards into a single interface with a common high-level container (e.g. dictionary / hash table), i.e. knows the parameters which belong to the IBOB and the BEE2 and sorts them out accordingly (while hiding these details from the innocent).
  • Parameter Datatypes - transforms high-level input into the necessary datatype for the hardware interface.
  • Parameter Dimensions - reports units/dimensions which correspond to the parameters (e.g. 'MHz', 's', etc.).
  • Parameter Mutability - reports which parameters are read-only.

Board-to-Common-Interface Interface

Type: programming methods/functions, providing Python dictionary syntax

Requirements:
  • Get a list of parameters.
  • Get a parameter's value by name/key.
  • Set a parameter's value by name/key and target value.

Pseudocode:
  • board.keys() - returns a listing of parameters; ["key"]
  • board[key] - returns the value of the parameter which matches the key; throws exception KeyError if no parameter matches the key
  • board[key] = value - sets the value of the parameter which matches the key; throws exception KeyError if no parameter matches the key

Board Interface Level

Board access for GUPPI

IBOB Interface

Responsibilities:
  • IBOB Parameter Access - provides a means of access to the IBOB and its parameters.

BEE2 Interface

Responsibilities:
  • BEE2 Parameter and BORPH Access - provides a means of access to the BEE2 and its parameters and personalities.

Helper Classes

Support & Utilities for GUPPI

GUPPI Parameters

Responsibilities:
  • Parameter File Access - parses input parameter files.

Behavior:
  • parses Comma Separated Values (CSV) files
    • delimiter = ',' and text is specified with double quotes
    • hence, a value cannot retain double quotes
  • expects the following column header properties
    • the first row contains the column headers
    • the first column contains the parameter name
    • columns can be in any order beyond the first column
    • duplicated column headers may cause conflict
  • treats each row and cell as follows:
    • all values are treated as strings
    • each parameter name is unique... duplicates are ignored
    • whitespace is ignored
    • a line starting with '#' is a comment
      • "#comment_test","B","BEE2","no","0","..." is a comment
      • #"comment_test","B","BEE2","no","0","..." is a comment
Use:
  • Maintain one "production" parameters file (basefile) to keep knowledge of:
    • parameter units (for ease in human readability)
    • default parameter values
    • destination of each parameter (i.e. board which shall receive each parameter)
    • which parameters are read-only
  • Allow for flexible runtime parameter file (configfile) input

Implementation Guidelines & High-Level Decisions

  • Putting It All Together
    • The central information flow Server -> Controller -> Common Hardware Interface -> Board Interfaces is combined into a single executable program.
    • The board-side IBOB Interface and BEE2 Interface run on their respective boards.
    • The GUPPI Client communicates by a network protocol from any machine.
    • The GUPPI Data Acquisition module communicates via interprocess communications on the same machine.
  • Programming Language Choice
    • Ron is going to use python for the GUPPI Controller.
      • The Common Hardware Interface will be written in python to quickly leverage existing python code which provides board interfaces.
      • The GUPPI Server will likely be written in python.
      • The Data Acquisition module is independent to the Controller and can be written in a different language (C).
    • Scott and Paul are going to use C for the GUPPI Data Acquisition module.
  • Serving GUPPI
    • The Server-Client Level is effectively ignored for phase 1 of GUPPI.
    • The first "server" is to be a simple command-line user interface to the controller.

-- RonDuPlain - 02 Jan - 23 Jan 2008
Topic attachments
I Attachment Action Size Date Who Comment
GUPPISoftwareLayers.pngpng GUPPISoftwareLayers.png manage 60 K 2008-01-24 - 11:41 UnknownUser Diagram illustrating GUPPI software layers
Topic revision: r6 - 2009-03-23, PatrickBrandt
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding NRAO Public Wiki? Send feedback