The Application of CORBA in a Generic

Data Acquisition Program

SRCG Team

Geoff Mant Paul Stephenson Mike Miller Steve Kinder Karen Ackroyd N Vasanthi

Motivation

Construction of Data Acquisition program for a combined technique station.

Integration of Unix, PC and VME environments. Provide software with a common ‘Look and Feel’

across stations to make set up and data collection easy. Integrating all detectors and ancillary equipment into one interface.

Create “plug and play” components with well defined interfaces using object-oriented programming principles to provide flexibility to cope with future changes.

Provide an interpreter for complicated and rapidly changing experiment protocols

Schematic

Beam-line Components

Devices

GUI Interpreter

EPICS Devices

Design Decisions

• UML (Unified Modelling Language) for analysis and design.

• C++ for OS-9 programming.• Java for beam-line components and graphical user

interface (easier to program, large number of built in class libraries, garbage collection, threads, portability).

• CORBA for middleware (Orbacus)• Jython as an interpreter• Allow multiple client access.

Component Overview

OE Object

GUIABA/App

ADC McLennan:MotorSRS122:Motor

McLennan:Motor

Existing Code

Why CORBA

• Industry standard supported by the OMG• Provide connectivity between VME, PC and Unix

systems• Orbacus CORBA was chosen for its C++ and Java

flavours and its was FREE or so we thought!• Robust communication, hiding socket programming

and retaining a strongly typed interface. i.e. multiple idl files specifying wide interfaces.

Features

• Factories for object creation • Name Server for location of objects• Event Server for asynchronous

communication• XML for configuration

Event Service

Overall Design

ClientClient

Client

OE Server

Object Server

Naming Service

Naming Service

Application framework

Client

ObjectServer

Table Slit

Adapter Pattern - Server side

«interface»Temperature

TemperatureImpl

LaudaWaterBath

_OrbacusTemperatureImplBase

+Update()

«interface»IObserver

«datatype»TemperatureEvent

Create AnyInsert the Temperature Event into AnyPublish on the EventService

«interface»IObservable

TemperatureBase

ObservableComponent

Adapter pattern to provide some independence from the middle-ware and also to allow the components to interact as a monolithic system should the need arise.

Adapter Pattern - Client side

«interface»Temperature

Client

TemperatureAdapter «interface»OrbacusTemperature

StubForOrbacusTemperature

ObservableComponent

«interface»IObservable

+Update()

«interface»IObserver

Create a filter for events with TemperatureEvent datatypeSubscribe to the Event Service with filterMethod inform notifies all IObservers

«interface»Subscriber

The client side adapter contains code to allow the re-connection to the server if this has died and been restarted.

Creation of Objects

+find() : Findable+addFactory()

Finder

«interface»Findable

+configure()+create()

«interface»Factory

+configure()+create() : Findable

LocalFactoryAdapterFactory

1 0..*

«interface»Temperature

Server StartupParse the xml resource fileCreates a local factorycreate NetServicecreate EventServicecreate an adapter factoryadd local and adapter factories to findercreate the factoryImplconfigure from resource data

+configure()+create()

FactoryImpl

TemperatureImpl

Serial

Drawbacks

• Cost of Orbacus(Iona) CORBA licence• Now frozen at release 3.1.3• Old OMG CORBA specification• Can’t pass Java objects, although if you know

its only Java to Java serialization is one option.• We have used inheritance based CORBA

which is now problematic on the server side. Tie mechansim would be better but not ideal.

• numerous idl interfaces (pro or con?)• Java multiple inheritance in our design

• Aligns beamline for data collection.

• OEMove provides a standard tool to allow the control and set up of Optical Elements.

• Easily configurable for different stations.

• One tool meets needs of many projects.

Align Beam-line

• Standard absorption edge scan interface.

• Will support multiple modes, Angle, KSpace and Fast.

• GUI completely detached from control.

• Scans done via JCLAM (scripting language - python extension).

Xafs

• Data collection making good progress, tested with Q4 and MAR180 & MAR345 detectors.

• Same GUI independent of detector in use.

• Detector specific bits provided by Detector implementation.

PX Data Collection

• Configuration of the timer frame generator for multiple frames and profiles

• Detector set-up with memory usage feedback.

• Data output details

NCD Configuration

• Load, save and execute scripts

Interpreter

Future

• Another brand of CORBA• Utilise Java offering• RMI over IIOP• Get rid of OS-9 in favour of Linux• SOAP