TSU CONS Reliability Meeting - 3
Present: M. Blaszkiewicz, L. Felsberger, N. Voumard, P. Van Trappen, J. Uythoven
Minutes
The main focus of the meeting was reliability block diagram of the three beam dumping scenarios.
Recap - Top-level FMECA table (excerpt)
This slide was a recap of the table discussed in the last meeting. It highlighted only the most critical failures. In the discussion, Jan has confirmed that the "acceptable once in 10 years" should be applied for an asynchronous beam dump, even though such a beam dump should occur not more often than once per year. The reason is that there are multiple systems which may trigger that effect. It has been suggested to be marked in the table.
Nicolas noted that no such event has been triggered by the TSU in the last 10 years.
Pieter asked about 3.1.1.1 "no damage" after an asynchronous beam dump. Both Jan and Nicolas agreed that it should remain as such.
Nicolas remarked that in the 4. Injection situation, there would need to be an entire chain of circumstances leading to the critical error.Jan remarked that it is partially coverd by scenario 3.
The same applies to scenario 5.
Reliability Block Diagram
The slide explains the RDB methodology. .
Synchronous Beam Dump
The slide presents an RDB for a synchronous beam dump triggered by the BIS.
The discussion featured several points:
-
BETS tracks all the generators to be sure that they are within a certain tolerance - surveys all the generators, Q4 and septa magnets. Connected directly to the TSU
-
All of the BLMs are connected to the BIS, however the one BLM here might be not. It may be connected directly to the TSU only. Jan suggested assuming the one directly connected does not exist. Lukas remarked that we are more interested in critical systems connected to the TSU but not to the BIS.
-
SCSS (Slow Control PLC) is connected directly to the TSU and may also connected to the BIS ring. In SPS TSU is connected directly to the Ring BIS (forcing the BIS during the arming procedure), where it’s only used for ARMING. No direct link to the ring BIS from the SCSS. In LBDS we can add it - however Pieter says that it would be preferable to keep the architecture the same, and that it is not only SCSS - there are also other input channels (as the BETS).
- External TRIG LBDS used for “inject and dump” procedure. And for early dump in the SPS (dump issue via the timing). Standard Dump in the SPS issued by the BIS at the end of the flat top.
Generally it was concluded that it counts whether the upstream trigger is connected to the BIS or not, as only then CIBDS gets triggered. Hence, for async. dumps the two variants are considered.
TSU Interconnect
Nicolas explained that it is mostly done to check the syncronization between the two cards. If there is a problem, it will issue a trigger immediately.
Lukas asked about comparing the client status. Nicolas explained that it is not done now, but may be in the future for additional security. Pieter suggested that it should be done only if it’s necessary and could be one of the results of the analysis here. Nicolas agreed adding that it is only an additional client. Lukas concluded that we will compare the options.
New top-level failure mode
Nicolas explained the idea of an internal fault - if one of the TSU detects an internal dump, the other one sends synchronous BDT and asynchronous BDT. First one sends only asynchrony BDT. Normally, if there is only oneTSU with an internal fault, there is still an synchronous beam dump trigger. If both TSUs have an internal fault, there is a chance of an asynchronous trigger.
Next steps
Jan remarked that the TSU has its own IPOC - TSU IPOC which is the most important as it is looking at the redundancy on the TSU. Nicolas added that it is the Triggering Synchronization IPOC, all signals of the TSU output. Jan highlighted importance of checking if it covers the entire redundancy with Nicolas Magnian.
Pieter added that XPOC checks all kinds of sources. The check here is done by IPOC. However, he would like to follow up on exact actions which may be triggered from that check. He also stated that the LBDS IPOC samples the signal. When something goes bad, it will be seen there.
Lukas suggested to start the modeling by assuming that everything is checked after every dump request.
Regarding a possibly closer investigation of the LBDS power distribution, Nicolas said that the LBDS Power distribution reliability study has already been done. Jan confirmed that it has been looked at and that we should look at it as “if we lose power, then we dump”. Nicolas added that if we lose power for the TSU crate, then we have voltage surveillance via Slow Control and we will act. To be followed up. Lukas concluded that we focus on the beam dump function. Then we look into power distribution - with slightly lower priority.
Actions
- Nicolas V. will disucss with NM what kinds of checks we do in LHC and SPS.
- Prepare initial simulations with crude assumptions and study the results.
- Prepare model of LBDS power distribution