1st Developers@CERN Forum

FESA is a framework used by 100+ developers at CERN to design and implement the real-time software used to control the accelerators. Each new version must be tested and qualified to ensure that no backward compatibility issues have been introduced and that there is no major bug which might prevent accelerator operations. Our quality assurance approach is based on code review and a two-level testing process. The first level is made of unit-test (Python unittest & Google tests for C++). The second level consists of integration tests running on an isolated test environment. We also use a continuous integration service (Bamboo) to ensure the tests are executed periodically and the bugs caught early. In the presentation, we will explain the reasons why we took this approach, the results and some thoughts on the pros and cons

Solving the Synchronization Problem in Multi-Core Embedded Real-Time Systems

Multi-core CPUs have become the standard in embedded real-time systems. In such systems, where several tasks run simultaneously, developers can no longer rely on high priority tasks blocking low priority tasks. In typical control systems, low priority tasks are dedicated to receiving settings from the control room, and high priority real-time tasks, triggered by external events, control the underlying hardware based on these settings. Settings' correctness is of paramount importance and they must be modified atomically from a real-time task point of view. This is not feasible in multi-core environments using classic double-buffer approaches, mainly because real-time tasks can overlap, preventing buffer swaps. Other common synchronization solutions involving locking critical sections introduce unpredictable jitter on real-time tasks, which is not acceptable in CERN's control system. A lock-free, wait-free solution to this problem based on a triple buffer, guaranteeing atomicity no matter the number of concurrent tasks, is presented. The only drawback is potential synchronization delay on contention. This solution has been implemented and tested in CERN's real-time C++ framework

Distributed Transactions in CERN’s Accelerator Control System

Devices in CERN’s accelerator complex are controlled through individual requests, which change settings atomically on single Devices. Individual Devices are therefore controlled transactionally. Operators often need to apply a set of changes which affect multiple devices. This is achieved by sending requests in parallel, in a minimum amount of time. However, if a request fails, the Control system ends up in an undefined state, and recovering is a time-consuming task. Furthermore, the lack of synchronisation in the application of new settings may lead to the degradation of the beam characteristics, because of settings being partially applied. To address these issues, a protocol was developed to support distributed transactions and commit synchronisation in the CERN Control system, which was then implemented in CERN’s real-time frameworks. We describe what this protocol intends to solve and its limitations. We also delve into the real-time framework implementation and how developers can benefit from the 2-phase commit to leverage hardware features such as double buffering, and from the commit synchronisation allowing settings to be changed safely while the accelerator is operational

SIP4C/C++ at CERN - Status and lessons learned

After 4 years of promoting the Software Improvement Process for C/C++ (SIP4C/C++) initiative at CERN, we describe the current status for tools and procedures along with how they have been integrated into our environment. Based on feedback from four project teams, we present reasons for and against their adoption. Finally, we show how SIP4C/C++ has improved development and delivery processes as well as the first-line support of delivered products.A C/C++ software improvement process (SIP4C/C++) has been increasingly applied by the CERN accelerator Controls group since 2011, addressing technical and cultural aspects of our software development work. A first paper was presented at ICALEPCS 2013*. On the technical side, a number of off-the-shelf software products have been deployed and integrated, including Atlassian Crucible (code review), Google test (unit test), Valgrind (memory profiling) and SonarQube (static code analysis). Likewise, certain in-house developments are now operational such as a Generic Makefile (compile/link/deploy), CMX (for publishing runtime process metrics) and Manifest (capturing library dependencies). SIP4C/C++ has influenced our culture by promoting integration of said products into our binaries and workflows. We describe our current status for technical solutions and how they have been integrated into our environment. Based on testimony from four project teams, we present reasons for and against adoption of individual SIP4C/C++ products and processes. Finally, we show how SIP4C/C++ has improved development and delivery processes as well as the first-line support of delivered products

High Risk of Anal and Rectal Cancer in Patients With Anal and/or Perianal Crohn’s Disease

International audienceBackground & AimsLittle is known about the magnitude of the risk of anal and rectal cancer in patients with anal and/or perineal Crohn’s disease. We aimed to assess the risk of anal and rectal cancer in patients with Crohn’s perianal disease followed up in the Cancers Et Surrisque Associé aux Maladies Inflammatoires Intestinales En France (CESAME) cohort.MethodsWe collected data from 19,486 patients with inflammatory bowel disease (IBD) enrolled in the observational CESAME study in France, from May 2004 through June 2005; 14.9% of participants had past or current anal and/or perianal Crohn’s disease. Subjects were followed up for a median time of 35 months (interquartile range, 29–40 mo). To identify risk factors for anal cancer in the total CESAME population, we performed a case-control study in which participants were matched for age and sex.ResultsAmong the total IBD population, 8 patients developed anal cancer and 14 patients developed rectal cancer. In the subgroup of 2911 patients with past or current anal and/or perianal Crohn’s lesions at cohort entry, 2 developed anal squamous-cell carcinoma, 3 developed perianal fistula–related adenocarcinoma, and 6 developed rectal cancer. The corresponding incidence rates were 0.26 per 1000 patient-years for anal squamous-cell carcinoma, 0.38 per 1000 patient-years for perianal fistula–related adenocarcinoma, and 0.77 per 1000 patient-years for rectal cancer. Among the 16,575 patients with ulcerative colitis or Crohn’s disease without anal or perianal lesions, the incidence rate of anal cancer was 0.08 per 1000 patient-years and of rectal cancer was 0.21 per 1000 patient-years. Among factors tested by univariate conditional regression (IBD subtype, disease duration, exposure to immune-suppressive therapy, presence of past or current anal and/or perianal lesions), the presence of past or current anal and/or perianal lesions at cohort entry was the only factor significantly associated with development of anal cancer (odds ratio, 11.2; 95% CI, 1.18-551.51; P = .03).ConclusionsIn an analysis of data from the CESAME cohort in France, patients with anal and/or perianal Crohn’s disease have a high risk of anal cancer, including perianal fistula–related cancer, and a high risk of rectal cancer