Abstract Every beamline is different, which makes it impossible to buy a control system off the shelf. Nevertheless well tested and customizable building blocks can be prepared, which are then put together according to customer requirements. Delivering a fully operational control system is not just software development, but also gathering specifications, writing documentation, testing the hardware and trimming the software on site. Based on the delivery of a number of working beamline control systems, this paper will prove that we have optimized all stages and can guarantee that the purchased control system will be delivered on time, will work according to specifications and will be properly documented. The customers can also count on support

G Pajor

I Verstovsek

M Kobal

P Medvescek

R Sabjan

CiteSeerX

PHOTON BEAMLINE CONTROL SYSTEM AS A PRODUCT  
M.Kobal, R. Sabjan, G. Pajor, I. Verstovsek, P. Medvescek  
Cosylab, Teslova 30, Ljubljana, Slovenia.  
 
Abstract 
Every beamline is different, which makes it impossible 
to buy a control system off the shelf. Nevertheless well 
tested and customizable building blocks can be prepared, 
which are then put together according to customer 
requirements. Delivering a fully operational control 
system is not just software development, but also 
gathering specifications, writing documentation, testing 
the hardware and trimming the software on site. Based on 
the delivery of a number of working beamline control 
systems, this paper will prove that we have optimized all 
stages and can guarantee that the purchased control 
system will be delivered on time, will work according to 
specifications and will be properly documented. The 
customers can also count on support.  
 
 
INTRODUCTION 
Cosylab has been producing control systems for 
beamlines since 2003. In this period, we have delivered 
control systems (CS) for 8 beamlines and are considered 
the leading company in the field [1].  
As with all things there can be a big difference between 
different control system solutions. It is one thing to 
implement the controls directly from the manual, while it 
is another when users are involved to tailor functionality 
which will make their work easier. To make the control 
system robust, significant amount of time must be spent 
on testing with hardware and modifying the CS to 
accommodate any hardware misbehaviour. A good CS 
must have machine protection capabilities and all 
subsystems must fit together. The code must be readable 
and configurable and documentation and support must be 
provided for the user to be able to modify or extend the 
system.  
After gaining technical experience with the first four 
beamlines, special emphasis was put on optimizing 
procedures for delivering CS service. We call it a service, 
since it is not just about software code, but also 
consultations, training, support and upgrades. The idea 
was to make all parts of the CS configurable and thus 
recyclable. By recycling components, we have reduced 
the effort for the last two CS by a factor of 3 compared to 
the first ones. This shows that Cosylab is now able to 
deliver state of the art CS with minimal effort. 
HISTORY 
 We have analysed already finished projects, to find 
where time can be saved and to learn how to predict effort 
and cost for future projects. We were not only interested 
in the total effort, but in the effort of individual tasks, 
which can differ significantly among projects (Figure 1). 
 
0
50
100
150
200
250
300
FDR DSGN SW QA DOC INT PM
MX (2005)
PX (2007)
PX2 (2008)
 
Figure 1: Effort in man days for different stages of 3 CS 
projects. FDR: final design review meetings. DSGN: 
design preparation. SW: software development. QA: 
quality assurance. DOC: documentation. INT: software 
integration with hardware. PM: project management. 
 
The first CS was developed for U55 beamline at 
University of Dortmund. It was a fairly simple CS with 
only individual motor motion control and was excluded 
from the analysis. 
 
Other CS included all the major beamline components 
and complex specifications. In all projects we have 
worked with hardware manufacturer Oxford-Danfysik 
(OD) [2] who was the main contractor. The scope of the 
first project (MX) was to deliver CS for 3 identical 
beamlines to DLS [3]. In the next two projects CS for PX 
and PD beamlines (PX) and for PX2 and SAXS/WAXS 
beamlines (PX2) at the ASP [4] were delivered.   
 
In case of MX specifications were prepared by OD and 
included practically all the functionality possible with 
existing hardware. Compromises were made with the 
customer in the design phase, which resulted in non 
Proceedings of PCaPAC08, Ljubljana, Slovenia THX02
Non-Technical Topics Standardization
221
optimal solutions and work a rounds were required at later 
stages. Due to hardware delays, software was integrated 
together with hardware fixing, which resulted in longer 
integration times. Since it was not obvious how much of 
additional effort was influenced by hardware delays, 
management effort is also higher compared to the other 
two projects. It should be noted that the estimated time for 
the project was 3 times underestimated mostly due to 
significantly longer integration. 
In the course of MX, we have learned several lessons:  
• Management procedures and interactions need to 
be explicitly defined. 
• Specifications need to be communicated directly 
with the final customer. 
• Scope needs to be well defined and all changes 
need to be tracked.   
• Hardware needs to be available during software 
development.  
• The effort was significantly larger that previously 
envisaged. 
 
Applying lessons learned to PX, resulted in reducing 
management effort from 100 man days (md) in case of 
MX to 40 md in case of PX. Better procedures for 
tracking progress and changes resulted in less friction 
between the companies.  
By using the actual MX effort for PX effort predictions, 
PX went only 30% over budget with most of the budget 
over runs attributed to making CS building blocks 
recyclable and thus paving the way for future projects. 
Since different hardware was used for PX as for MX, 
most of the design and software code needed rewriting. 
Therefore similar amount of effort was required for stages 
before integration.  
In contrast to MX where CS for 3 identical beamlines 
was delivered, the 2 beamlines of the PX project were 
significantly different. This resulted in 30 % to 40 % 
integration effort increase, compared to MX where no 
significant effort increase was observed. If we take this 
into account, the integration time in case of PX was 
reduced from 130 md at MX to 80 md. Two additional 
integration visits were required at PX due to hardware 
delays. 
For PX2 the similar hardware as for PX was used. 
Specifications and design work was striped down to 
revising the PX documents. Since we had future projects 
in mind when developing PX software modules, all PX 
modules could be reused with different configuration 
parameters. The time spent for software was mostly 
adding modules for hardware not already supported. As 
for the other two projects, quality assurance for new 
building blocks was around 25% of software development 
effort. Since the hardware was well prepared for software 
integration, the integration time was reduced by 25%. 
After the last project it is safe to say that Cosylab has 
well defined procedures, which allow reduction of effort 
for CS development to a minimum.  
 
 
CONTROL SYSTEM PRODUCTION 
CYCLE AT COSYLAB 
 
Control system production cycle at Cosylab comprises 
the following phases: 
1. Specifications 
2. Design and Prototyping  
3. Implementation/Test procedures/Documentation 
4. Integration/Testing/Debugging 
5. Customer acceptance 
 
First specifications need to be defined. It is very 
important to include the final user in the process of 
making specifications. In this way developers get to 
understand user needs, while users get a glimpse of what 
the CS will look like. Without detailed specifications, 
design changes might be required at a later stage, which 
can significantly increase effort and consequently friction 
between the developers and users. It is easy to spend a 
couple of weeks for specifications or even more in case of 
first time users.  
 
After specifications are confirmed by users, the Design 
and Prototyping phase can start. CS for a beamline is 
complex enough that a bad design can lead to significant 
problems at implementation stage or when additional 
features are required at the end. It is essential that design 
is confirmed with hardware in the prototyping phase. 
Since Cosylab has experience in a number of solutions 
currently used in accelerators worldwide, the 
Design/Prototype phase can be reduced to below a week, 
although it can take several weeks otherwise. 
 
The CS design is usually modular. Some modules need to 
be developed, while others can be found in accelerator 
community. Unless you are really familiar with the 
existing module or no modifications are required, not 
much time is saved by using existing modules. Producing 
all the modules for a beamline with testing and 
accompanying documentation takes around 200 md, 
where around 40 % are spent for motor controls. At 
Cosylab we have developed a number of modules that can 
cover most of the beamline components. In addition to the 
software code, test procedures, user manual and technical 
manual are also part of the module. By deciding to use 
Cosylab standard modules, this phase can be avoided 
entirely. 
 
After all modules are developed, they must be put 
together and configured for particular hardware. The 
integration of modules into CS software is done 
automatically from an Excel spreadsheet [5]. User 
documentation and technical documentation are also 
automatically generated from templates pertaining to 
different modules. It takes a couple of days to build the 
CS software and check module configuration. 
 
THX02 Proceedings of PCaPAC08, Ljubljana, Slovenia
Non-Technical Topics
222
Standardization
Although individual modules have already been tested on 
test systems, tests with the actual hardware need to be 
made. The modifications in this stage are usually not 
made in the module code, but in the configuration 
parameters, which need to fit the actual hardware. Apart 
from insuring that the software is properly configured, 
also problems with the hardware can be detected.  
 
Before handing over the beamline to the final customer, it 
is ensured that the CS passes all the test procedures. 
Although the test procedures are updated to detect all 
known bugs, a 1 year warranty is given to the customer to 
report bugs. Current experience shows that after the 
commissioning phase when some configuration 
parameters need tuning, no problems are reported. 
 
 
 
CONTROL SYSTEM PRODUCTS 
All control systems delivered by Cosylab are of the 
highest standards. They range from CS build from 
standard modules to fully customizable solutions.  
 
Our standard CS solution is based on EPICS and is 
optimized for FMB-Oxford hardware. If the standard 
solution is selected, the only effort required is to 
configure the CS and integrate it with hardware. In this 
case around 50 man days are estimated and would be 
mostly spent on integration (PROD 1 in Figure 2). The 
customer does not need to be involved in any stage of the 
project. 
 
0
20
40
60
80
100
120
140
160
PROD 1 PROD 2 PROD 3 PROD 4 PROD 5
Design
Development
Integration
 
Figure 2: Estimated effort in man days for different CS 
products depending on the required customization. 
 
In most cases some development work is required even if 
FMB-Oxford hardware is selected. Let us assume a 
couple of serial devices need to be supported and some 
additional features are required for the DCM. The 
development work would take around 20 man days and 
there would be also additional effort of around 10 man 
days at integration. Customer involvement is still not 
required and the total estimated time in around 80 md 
(PROD 2 in Figure 2). 
 
Since Cosylab has extensive knowledge in hardware used 
in various accelerator facilities, even if selecting hardware 
not included in the standard solution, no learning effort is 
required. Still significant software development and 
additional integration time is required to bring the CS to 
desired standards. A rough estimate to provide CS with 
hardware outside the standard solution is 140 md (PROD 
3 in Figure 2) and 230 md if also motor controls need to 
be developed (PROD 4 in Figure 2). If the customer 
wants to be highly involved in specifications and design 
phase, an extra 20 md are easily spent (PROD 5 in Figure 
2).  
 
CONCLUSIONS 
Cosylab has the experience to produce state of the art 
control systems for photon delivery beamlines. Since 
emphasis was taken to make control system building 
blocks recyclable, a state of the art control system can be 
produced with minimal effort.  
 
Software development work accounts for around 50 % 
when producing the first control system. Effort required 
for consecutive control systems can be significantly 
reduced, if modules are properly designed. By using 
standard well tested modules, Cosylab has reduced total 
effort by a factor of 5 compared to the first delivered 
photon delivery beamline control system. 
.  
Apart from providing control systems with standard 
modules, Cosylab can deliver also fully customizable 
control systems. Due to experiences with control system 
solutions used in accelerator facilities world wide, the 
customer is ensured that the control system is developed 
in a most effective way. 
 
From our experience, it is very difficult to properly 
estimate control system production effort before actually 
delivering a fully functioning control system. This has 
mostly to do with time spent to achieve optimal 
compatibility with hardware. Cosylab has now enough 
experience to estimate production effort within a 10% 
margin. 
 
 
REFERENCES 
[1] http://www.cosylab.com/info/references/. 
[2] FMB-Oxford, http://www.fmb-oxford.com. 
[3] Diamond Light Source, http://www.diamond.ac.uk. 
[4] Australian Synchrotron Project,  
 http://www.synchro tron.vic.gov.au. 
[5] G. Pajor et. al., 
”
Systematic production of beamline 
and other turnkey control systems”, ICALEPCS07. 
 
 
Proceedings of PCaPAC08, Ljubljana, Slovenia THX02
Non-Technical Topics Standardization
223


PHOTON BEAMLINE CONTROL SYSTEM AS A PRODUCT

http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=4A33B8A1C50C8E09F2BE2DA5F6C84B84?doi=10.1.1.1042.3252&rep=rep1&type=pdf

PHOTON BEAMLINE CONTROL SYSTEM AS A PRODUCT

Abstract

Similar works

Full text

Available Versions

CiteSeerX