TAC Review

TAC Review

ONCS Common Control Architecture

August 10, 1998

Edmond Desmond

On-Line Distributed Architecture Goals

Provide a framework for the monitoring, configuration and control of controllable PHENIX detector elements

Support the distributed heterogeneous control environment required for the PHENIX environment.

Provide support for detector partitions

Implement Shlaer - Mellor rules for active object interaction

Provide a framework for de-coupled development and execution of client and server applications in a distributed environment.

Provide insulation from subsystem developed code

Provide a uniform interface to common functions and services

event (commands and message ) delivery mechanism

error logging

component status monitoring facilities

Characteristics of the On-Line Architecture

Asynchronous Event Driven communication

Name based Access to system components

Allows use of device naming convention to identify components by subsystem

CORBA based distributed communication

State Driven Active Objects

PHENIX Detector Control Environment

Provides Controls for

Data Collection System

Data Collection Modules (DCM)

Data Collection Boards (DCB)

Partition Module (DPM)

Event Builder

Sub Event Buffers (SEB)

Event Builder Controller (EBC)

Assembly Trigger Processors (ATP)

Level 1

Timing System

Global Timing Module (GTM)

Master Timing Module (MTM)

Main Magnets

FEM

Architecture Implementation

Selected Orbix by IONA Technologies for CORBA Implementation

Market Leader

CORBA 2.0 Compliant

Full C++ mapping

Broad Platform Support
Solaris
IRIX
VxWorks
NT

provides JAVA IDL Mapping with OrbixWeb

provides COM bindings

Java client applications

Provides platform independent execution environment

relatively easy to develop

large and growing base of functional components available

selected Jbuilder IDE development environment

Available Orbix Functionality includes

Transparent Object location and invocation

proxy objects for local cache or remote object information

Object and Process Filters

Client and Server co- location

Loaders and Object Fault Handler

Object Interface through public IDL

A language independent description of the public interface to an object

Orbix IDL compiler generates stub code from interface description

Interface Definition Language (IDL)

Defines and makes public the interface to the distributed components

interface NameService {

void BindName ( in string objectName,

in Object objectRef );

long ResolveName ( in string objectName,

out Object objectRef );

};

Architecture Mechanisms for remote object access and Invocation

Naming Service

Event Notifier

Object Managers

Active Objects

Naming Service

Provides access to ONCS services by character string names

resides at a well known address

provides an object reference to a remote object service

Using the Naming Service

// Client Code

nameserv_ptr pns;

pns = NameServer::_bind(":NS"," ");

// obtain a reference to a registered object

CORBA::Object_ptr pobject;

pns->ResolveName("daqevnot", pobject );

// Server Code to Register Objects

En_ptr pevnot = new TIE_EN(evnot_i)

(new EN_I(),"daqevnot");

pns->BindName("daqevnot",pevnot);

Event Notifier

Provides a mechanism for asynchronous routing and delivery of events and messages

Active objects register their interest in receiving an event with the event notifier

active objects can unsubscribe at any time

Provides an Object Observer Pattern implementation

Modeled on CORBA 2.0 Event Service

Using the Event Notifer Service

servers create and subscribe active objects

pdcm1 = new TIE_Dcm(Dcm_I)

(new Dcm_I( ),"dcm1");

pevnot->subscribe(eventlist,"dcm1",pdcm1);

Clients send asynchronous event via the Event Notifier

Event event;

// fill event with event identifiier and data

pevnot->sendevent(event );

CORBA 2.0 Event Service Model

Provides Push and Pull Event Models

events are pushed from the event generator to the event Channel Object

events are pushed to Push event Consumer

Event Notifier Implements the Push Model

Provides reliable event delivery

Intended development path when available

Object Managers

Each remote server contains a manager for local objects

Manages the creation and access to all objects local to the server

Provides dynamic object creation

Provides a method for remote access to local object references

provides iterator services over the objects it manages

Using the Object Manager

Obtain a reference to the Object Manager from the Name Service

pns->ResolveName("daqobjmgr", pobjmgr );

Obtain a list of active objects

Pobjmgr->getObjectList( objectlist );

Obtain a reference to a managed object and invoke that method

CORBA::Object_ptr pobject =

pobjmgr->getObjectRef("dcm1", pdcm );

Create a new object dynamically

pobjmgr->newComponent("dcm2",pobject);

Active Object Implementation

Implement a Finite State Machine to define the objects possible actions
Transitions between states are made on the reception of events
Provides Accessor methods for the return of status information
Accept events through a takeevent method

Using the Active Objects

Define a state transition diagram for each object state

Clients cause state transitions by sending events

Event event;

// fill event structure;

event.eventid = 1;

pevnot->sendevent( event);

Event Structures

Events pass an event identifier, the source and destination object name and auxilliary data

struct Event {

long eventid;

EventType type;

string srcObjectName;

string destObjectName;

Any devicedata;

};

Component Inheritance Hierarchy

PHENIX Naming Convention

A format for naming and identifying components throughout the PHENIX detector system.

Conventions for detector segment and configurable devices have been defined and agreed upon by the collaboration

FEATURES OF A NAMING CONVENTION

Isolates application code from component implementation

Identifies the device type to easily parse and collect components of a particular type.

This can be used by applications such as error loggers and process monitors to easily identify all components of a particular type for a particular detector.

Identifies the sub detector and location to which a component belongs.

DCM.PBSC.[E].SE[0-3].SM[0-17]

DCM.PBSC.E.SE1.SM2

Sub System	Mnemonic
BB	Beam Beam
MVDB	MVD barrel
MVDE	MVD endcaps
DC	Drift Chamber
PC1	Pad Chamber
PC2	Pad Chamber 2
PC3	Pad Chamber 3
TEC	Time Expansion Chamber
RICH
TOF	Time of Flight
PBSC	Lead scintillator
PBGL	Lead Glass
MUTR	Muon Tracker
MUID	Muon Id
LV1	Level 1
PHNX	Phenix Global Resource
MM *	Main Magnet

Arms

Arm Identifier	Arm Name
E	East
W	West

Side

Side Identifier	Side Name
N	North
S	South

Segments:

Segment Identifier	Segment Name
SM	Supermodule
SR	Supermodule row
SC	Supermodule column
SU	Super Unit
KS	Keystone
PL	Plane
PA	Panel
SE	Sector
HS	Half Sector
RO	Row
CO	Column
MO	Module
EN	End
SL	Slat
ST	Strip
TO	Tower
CE	Cell
GP	Gap
SN	Station
TB	Tube
TV	Tube Vertical
TH	Tube Horizontal
WE	Wedge
CH	Channel
CN	Chain
C	EndCap
B	Barrel

Configurable Devices

Component Name	Component Type
DCB	Data Collection Board
DCM	Data Collection Module
FEM	Front End Module
HV	High Voltage
MTM	Master Timing Module
GTM	Granule Timing Module
PPG	Programmable Pulse Generator

Others as identified
LL1BD	LL1 board
GL1BD	GL-1 board

Current Implementations

Implemented DCM and DCB server and components

VME based

Currently used for DC DMC test stand at BNL and for development at Nevis

Implemented SEB server and component
NT based
Executes same server as VxWorks based server

Main Magnet Controls

Implemented Magnet component and server

NT based
Provides controls for North, South and Central Magnets
Scheduled for testing mid July 1998

Interprocess Communication Mechanisms

ONCS server and application code is isolated from sub system developed code

Provides for independent development paths

Provides run-time isolation

Sub system code executes in a separate process

Each process is spawned at boot time by the ONCS server code
Allows separate run-time process priorities

Command are sent via message queues

All commands are required to return a completion status code

Monitored data is read through shared memory

In VxWorks global variables are shared between processes
In NT a memory mapped file implements the shared memory

Data Collection System Controls

DCM and DCB components have been implemented

resident in PPC VME crates running VxWorks

Spawn separate process to isolate the development and runtime execution of subsystem developed code

provides a message queue for transmission of commands to the sub system process and the return of status and function data

Provides shared memory facility for communication of data between processes

Provides control of component initialization , data download, status monitoring

Client Java Applet developed and used here and at Nevis

to control DCM operations

Each Partition will have its own server as partitions may run independently

Sub Event Buffer Controls and Management

NT based implementation

contains the same server code as the VxWorks DCM system.

Server code creates, configures and manages SEB components

ONCS server code spawns Real-Time process which controls the event data flow.

Shared memory via Memory Mapped files was developed for communication of monitored data and commands between the ONCS and the realtime process.

Java client was developed to access and control the SEB system.

Main Magnet Controls

NT based implementation

Provides controls for North , Central , and South Magnets

Server based magnet components execute control and monitor magnet functions and status

Interfaced to AGS Allen Bradley PLC controller to monitor water, temperature status and fault conditions via DDE

Java client application was developed for Main Magnet Controls.

Main Magnet Controls

Consists of 3 Invar Power Supply Main Magnets

north central and south magnets.

Control Interface

RS422 serial control

ASCII command and status return

Synchronous communication only

Allen Bradley Serial Highway to Allen Bradley Fault Monitoring Controller

Control System Description and Components

Command control and monitoring from NT based server

Uses ONCS common server and component interface.

Java based application interface implemented

Facility fault monitoring from Allen Bradley PLC -5 controller.

Control and monitoring application is written in PLC ladder logic by AGS personnel.

Interlock connection between main facility monitoring of critical faults

( temperature and water flow) and system shutoff

Fault monitoring of main facility interlocks will be connected to Invar internal fault bus

Facility faults are updated to ONCS monitoring process.

Schedule

Initial magnet mapping tests are scheduled for mid July.

Main Magnet Control Connections

ONCS readout of Allen Bradley monitored status and faults is through and Allen Bradley serial highway.

Allen Bradley NT drivers were purchased as part of the Rslinx software package.

Connection to ONCS server is through Rslinx DDE message mapping.

Main Magnets Command and Monitoring Functions

Command Set

Voltage setpoint 0 - 120v

Current setpoint 0- 3800 amps

Voltage Ramp Rate 1.2 to 126 volts/second

Current Ramp Rate 4.0 to 400 A/second

System start/stop

System reset

Power on / off

Start ramp up / down

Voltage readback

Current readback

Voltage setpoint readback

Current setpoint readback

Ramp rate readback for voltage and current

Fault status readback

Reads back 44 individual status indicators