CERN Accelerating science

Middleware

Issues (in no particular order)

• Size of server side CMW implementation (around 4 Mbytes apparently) BISCOTO - JJG not happy with 4 Mb to provide command-response
• Homemade publish & subscribe mechanism
• Device/Property model inadequate
• How do we want to subscribe: device/property/cycle selector (cycle type, cycle, cycle time) . needs to be defined.
• User options ... foresaw stateless calls (just great), complications of two conflicting subscriptions to the same piece of equipment.
• subscription on change, state OK, what about tolerances.
• Quentin not happy with performance of CMW
• BT need to know whether or not to proceed with the DIM/contract framework.

Towards a common middleware: SPS2001 provides support library for device property (implement with CMW). First, implement device data with CMW. Device server framework to declare data properties (meta-data). (Note: XML translated to header file, C structure, validation, Java class)

MJ to provide stripped down version. Kris to link to CMW. Possibly test with RF timing modules (Andy). Client side wrapper around device properties.

However, attempt cut short by questions about CMW's ability in its present state to meet requirements of power converters and BI.

Requirements

1. Simple set command/response to one device. Switch power converter on. Response indicates that the command has been successfully (or not) received, not that it has been completed. Command could be an action (INIT) or a state change for example.
2. Command/response set with parameters to one device. Data structures can get complicated, for example, when loading functions.
3. Simple get command/response to one device. Data structures return could be quite complicated
4. Get command/response with parameters congiguring the nature of the get. Measurements.
5. Context dependent get - cycle type, id, time in the cycle
6. Context dependent set - cycle type, id, time in the cycle
7. async versions of above,
8. multi-equip version of the above
9. Subscription - on change - periodic - condition subscription

MEQUIP

minfo[mequip_hw].nam = nam;
minfo[mequip_hw].action = action;
minfo[mequip_hw].mode = mode;
minfo[mequip_hw].cycle = Request->ActHWEntry[hwind].SegID.EVCode;
arg[mequip_hw] = (char *)s_array;
bcnt[mequip_hw] = ndata * sizeof(short);

n_bad = MEQUIP(mequip_hw,   time_out,    minfo,     bcnt,    (long *)0,    arg,     Errmsg,    errnum,    asy_YES);

LEP's old mequip

rc = equ_m_sf_q(&ordpca, &ordfam, &ordmem, pHWSettings->ActualHWCommand, 0, "B", &ordseq, &orderr);

Use of blackboxes....

if (!strncmp(HWSettings.ActualHWCommand,"address-",8)) ret = BBmiladdr_read(&HWSettings,&Ans);
else if (!strcmp(GroupType,"PC") || !strcmp(GroupType,"EXPTPC")) ret = BBpwc_read(&HWSettings,&Ans);
else if (!strncmp(GroupType,"BIVID",5)) ret = BBbiv_read(&HWSettings,&Ans);
else if (!strncmp(GroupType,"STOPPER",7) || !strncmp(GroupType,"SCREEN",6)) ret = BBsls_read(&HWSettings,&Ans);
else if (!strncmp(GroupType,"RF",2)) ret = BBrf_read(&HWSettings,&Ans);
else if (!strncmp(GroupType,"ERF",3)) ret = BBrfequ_read(&HWSettings,&Ans);
else if (!strncmp(GroupType,"COLL",4)) ret = BBcol_read(&HWSettings,&Ans);
else if (!strncmp(GroupType,"MUG",3)) ret = BBPCMug_read(&HWSettings,&Ans);
else if (!strncmp(GroupType,"ZL",2)) ret = BBZL_read(&HWSettings,&Ans);
else if (!strncmp(GroupType,"KI",2)) ret = BBkick_read(&HWSettings,&Ans);
else if (!strncmp(GroupType,"SPSKICKER",9)) ret = BBspsKickers_read(&HWSettings,&Ans);
else if (!strncmp(GroupType,"DUMP",4)) ret = BBSpsStopper(&HWSettings,&Ans);
else if (!strncmp(GroupType,"DAMP",4)) ret = BBSpsDamper(&HWSettings,&Ans);
else { SetERROR(0); InfoMessage("Error : ","I Have No BlackBox to Call for the ","Selected Hw Type"); return(1); }

Sometimes if all you need to do is a simple single command calling the bb is a bit of a pain because you have to setting up the structures for the call. This is if you're off making an ahoc sort of access. But what you do see it that the effort comes in marshalling the data for a call not in actually making the call.

With sloppysoft wherein the data (if needed) was on the database the following simple call was all that was necessary:

DriveHardware(local,&DriveSelection,&DriveReply);

Users: experts, control room application programmers, ad-hoc application development

• supports a remote method invocation paradigm
• provides location transparency
• allows to add, exchange, or remove services dynamically, dynamic device/propoerty declaration
• hides system details from the developer
• Multicasts
• timing oriented subscription (debate about whether this should be handle by the middleware)
• recovery of lost or late connections
• As far as BI are concerned any middleware proposed must provide, at least, that offered by sl-equip. Namely: single entry command, data in, data out, user options...
• simple interface for equipment experts
• synchronous command/response
• asynchronous for multi-call fan-out

Measurements and the need for user options to configure some of them.

• One off: with configuration as a property (user options with sl-equip)
• measurement already there - filter it and return
• condition equipment for measurement - setup filter. View one-off measurements as subscription used once. Might be a problem with MW servers and resources on front ends, CPU budget etc.
• Many clients...

PS/SL common middleware project

• aim to reduce maintenance costs by choosing a common solution
• use of-the-shelf commercial solutions
• apparently needs two middleware concepts: CORBA and MOM
• filter and cycle selection

Objections

• deployment of two solutions too resource heavy, not simple
• MOM not directly available on Lynx
• will not resolve maintenance issue
• additional effort required to maintain commercial solution (versions etc...)
• tries to solve problems that are not the responsibility of middleware
• commercial middleware targets commerce not accelarators & therefore not appropriate
• weak typing

SPS2001

"definition of a coherent and equipment-independent device access interface"

Two main aspects: use of DIM, and the functionality offered by the device server: use of contracts, support for multi-cycling etc. Underlying middleware hidden away.

Will need some multi-cycling support, cycle catalog for devices/groups of devices, resisdent set (add, delete etc). API defined, implementation progressing. Provides added value via state contract etc...,

• in-house
• based on DIM, matches requirements (apparently), light-weight
• strong typing with weak typing extensibility
• context management
• server API implemented by header file that describes structures for strongly typed device properties, device server support library... convenience functions ... infrastructure to manage declared devices, device properties, and cycle management.

Objections

• will we ever get everyone to buy into sps2001 device server framework, and what about the inevitable case when they don't or won't.
• maintenance - who will provide extensions & maintenance
• based on home made technology
• somewhat complex server side interface, equipment experts need something fairly simple
• asynchronous... (apparently not a problem to provide synchronous calls...)