Status of the Interface Documents with Other Consortia Marco Verzocchi - Fermilab Cold Electronics Workshop – Brookhaven National Laboratory 18 July 2018
What is an interface document ? M. Verzocchi | Status of the Interface Documents with Other 2 18 Jul 18 Consortia
What is an interface document ? • So far documents written by one group, checked / edited by second group, some minimal review by technical coordination (comments by Terri Shaw & Farshid Feyzi) • We’ve done at least two iterations on all documents, but the amount of review (by consortia members, by technical coordination, by other people in DUNE) is still pretty limited • In principle we should start putting these documents under formal approval / revision control this Summer • I will refuse to sign any CE interface document and make them official until I see certain things implemented in other interface documents (for example CISC-DAQ) because I think that the experiment design is still too vague and that CE could suffer as a consequence of other poorly drafted documents - Refusing to sign documents is the only weapon I have, I am trying to point out where I see problems - You can also help by looking at multiple interface document and spotting inconsistencies M. Verzocchi | Status of the Interface Documents with Other 3 18 Jul 18 Consortia
What is an interface document ? • An interface document should be a living document • When our understanding of how the detector is built and how it should be operated improves, this should be reflected in the interface document • When something has been done (for example APA and CE should together decide on X, design Y), this task should be removed from the interface document or marked as “DONE” • Interface document should not just be verbal: technical drawings, pieces of code could also be included if appropriate (in some cases that is the real interface) • I prefer to have a TODO list in the interface documents to highlight areas that are still in need of discussion M. Verzocchi | Status of the Interface Documents with Other 4 18 Jul 18 Consortia
Evolution from protoDUNE • Fewer interface documents for protoDUNE • In some cases the reason was “Bo is going this for both consortia, he doesn’t need an interface document” • Going forward, this may still be the case in case the responsibility for certain items is reassigned to a different group M. Verzocchi | Status of the Interface Documents with Other 5 18 Jul 18 Consortia
How Technical Coordination sees them (i) • Interface control drawings vs consortia drawings • Engineering drawings and documents that are specific to consortia are controlled by consortia • Fundamental dimension and parameters are documented in interface control drawings and maintained by technical coordination • A team from by TC and consortia will manage drawings • Central repository has not been defined yet • Design Review Process • Design reviews are responsibility of consortia at the 30% and 60% levels with TC participation • Design reviews at the 90% level and for pre-production are responsibility of TC • TC will include subject matter experts to review engineering analyses • Design review process and deliverables under development M. Verzocchi | Status of the Interface Documents with Other 6 18 Jul 18 Consortia
How Technical Coordination sees them (ii) • Drawings are 2d projections with dimensions in projection plane • 2d integration drawings are controlled by TC • Only dimensions that are strictly shown are controlling • All dimensions need a reference which is a controlled document • 3d model files by consortia or TC are supporting and must agree with 2d drawings • Decide on interface planes and dimensions and keep them • Tolerances are minus, not plus • Do not reserve space by increasing dimensions • Gaps belong to technical coordination • Regular verification M. Verzocchi | Status of the Interface Documents with Other 7 18 Jul 18 Consortia
A few comments • These are the rules for mechanics, hopefully for electronics we can work with Terri to develop more reasonable rules • Fortunately we don’t deal (much) with mechanics • While I can agree with a lot of what Farshid recommends on envelopes, not having a central repository for CAD drawings is completely crazy • If this continues, we should agree to use EDMS at CERN • It is there, it works, we can use it • I would prefer to have central repository for all drawings and bill of materials for all detector components. I will not be there in 2055 to dismantle and recycle the detector ? Or is the plan just to let the cavern flood and possibly pollute the water ? • The DØ detector will never be dismantled because a) it costs too much, and b) the people who know how it was built are now almost all out of the game • Since I like evil plans, I try to squeeze these recommendations in certain interface documents M. Verzocchi | Status of the Interface Documents with Other 8 18 Jul 18 Consortia
How many interface documents ? • There are at least 11 interface documents between the CE consortium and other consortia / groups • Some have gone through a couple of iterations, others are still missing M. Verzocchi | Status of the Interface Documents with Other 9 18 Jul 18 Consortia
APA Consortium • Document (DocDB 6670) last updated in May • Some have gone through a couple of iterations, others are still missing • Mostly based on discussions with Alberto Marchionni, need to make sure that the document is reviewed by their engineers • Pretty detailed for where we are now, but need to evolve with drawings (CR-FEMB connection, cable routing, cable clamps) and more details for the integration, installation, and testing activities • And we need to agree that there is work needed on understanding failures of individual channels and whether these are related in any way to the connection between boards M. Verzocchi | Status of the Interface Documents with Other 10 18 Jul 18 Consortia
DAQ Consortium • Document (DocDB 6742) last updated in May • So far we have focused on one issue (link between WIB and CUC), discussed briefly a second (clock distribution), and then realized that there is much more to be discussed • In writing the interface document with Software and Computing I’ve realized that there are parts that actually belong to the interfaces with DAQ and CISC (to be discussed) • Need to define the data format, need to finalize (by the TDR) decision on the link speed and the fibre plant, how to synchronize, how to handle calibration, ….. • Lots of room for more discussion, more details in the interface document M. Verzocchi | Status of the Interface Documents with Other 11 18 Jul 18 Consortia
CISC Consortium • Document (DocDB 6745) last updated in May • Will probably undergo a significant revision following meeting of Technical Coordination with DAQ, CISC, Software and Computing, Cold Electronics (because we are trouble maker) • I have three worries - Other consortia seems to think that there is no need to plan for systems for the ITF • The ITF should be the final dress rehearsal for SURF. Everything should be of the same quality Telling me that “we should have the system in time” is not the answer, it should be a • deliverable of the CISC / DAQ consortia - Boundary between DAQ and CISC responsibilities on run control, detector configuration, online monitoring - Hardware interlock system (I want one as good as the one used in ATLAS/CMS, I don’t want software interlocks that will not work if the DAQ or the CISC are down) • All systems are as good as they are built, but hardware interlocks generally work better than software ones M. Verzocchi | Status of the Interface Documents with Other 12 18 Jul 18 Consortia
HV Consortium • Document (DocDB 6739) last updated in May • Needs to evolve with drawing and probably more details about testing during the detector installation - HV wants to do some tests and we (and APA, possibly PD) should profit by doing other tests at the same time (no access in the cryostat, check for shorts when ramping HV, RF shielding) M. Verzocchi | Status of the Interface Documents with Other 13 18 Jul 18 Consortia
PD Consortium • Document (DocDB 6718) last updated in May • We share the chimney and most probably we (CE) will have to take some responsibility for the cabling of the PD (reduce personnel in the cavern) • Interface quite detailed, our main worry is that PD respects all the grounding rules and that we have sufficient testing to demonstrate that there is no cross-talk between the two systems • We are going to follow certain rules for the design and test of electronics, how do we ensure that PD follows the same rules ? Do we need to put this explicitly in the interface documents (for example: design to avoid hot carrier effect, measurements of lifetime of components….) M. Verzocchi | Status of the Interface Documents with Other 14 18 Jul 18 Consortia
Recommend
More recommend
