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
Cartoon of evolution of the RoIB RoIB requirements on the dual-Hola: L1 Coord. 1/7/14 2
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 3
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 4
Timescale/tasklist ● develop software (and perhaps some fjrmware) to allow use of 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) or 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 5
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 6
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 7
Backup slides RoIB requirements on the dual-Hola: L1 Coord. 1/7/14 8
Possible Improvements to Reduce Risks and Support Costs Plans for simplifying the system Run I Run I architecture fit with decreasing system system the amount of custom hardware and the need to support it. HLT Supervisor would be a commodity PC with custom input cards. Run II Run II system system RoIB requirements on the dual-Hola: L1 Coord. 1/7/14 9
Recommend
More recommend
