Author: Dworak, A.
Paper Title Page
TUPHA084 Decoupling CERN Accelerators 608
 
  • A. Dworak, J.C. Bau
    CERN, Geneva, Switzerland
  
  The ac­cel­er­a­tor com­plex at CERN is a liv­ing sys­tem. Ac­cel­er­a­tors are being dis­man­tled, up­graded or change their pur­pose. New ac­cel­er­a­tors are built. The changes do not hap­pen overnight, but when they hap­pen they may re­quire pro­found changes across the han­dling sys­tems. Cen­tral tim­ings (CT), re­spon­si­ble for se­quenc­ing and syn­chro­niza­tion of ac­cel­er­a­tors, are good ex­am­ples of such sys­tems. This paper shows how over the past twenty years the changes and new re­quire­ments in­flu­enced the evo­lu­tion of the CTs. It de­scribes ex­pe­ri­ence gained from using the CBCM CT model, for strongly cou­pled ac­cel­er­a­tors, and how it led to a de­sign of a new Dy­namic Beam Ne­go­ti­a­tion (DBN) model for the AD and ELENA ac­cel­er­a­tors, which re­duces the cou­pling, in­creas­ing ac­cel­er­a­tor in­de­pen­dence. The paper ends with an idea how to merge strong points of both mod­els in order to cre­ate a sin­gle generic sys­tem able to ef­fi­ciently han­dle all in­volved CERN ac­cel­er­a­tors and pro­vide more beam time to ex­per­i­ments and LHC.  
poster icon Poster TUPHA084 [0.477 MB]  
DOI • reference for this paper ※ https://doi.org/10.18429/JACoW-ICALEPCS2017-TUPHA084  
Export • reference for this paper using ※ BibTeX, ※ LaTeX, ※ Text/Word, ※ RIS, ※ EndNote (xml)  
 
TUPHA161 SIP4C/C++ at CERN - Status and Lessons Learned 785
 
  • S. Jensen, J.C. Bau, A. Dworak, M. Gourber-Pace, F. Hoguin, J. Lauener, F. Locci, K. Sigerud, W. Sliwinski
    CERN, Geneva, Switzerland
  
  A C/C++ soft­ware im­prove­ment process (SIP4C/C++) has been in­creas­ingly ap­plied by the CERN ac­cel­er­a­tor Con­trols group since 2011, ad­dress­ing tech­ni­cal and cul­tural as­pects of our soft­ware de­vel­op­ment work. A first paper was pre­sented at ICALEPCS 2013*. On the tech­ni­cal side, a num­ber of off-the-shelf soft­ware prod­ucts have been de­ployed and in­te­grated, in­clud­ing At­lass­ian Cru­cible (code re­view), Google test (unit test), Val­grind (mem­ory pro­fil­ing) and Sonar­Qube (sta­tic code analy­sis). Like­wise, cer­tain in-house de­vel­op­ments are now op­er­a­tional such as a Generic Make­file (com­pile/link/de­ploy), CMX (for pub­lish­ing run­time process met­rics) and Man­i­fest (cap­tur­ing li­brary de­pen­den­cies). SIP4C/C++ has in­flu­enced our cul­ture by pro­mot­ing in­te­gra­tion of said prod­ucts into our bi­na­ries and work­flows. We de­scribe our cur­rent sta­tus for tech­ni­cal so­lu­tions and how they have been in­te­grated into our en­vi­ron­ment. Based on tes­ti­mony from four pro­ject teams, we pre­sent rea­sons for and against adop­tion of in­di­vid­ual SIP4C/C++ prod­ucts and processes. Fi­nally, we show how SIP4C/C++ has im­proved de­vel­op­ment and de­liv­ery processes as well as the first-line sup­port of de­liv­ered prod­ucts.
*http://jacow.org/ICALEPCS2013/papers/moppc087.pdf, http://jacow.org/ICALEPCS2013/posters/moppc087_poster.pdf 		 
poster icon Poster TUPHA161 [0.781 MB]  
DOI • reference for this paper ※ https://doi.org/10.18429/JACoW-ICALEPCS2017-TUPHA161  
Export • reference for this paper using ※ BibTeX, ※ LaTeX, ※ Text/Word, ※ RIS, ※ EndNote (xml)