Dual Holas and RoIB Replacement Strategy Long and short term plans - - PowerPoint PPT Presentation

Dual Holas and RoIB Replacement Strategy

Long and short term plans for the RoIB and redundant L1 outputs to it

• R. Blair,Last Feremenga, Jeremy Love, Othmane Rifki,,

Jinlong Zhang

RoIB requirements on the dual-Hola: L1 Coord. 1/7/14 2

Cartoon of evolution of the RoIB

RoIB requirements on the dual-Hola: L1 Coord. 1/7/14 3

Current Status

• Have RobinNP at ANL

– Doing rate measurements to evaluate whether existing ROS fjrmware/readout software will suffjce for our traffjc – currently older underpowered systems used for testing – have a high end system for RobinNP work on order

• Have exercised the ROS testing routines

– collaborating with Jos, Markus and Will Panduro – so far the results are not fully consistent with ROS groups but see above

RoIB requirements on the dual-Hola: L1 Coord. 1/7/14 4

Short term

• Develop the software to use the C-RORC based on the ROS readout

and fjrmware

– First as a simple replacement for the FILAR/TILAR

• T

est and evaluate performance of the above

• likely will involve some simplifjcation of the l1id handling since the

RoIB/HLTSV use case is a bit difgerent

– provided performance is adequate

• add assembly software to allow direct input of level 1 fragments and software

assembly in the HLTSV thus eliminating the RoIB

• T

est and evaluate performance of the above

• If software assembly and the above fails to meet the required rate

then fjrmware changes to optimize the C-RORC performance will be needed

– modifying existing fjrmware to allow 120kHz operation (read in) – some fjrmware assembly of fragments

• Either way fjnal testing and deployment can be done using the

backup HLTSV and fjnally put into service with the primary HLTSV

– The system should remain operational during these transitions

RoIB requirements on the dual-Hola: L1 Coord. 1/7/14 5

Timescale/tasklist

• develop software (and perhaps some fjrmware) to allow use
• f the C-RORC instead of a FILAR or TILAR for the HLTSV input
• October 2014
• prototype and testing direct input using the C-RORC

(eliminating the need for fragment assembly in the RoIB)

• October 2014 (manpower issues may delay this)
• get things set up at point 1 to allow duplicate outputs from level 1

so we can have a prototype system testing in parallel with a proven system

• the proven system could be the current TILAR+RoIB system
• test could be C-RORC input fed by the RoIB (single point of failure is RoIB)
• r results of step 2 above with all inputs directly to the C-RORC (no single

point of failure)

• tests might be done with the latter, running done with the former
• Once test system is proven it is made production and the “proven

system” replaced with a copy

RoIB requirements on the dual-Hola: L1 Coord. 1/7/14 6

Implications w.r.t. L1 inputs

• Initial running might involve a production and a test system

– slave type output would be okay for this with the production system the master and the test the slave – this may be pessimistic

• if there is no need for fjrmware revisions and the ROS drivers are adequate

this is the preferred option to minimize customizations for RoIB operation

• if the above condition is satisfjed very little work is required to adapt the

HLTSV and initial running may be possible in this mode

• Ultimately the objective is to avoid the need for any 24/7 on call to

support RoIB functionality

– for this running with either system down would be required (i.e. master/slave type status would be an issue) – either link's receiving end may be down while the other link is active

• Prefer a minimum of changes needed for swap from one system to

the next since data taking stops if the RoI Building is down

– clearly some software reconfjguration both at the HLTSV and perhaps the upstream end would be required

RoIB requirements on the dual-Hola: L1 Coord. 1/7/14 7

Dual HOLA strategy

• For the testing phase

– test setup gets L1 from the dual HOLA slave outputs – primary system gets inputs from master outputs – Master is always available for system operation, slave is used in parasitic mode for testing

• For fully redundant operation

– slave runs as the primary output to the HLT – if the slave HLTSV fails the HLTSV connected to the master outputs takes over – this approach requires the master to be operational for the slave setup but not for data taking under normal conditions

• the master connection can function alone after a failure while the slave

system is brought back up

• for confjguration purposes this introduces a small risk that the setup of

the links might be broken if the HLTSV connected to the master outputs fails – solution: swap master/slave inputs to the redundant HLTSVs

RoIB requirements on the dual-Hola: L1 Coord. 1/7/14 8

Backup slides

RoIB requirements on the dual-Hola: L1 Coord. 1/7/14 9

Possible Improvements to Reduce Risks and Support Costs

Plans for simplifying the system architecture fit with decreasing the amount of custom hardware and the need to support it. HLT Supervisor would be a commodity PC with custom input cards. Run I Run I system system Run II Run II system system