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:
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