SwissFEL Controls Architecture

["White, Greg" <greg AT slac.stanford.edu>]

Colleagues,

Please find below a report on the SwissFEL Controls Architecture work, as
conducted in April. I have recently completed two documents that were
initiated as part of that work [1],[2], so it seemed appropriate to
summarize the effort in general.

This email summarizes the scope of the work, and gives references to the
existing outcome products.

The work was requested by Markus Janousch. It was worked on primarily
by *Elke* Zimoch, *Renate* Krempaska, *Leonardo* Sala, *Stephan*
Egli, *Sven* Reiche, *Timo* Korhonen, and me Greg White. Apart from the new
work on architecture specifically, the effort included documentation of the
data services support on which Timo and I had worked during the previous
year, and on Matlab online model system *Bolko* Beutner and I extended from
work by *Eduard* Prat Costa.

Primarily, first drafts of two principal documents, "SwissFEL Basic
Controls Architecture" [1], and "SwissFEL Basic Developers Guide" [2] are
now ready to use. (*Jan*, you now have a place to read about development
and deployment of EPICS V4 at PSI, including release escalation, source
control, and daemon management.)


CONTROLS ARCHITECTURE SCOPE AND WORK BREAKDOWN
==============================================
The SwissFEL Controls Architecture work covered the following primary areas:

i) Created a high level control systems software development environment.
This now includes the development and release escalation system for EPICS
V4 based services and matlab based applications. So, programming SwissFEL
scientific applications and data services can get started seriously

ii) Created and deployed initial data services in the environment so
designed, see CVS module G/SERVICES [5]

iii) Documented the software development and release process of the
environment, principles described in [1], and practical use in [2]
 
iv) Created a decision making framework, so new issues can be seriously
tackled and the outcome decisions can be assumed to have weight, see
Working Group Decision Making Framework in [3].

v) Agreed on the nominal host level data systems that will be key to
SwissFEL. This includes the plan for beam pulse identified image archival,
EPICS V4 data service for modelling, beam synchronous data, image
acquisition and image retrieval systems. Archive data retrieval and Oracle
data retrieval are already in place and follow the guidelines and
development environment described in i) above. See PDF slides [0] - the
outcome of talks between those named above. In particular see the last
slide, Decisions, which lists the important decision points that came out
of the outline architecture work. Those decisions should now be taken
formally and recorded

vi) Created a Documentation architecture. This is described below,
and *Stephan Egli* has agreed to take this further and generalize it to a
documentation architecture for large projects generally


DOCUMENTATION ARCHITECTURE
--------------------------

A significant part of this architecture effort was to design a
"documentation architecture" for SwissFEL controls and software systems.
That is, a recommendation and design for where documents should be stored.
Two principal locations were decided and developed:

1. The first is the SwissFEL Controls Architecture project coordination
space [3], under the SwissFEL project space in the PSI Intranet. It now
contains the high level, project oriented, material of the SwissFEL
architecture controls effort. It references and provides structure for
browsing and finding the relevant individual documents in Alfresco. In the
future I propose it should also contain roughly speaking those items in
which SwissFEL project management would be interested

2. The second is the SwissFEL architecture Alfresco space [4]. This where
individual documents will be stored. It presently contains the SwissFEL
Basic Controls Architecture Guide [1], and the SwissFEL Basic Controls
Developers Guide [2], and other documents produced so far

Note that most document themselves are mostly written in raw HTML, per the
decisions of the Architecture meetings of April. A simple style sheet to
help formatting, pagination, Table of Contents etc, has been included. This
provides a flexible and efficient platform for fast production of design
and programming documentation. A simple document version tracking pattern
is also evident, see the top of either [1] or [2]. A template document
helps new writers get started
 
Documentation systems performance:

The Controls Architecture work included work to analyze the retrieval time
performance of the various Wikis (PSI Intranet, Controls Wiki, Alfresco
wiki system) that could be used for SwissFEL controls and associated
documentation. Timing measurements were made of the various documentation
systems, both on and off campus through VPN. The results were not
encouraging. The systems intended for PSI general use were very slow
indeed, ranging from 6 to 45 seconds per simple page load of the relevant
wiki pages. These results were shared with Stefan Egli, and he has agreed
to look seriously at both specific wiki performance improvement, and more
generally to lead an effort to design guidelines for documentation
management.


CONCLUSION
----------

The development environment, EPICS V4 install, outline architecture,
decision framework, and documentation framework, seem enough to start to
effectively develop and deploy smart scientific data services for SwissFEL.
Two such services have already been deployed in the architecture - an EPICS
archived data retrieval service, and a general Oracle data retrieval
service (in CVS at [3]). Other such systems as beam pulse synchronous data,
synchronous magnet and rf control, etc should be planned, per the nominal
architecture in [0]. With these in place, writing the core FEL applications
for orbit display and fitting, wire scans, emittance estimation, beam
profile image acquisition and viewing, become easy. The nice development
environment will help in development of the other key apps, a general
purpose "scanning" and analysis app (called Correlation Plots at SLAC) in
particular. The overall framework was developed for host level systems
architecture, but could plainly also be used for low level EPICS controls
and photon diagnostics also.

Thank you very much indeed for hosting me to develop EPICS V4 and this
architecture framework. I hope very much to work with you all in the
future.

Greg White

REFERENCES
----------
[0] SwissFEL Controls Architecture In Outline, 
https://ecm.psi.ch/alfresco/d/d/workspace/SpacesStore/9d3376e7-0b23-4f38-a06d-26e4f7031aaf/SwissFELArchInOutline.pdf
[1] SwissFEL Basic Controls Architecture,
https://ecm.psi.ch/alfresco/webdav/Projects/SwissFEL/Facility/8430%20Controls/Architecture/SwissFEL_Basic_Controls_Architecture.html
[2] SwissFEL Basic Developers Guide,
https://ecm.psi.ch/alfresco/webdav/Projects/SwissFEL/Facility/8430%20Controls/Architecture/SwissFEL_Basic_Developers_Guide.html
[3] Project Level Architecture web page, 
https://intranet.psi.ch/Swiss_FEL/ControlsArchitecture 
[4] SwissFEL Architecture in Alfresco,
raw view; 
https://ecm.psi.ch/alfresco/n/browse/workspace/SpacesStore/80127168-064c-4edb-a748-4f3972d55231
"WebDAV" view; 
https://ecm.psi.ch/alfresco/webdav/Projects/SwissFEL/Facility/8430%20Controls/Architecture
Internet Filesystem view; 
smb://ecm.psi.ch/alfresco/Projects/SwissFEL/Facility/8430 
Controls/Architecture
[5] CVS of PSI EPICSV4 Channel Archive Service and Oracle RDB Service, 
http://www.sls.psi.ch/cgi-bin/cvsweb.cgi/G/SERVICES/
[6] SwissFEL Architecture document template, 
https://ecm.psi.ch/alfresco/d/d/workspace/SpacesStore/6df3b9fb-8abe-476f-93a8-ae899e28c68d/swissfeldoc_template.html