Control Sheet Cosylab’s Newsletter

Volume 27 ISSN: 1855-9255

Cosylab d.d., Teslova ulica 30, SI-1000 Ljubljana, SLOVENIAPhone: +386 1 477 66 76 Email: controlsheet@cosylab.com URL: www.cosylab.com

June 2016Table of Contents

3

2

11

6

Are there major trends and insights in Big Physics machine integration projects?This issue features the second in our Cosylab Experts series of articles. In this article, Rok Hrovatin looks at where there are major trends and insights in Big Physics machine integration projects.

FAQ: What is the maximum allowed length of an EPICS record name?A recurring question in all EPICS-based control system projects is: “What is the maxi-mum allowed length of an EPICS record name?” We look at the factors that contribute to the answer.

Integration of the Raspberry Pi NoIR Camera into EPICSStudent project using the Raspberry Pi and its camera for area detection with EPICS.

Web Browser

RESTful API

Input/Output Controller

(IOC)

Camera API and Hardware

Client Device Raspberry Pi

Network

The Picture BoardFeaturing some snapshots from PTCOG55 in Prague, Czech Republic and the 2016 Sci-ence Festival in Ljubljana, Slovenia.

9 Site Independent EPICS IOC SoftwareAutomation to simplify and speed up installation and maintainenance of several ver-sions of EPICS IOCs, which essensially control devices of the same type.

SITE DESCRIPTION

EPICS CONFIGURATION MANAGEMENT

TOOL

SITE CONFIGURATION

site description file additional

configuration files

EPICS IOC configuration

CSS screens configuration

Additional plugins

EPICS database substitution files

IOC initialization routines

CSS operator screens

Volume 27 Control Sheet ISSN: 1855-9255

2page:

As Big Physics machines are built to push the very boundaries of science, one can expect it to be a field of constant tech-nological innovation and evolution. Does that also imply the same dynamics apply to the systems engineering and integra-tion aspects of these projects?

My first observation is this: if there are to be major trends, they are not necessar-ily obvious to the naked eye. The archi-tectures of these projects crystallize over long periods of time and the endeavors themselves are large and multifaceted. In the open (source) scientific community, there is a lot of cross-fertilization of new ideas as well as reuse of proven concepts and recipes. So, to use a metaphor, if there are trends, they are to be spotted from a high, 40000 ft perspective, with a view of the entire field ranging from fundamental accelerator-based big physics research, to applied research and adjacent fields like astronomy and even to non-research ap-plications such as proton therapy.

At Cosylab, we have a “finger on the pulse” with respect to what is happening across the entire field of accelerator systems en-gineering, giving us an eagle-eye view, so to speak. Let us share some of the trends and ensuing insights we’re discovering.

Are there major trends and insights in Big Physics machine integration projects?

Looking further than the “close neighbor” projects for commonalityAt first glance, one would not expect sig-nificant commonality in system require-ments between, for example, an archiving system for a radio telescope and that for a large accelerator, yet there are. Further-more, these system requirements, at the implementation level, also share many de-tails in solutions that can be reused from “one world to the other”.

As a result, it is definitely worthwhile to look beyond projects of similar machine types for proven chunks of software (frameworks, applications, … ). Exactly

what you need may lay hidden in places where you don’t expect to find it

Related to this insight is the trend of fewer developments from scratch and increased reuse of frameworks. It allows solutions from not-so-related projects to be more easily integrated. Hence the advice: think twice (and look around) before you de-cide that your system requirements justify large custom developments. Adaptations of existing systems might well be the more rational decision.

Documentation gains importancePostponing writing the documentation to a later point in the project (some develop-ers hope for and infinite postponement!) is a practice that is less and less accept-able in accelerator integration projects. There are a few possible explanations. First, there’s a certain maturation and pro-fessionalization of the discipline where the non-functional requirement of main-tainability together with the ability to deal with personnel changes is acknowledged at the start of the project. Secondly, more research machines are built with an im-portant medical component: for research in Proton and Carbon-ion therapy. To pre-pare the technology to spin-off to actual patient treatment requires that it is certi-fiable, with the imposed documentation requirements. Thirdly, recent dramatic in-creases of accelerators being built purely

Cosylab is the world leader in big physics control systems with experts who have a vast experience gained over the years by working on a variety of differ-ent projects. It is our mission to help labs and people with their control system challenges, whatever these may be.

Rok Hrovatin has visited numerous accelerator laboratories around the world and these experiences have put him in a position to have a big-picture view of the field.

In this article, Rok shares some of his insights.

Rok Hrovatin

Cosylab Experts

Volume 27 Control Sheet ISSN: 1855-9255

3page:

Rok Hrovatin, Ph.D., Rok’s basic education was in Me-chanical Engineering, but he finally saw the light and headed down the Physics path. In 1995, Rok graduated with a Ph.D. in Technical Sciences with his thesis focus-sing on the optodynamic characterization of the inter-action of laser pulses with matter. Thereafter, Rok joined a development team in industry, where he worked on an ultrasonic gas meter. At the same time, he completed his MBA. He next worked at an institute for quality and metrology where he managed several test labs. His in-dustrial development experience continued with optical incremental encoders, while his next step brought him to particle accelerator instrumentation.

Rok joined Cosylab in the very beginning of 2015 and is able to apply his vast experience gained in industry and in the quality and standards arena to identify appropri-ate control system solutions for unique problems in the world of particle accelerators and big physics.

In his free time, Rok enjoys running, working around his house, long motorbike journies, kayaking, sailing and cycling. He feels that his leisure time is always too short, but he always enjoys whatever free time he has. He pre-fers wine over beer and sausages over foie gras. Most of all he likes spending quality time with his grandson.

ABOUT THE AUTHORfor Proton Treatment means a shift in the direction towards medical applications of the accelerator systems “market” as a whole. Medical devices require a consid-erable, often underestimated, quantity of documentation. The documentation, be-sides demonstrating or testing a working software system, also serves as a proof of compliance of a software system. In this, not only the end product (software sys-tem) is considered, but due to its com-plexity, also the (documented) develop-ment processes. This is mandated by medical standards (ISO 13985, IEC 62304)

A collaboration of many parties: administrative headache?The last trend that I would like to raise is that the number of independent par-ties in any project is increasing. Few large projects are still started and funded in a monolithic way, with the aim to produce as much of the technology as possible in-house, but rather the direct opposite is becoming more common. These collabo-

rations can become quite complex, es-pecially with international collaborations that have many in-kind contributions. An insight we’d like to share here is that system architects and project managers tend to underestimate the pure admin-istrative hurdles they’ll encounter when bringing innovative (novel) systems to-gether. An institute’s purchasing depart-ment has processes and policies in place, undisputedly for a good reason. Only, they differ between institutes and as such are not easily understood by all involved par-ties. This can cause serious project delays that in hindsight turn out easily avoid-able, simply by addressing them early. The simple message here is: pay attention to figuring out relevant purchasing policies, legal frameworks, local tendering process specificities. Involve the administration people early!

If you would like to discuss any of these insights further, feel free to check with your Cosylab contact or contact me at rok.hrovatin@cosylab.com.

FAQ: What is the maximum allowed length of an EPICS record name?

A recurring question in all EPICS-based control system projects is: “What is the maximum allowed length of an EPICS record name?” We look at the factors that contribute to the answer.

by: Miha Vitorovič (Cosylab)

IntroductionIn all EPICS-based control system projects, a recurring question is: What is the maxi-mum allowed length of an EPICS record name? This question is very popular, es-pecially in the early stages of the project, when the naming convention policy is de-fined. Searching the Tech-talk mailing list shows that this question is quite regular there as well.

And as with many such questions it has a few answers, and we often hear all of them:

◊ “It depends” – always an easy and cor-rect answer :),

◊ Sometimes you hear answers like “28 characters” or “40 characters”,

◊ “60 characters” is the answer for newer EPICS systems.

In this article, we will explore this question

and give the real answer, but unfortunate-ly the real answer will not turn out to be a single number.

PV Name, Record Name, Database and Channel Access LinksBefore we look at the answers and back them up with some experiments, let’s first take a little time to define what exactly dif-ferent terms mean.

Volume 27 Control Sheet ISSN: 1855-9255

4page:

Record NameA record name is the name of the record in the EPICS database. It is the name that you specify in VisualDCT or directly in the EPICS DB file.

Process Variable NameEPICS records often need values from oth-er records in the database. The reference to these other values is called a Process Variable (PV), and it contains the record name, but may also be extended with the specific field in a record. We can see three such fields in the examples in Figure 1 (VAL, INP and DESC). In the PV, the field name is separated from the record name with a dot. For example the PV names in Figure 1 are:

◊ Direction.VAL

◊ Direction.INP

◊ Direction.DESC

◊ Direction

As we can see, even the record name by itself is also a PV name. In this case, the field VAL is implied. By convention, fields are given names of 4 characters or less, so a PV name may be up to 5 characters (including the dot) longer than the re-cord name.

Database and Channel Access LinksDatabase links and Channel Access links reference PV names and consist of the target PV name plus 2 optional flags sepa-rated by white spaces. These 2 flags may be one of these:

◊ Process Passive flags

• NPP (default if no Process Passive flag is specified)

• PP

record(ai, “Direction”) { field(VAL, “1.0”) field(INP, “Calc:Direction”) field(DESC, “The direction of the calculation.”)}

Figure 1: VisualDCT and EPICS DB file showing a record named Direction.

• CA

• CP

• CPP

◊ Maximize Severity flags

• NMS (default if no Maximize Severity flag is specified)

• MS

• MSS

• MSI

An example of a CA link value might be:

“Direction.DESC CPP NMS”

This extends the PV name by a maxi-mum of an additional 8 characters.

Exploring the LimitsEquipped with all this information, let’s test the behavior of the EPICS database. For this, we will use a simple database that cycles a value between -1 and 1. We can see the sample database in Figure 2.

The limit for the record name in the cur-rent EPICS version (3.15.3) is 60 characters. Let’s change the name of the record In-put:1 to something longer like A:Variable:That:Changes:Its:Value:From:Zero:To:One::In:Steps which is exactly 60 characters long. Our new database is shown in Figure 3 and we

added the flags to the links while we were at it.

Loading this database still produces a working application (Figure 4), so the da-tabase limits were not reached for any of the fields.

So, let’s inspect the database in some greater detail (Figure 5).

Uh-oh. It seems we have encountered one of the legendary limits mentioned in the introduction. Both EPICS IOC and the caget tool use the EPICS DBR_STRING type to return the value, and this is lim-ited to 40 characters. So the value of the field itself is not affected, but when we use the available tools to read the value of the FLNK field, the returned value gets trun-cated to 40 characters.

We may get into even more trouble if we try setting FLNK field using the caput tool (Figure 6).

The default behavior in Figure 6 will set the value of the PV using a DBR_STRING type. This causes problems.

Luckily, most EPICS tools have, for a long time, implemented an extension that helps us get around this limitation. End-ing the PV name with the $ character tells the client to use the value as an

record(ai, “Input:1”) { field(VAL, “0.0”) field(INP, “Calc:1.VAL”)}

record(calc, “Calc:1”) { field(SCAN, “.5 second”) field(CALC, “A>0.9?-1.0:A+0.1”) field(INPA, “Input:1”) field(FLNK, “Input:1”)}

Figure 2: A sample database

Volume 27 Control Sheet ISSN: 1855-9255

5page:

need to be extra careful when changing the value of the DBR_LINK fields.

record(calc, “Calc:1”) { field(SCAN, “.5 second”) field(CALC, “A>0.9?-1.0:A+0.1”) field(INPA, “A:Variable:That:Changes:Its:Value:From:Zero:To:One::In:Steps.VAL”) field(FLNK, “A:Variable:That:Changes:Its:Value:From:Zero:To:One::In:Steps”)}

record(ai, “A:Variable:That:Changes:Its:Value:From:Zero:To:One::In:Steps”) { field(VAL, “0.0”) field(INP, “Calc:1.VAL”)}

Figure 3: The sample database with a long record name

$ camonitor Calc:1Calc:1 2016-04-22 11:27:19.584635 0.7 Calc:1 2016-04-22 11:27:20.085292 0.8 Calc:1 2016-04-22 11:27:20.584780 0.9 Calc:1 2016-04-22 11:27:21.085298 1 Calc:1 2016-04-22 11:27:21.585039 -1

Figure 4: Results of running application in database from Figure 3

############################################################################## EPICS R3.15.3 $Date: Sun 2015-11-22 17:54:12 +0100$## EPICS Base built Apr 20 2016############################################################################iocRun: All initialization complete## Start any sequence programs#seq sncExample, “user=miha”epics> dblCalc:1A:Variable:That:Changes:Its:Value:From:Zero:To:One::In:Stepsepics> dbgf Calc:1.FLNKDBR_STRING: “A:Variable:That:Changes:Its:Value:From” epics>

$ caget Calc:1.FLNKCalc:1.FLNK A:Variable:That:Changes:Its:Value:From

Figure 5: Using caget

array, not as a DBR_STRING which is limited to 40 characters (this extension also works in CS-Studio) (Figure 7).

The –S parameter instructs the CA tools that the array value will be specified/dis-played as a string (not as a sequence of numbers).

NOTE: The PV parameter of all the CA tools (caget, caput, camonitor) has a very high limit and will support future ex-tensions well beyond the current 60 char-acter limit.

A final word on the limitsSo, can you always use more than 28 char-acters for naming records? It depends. If you know that all your IOCs run EPICS ver-sion 3.14.1 or newer, then yes. If you have a mixed EPICS environment and some of your IOCs are older than that, than the record name limit on those systems is 28 characters. You can still use longer names, but you have to be sure they will not need to be used on older IOCs. But if you use names longer than 40 characters you

Miha Vitorovič is a Senior Software Developer at Co-sylab. He has a background in Computer Science and is currently Project Manager for the Data Management system for ESS, that is responsible for delivery of the Ma-chine configuration, naming, cabling and lattice appli-cations. In his free time, Miha enjoys spending time with his family, hiking and enjoying the mountains.

ABOUT THE AUTHOR

Volume 27 Control Sheet ISSN: 1855-9255

6page:

$ caput Calc:1.FLNK “A:Variable:That:Changes:Its:Value:From:Zero:To:One::In:Steps”Old : Calc:1.FLNK A:Variable:That:Changes:Its:Value:FromNew : Calc:1.FLNK A:Variable:That:Changes:Its:Value:From

$ camonitor Calc:1Calc:1 2016-04-22 11:47:26.143711 1 Calc:1 2016-04-22 11:47:26.644324 -1 Calc:1 2016-04-22 11:47:27.144449 -0.9 Calc:1 2016-04-22 11:47:27.644192 -0.8 Calc:1 2016-04-22 11:47:28.144310 -0.7 Calc:1 2016-04-22 11:47:28.644542 -0.6 [monitor stops since the database logic is broken by an invalid link]

Figure 6: Using caput

$ caput -S Calc:1.FLNK$ “A:Variable:That:Changes:Its:Value:From:Zero:To:One::In:Steps”Old : Calc:1.FLNK$ A:Variable:That:Changes:Its:Value:From:New : Calc:1.FLNK$ A:Variable:That:Changes:Its:Value:From:Zero:To:One::In:Steps$ caget -S Calc:1.FLNK$Calc:1.FLNK$ A:Variable:That:Changes:Its:Value:From:Zero:To:One::In:Steps

# The previous monitor command is running the whole time$ camonitor Calc:1Calc:1 2016-04-22 11:47:26.143711 1 Calc:1 2016-04-22 11:47:26.644324 -1 Calc:1 2016-04-22 11:47:27.144449 -0.9 Calc:1 2016-04-22 11:47:27.644192 -0.8 Calc:1 2016-04-22 11:47:28.144310 -0.7 Calc:1 2016-04-22 11:47:28.644542 -0.6 [monitor stopped by invalid link, but continues after the fix]Calc:1 2016-04-22 11:50:38.144649 -0.5 Calc:1 2016-04-22 11:50:38.644413 -0.4 Calc:1 2016-04-22 11:50:39.143788 -0.3

Figure 7: Using the value as an array

Integration of the Raspberry Pi NoIR Camera into EPICS

IntroductionThe Raspberry Pi is a small single-board computer that can run a full-fledged op-erating system, like Linux. This means that it is able to run EPICS. Its NoIR camera captures images in the dark and can de-tect processes like photosynthesis. [1] This combination makes it suitable for use in area detection.

As a Research Project, we investigated if it is possible to speed up and simplify area detection with EPICS by using the Raspberry Pi and its camera. This system can run as a standalone IOC on the Raspberry Pi, not consuming any additional resources on other machines. The driver we created contains around 36 EPICS PVs, which are used for image capture, retrieval and to change camera settings.

The camera device support and API server were developed to reduce the time and effort required to set up an image capture (or area detection) and image retrieval system in EPICS. All services run on the Raspberry Pi and a browser is sufficient for viewing the images; no additional view-ing software is required

Architectural OverviewThe system architecture is shown in Figure 1. One of the advantages of this system is that all services run on the Raspberry Pi, which frees other devices to focus on more important tasks. The main part is the IOC which handles the acquisition re-quests and manages the setting PVs. The acquisition of images was implemented

by: Domen Soklic (Cosylab)

Student Project

Volume 27 Control Sheet ISSN: 1855-9255

7page:

Figure 2: Flowchart of the program.

Prepare memory

Wait for event

Convert image

Update metadata

Grab image and store it

Continuous True

False

Recieve PV change

Reason

Trigger photo event

Acquire

Write value to API

Check readback

Other

Thread A Thread B

Figure 1: System Architecture

Web Browser

RESTful API

Input/Output Controller

(IOC)

Camera API and Hardware

Client Device Raspberry Pi

Network

with the help of the EPICS areaDetector plugin [2].

The server, which handles the RESTful API calls and acts as a middleware between the browser and the IOC, is implemented in Flask. Flask is a micro, web-develop-ment framework for Python [3].

The browser connects to the API server and requests the captured images, set-tings and sends any changes made by the user.

Driver ImplementationFigure 2 shows an overview of the work-flow of the driver that was written to sup-port the camera. The driver code, written in C++, contains a total of 650 lines. Most lines contain glue code which binds the setting PVs to hardware API calls.

The driver first creates the default values for the PVs and creates the event which will signal when an image should be cap-tured. A new thread is then created, which

will handle the image capturing. This new thread waits for the previously created event to signal that an image has been requested.

The first thing that needs to be done when acquiring an image is to read the color mode setting. The color mode specifies which RGB values represent which color channel. The image size is also retrieved from a PV, since it can be changed by the user, and there is no way to this know from the stream of image data.

The memory is then allocated and the im-age is captured. The areaDetector plugin also allows some image conversion to be carried out at this point. The thread then waits again for a new signal.

RESTful APIThe RESTful API was implemented with the Python micro-framework, Flask. The image operations are carried out with the Pillow [4] library, which is a fork of the out-dated PIL library.

The API uses Attribute Routing to retrieve and send information.

For example, a record value can be ac-cessed by HTTP GETing the following URL:

http://<url>/caget/<record>/

Using this approach greatly simplifies the readability of the commands compared to some other routing methods.

Images are retrieved in a similar way. The

image is loaded by simply getting the URL:

http://<url>/image/

The image is a special case, since it re-quires additional operations such as determining the size of the image and encoding it into a suitable format. The en-coding best suited for the majority of the photos, which are expected to be taken with this camera, is JPEG.

The breakdown in Figure 3 shows that even with the required encoding time, the JPEG image is still loaded faster than when using other encodings.

The compression is carried out with the built-in methods of the Pillow library. The purpose of this task was to create a work-ing prototype, so the results are not opti-mised. It is possible that the use of better algorithms could have reduced the en-coding times.

The use of JPEG might not be suitable for carrying out any computer vision op-erations on the image. If having a lossless image is a requirement, the server can be quickly modified to encode into BMP or PNG.

The Flask server also serves static files. The only static files served are the HTML page, the CSS stylesheet, and JS script. This is not the most efficient way to serve static files, but is good enough for the small number of files served and simplifies deployment.

Flask can run off the built-in development server, but this is not recommended for production. This is why the script uses Tor-nado. Tornado is a Python web framework and asynchronous networking library. By using a non-blocking network I/O, Torna-do can scale to tens of thousands of open connections, making it ideal for long poll-ing, WebSockets, and other applications that require a long-lived connection to each user. [5]

Web ClientThe web client provides a system inde-pendent way to interact with the IOC. Since only a web browser is needed, the camera can even be used with mobile phones. Using the HTTP protocol and a browser also enables the device to be mo-

Volume 27 Control Sheet ISSN: 1855-9255

8page:

Domen Soklic joined Cosylab in January 2016. He has been around computers since a young age and learned programming by first tweaking sample programs and then by writing his own. He is currently finishing his Bachelor’s degree in Computer Science from the Univer-sity of Ljubljana. His previous work experience mainly includes web technologies and mobile platforms.

ABOUT THE AUTHOR

REFERENCES

[1] https://www.raspberrypi.org/blog/whats-that-blue-thing-doing-here/

[2] http://cars9.uchicago.edu/software/epics/areaDetector.html

[3] http://flask.pocoo.org/docs/0.11/

[4] https://pypi.python.org/pypi/Pillow/3.2.0

[5] http://www.tornadoweb.org/en/stable/

[6] https://angularjs.org/

0 500 1000 1500 2000 2500 3000 3500

JPEG

PNG

BMP

Image loading time breakdown in ms

CA Get Convert Encode Network

Figure 3: Image loading time breakdown

bile i.e. connected to any wireless network or similar, as long as proper encryption and authorization is implemented.

The web interface is created with Angu-larJS [6], which is a Model-View Control-ler framework. By using a Model-View-Controller architecture, the complexity of implementing a real-time web interface was significantly reduced.

Messaging the server with changed set-tings is done with AJAX calls. The server is also periodically polled for information, to determine the state of the camera and if any values have changed.

Since the image retrieving and encoding is done completely on the server, the cli-ent doesn’t require any additional code to display the image, so it can be included in a simple <img> HTML tag.

Continuous ModeThe system also supports a continuous mode, where the image is periodically updated. This is achieved by enabling the continuous mode on the camera driver, which stops waiting for the acquire event, and starts capturing the image constantly.

The continuous mode also changes the behavior of the web interface. The inter-face starts continuously refreshing the im-age.

By doing some profiling with the resolu-tion at the lowest setting (320 x 240), a framerate of about 6 fps is achieved. De-tails of this analysis is shown in Table 1 where:

◊ Capture is the time it takes between iterations of the capture loop

◊ EPICS is the part it takes to CA get the image data

◊ Conversion is the time it takes to con-vert the data to a python object

◊ Encoding is the time to encode it to JPEG

◊ Network is the time to transfer it to the web browser

These results show that EPICS is the bot-tleneck and if a higher framerate and/or resolution is required, proper video cap-ture should be implemented outside of EPICS.

ConclusionUsing the Off-The-Shelf available Raspber-ry Pi together with its NoIR camera turns out to be a straightforward way to set up area detection or image capturing with EPICS. The system runs as a standalone IOC on the Raspberry Pi, giving it a small form-factor and flexible setup.

Your thoughts and opinions, as well as re-quests for more information are welcome at info@cosylab.com.

Time (ms)

Capture 33.3

EPICS 112.0

Conversion 2.0

Encoding 4.0

Network 20.0

Total 171.3

fps 5.8

Table 1: Results of profiling at a resolution of 320 x 240.

Volume 27 Control Sheet ISSN: 1855-9255

9page:

Site Independent EPICS IOC Software

Introduction EPICS, by design, is a modular software, consisting of the EPICS base and several modules, where each module is in charge of communicating with a specific device-type or implements a specific functional-ity. How all of these components are as-sembled together and initialized defines the final application, i.e. a specific EPICS IOC.

However, during the system integration, integrators are often faced with the situa-tion, where the same basic EPICS configu-ration is implemented, with only minor differences between specific IOCs. The most common cases may be:

◊ building a separate EPICS IOC, which supports a reduced set of devices for testing,

◊ maintaining a product line, with differ-ent configurations, but essentially the same device,

◊ preparing a reduced configuration for use when the facility is being installed and not all devices are ready.

With such scenarios, it is common to edit the configuration files and manually up-date the graphical user interfaces. This is not only a time consuming task, but more importantly, it is an error-prone process and makes the maintaining the code more challenging.

Our approach toward simplifying this task is based on the idea of splitting the EPICS IOC into two parts:

1. the site independent part, consisting of the EPICS base and modules and ,

Installing and maintaining several versions of EPICS IOCs, which essensially control devices of the same type, is a demanding task during the control system development and installation. Cosylab has developed an automated procedure to simplify and speed up the installation and configuration of such IOCs.

2. the site-dependent configuration and startup scripts.

This enables parallel development of the core IOC components and the configura-tion files for specific IOC applications (e.g. test facility, site A, site B…).

In order to further reduce the chance of human-induced errors, we automated the process of generating the site-dependent part of the IOC. Therefore, the specific site-configurations are maintained in one structured file, which lists all the device in-stances used by the site and their param-eters (e.g. IP addresses, positions on the beamline…).

However, such a design of the IOC may only be appropriate for applications, which require a large number of very simi-lar IOCs, which share the same functional-ity and/or are used to control devices of the same type.

In this article, we present the require-ments for the EPICS system architecture, to support this feature, followed by the design of the configuration management tool, which automates the process of gen-erating the site-dependent configuration. We conclude with a discussion regarding further development and opportunities.

Separating the EPICS IOC Core and ConfigurationWithout delving too deeply into the EPICS development, we can roughly view a typi-cal EPICS IOC as an assembly of the follow-ing components:

◊ EPICS application binaries

◊ EPICS database definitions

◊ EPICS database template files

◊ Startup scripts (i.e. st.cmd)

EPICS binaries are built to from EPICS base and required modules (either third-party extension or specific modules for our cus-tom devices). Therefore, these are very general and in our scope can be viewed as essentially the same for any site or con-figuration. The same holds true for the da-tabase definition files.

However, the EPICS database templates have to be instantiated for each device in the setup and loaded accordingly at ini-tialization. Finally, the main startup script (st.cmd) is essentially the same for all IOC configurations.

As we’ve stated, these components pres-ent the main building blocks of the EPICS IOC, which includes all the functionality, definitions, and record device support.

What is not included is any specific con-figurations, device count or device place-ment. All of this is then part of the site-de-pendent EPICS IOC or site-configuration. The site configuration therefore includes:

◊ Customized pre- and post- initializa-tion routines

◊ EPICS database substitution files, which specify the number and names of devices used in a specific setup

◊ (optional) Additional device specific commands, such as spawning se-quencer programs, magnet ramping configurations, etc.

by: Matej Gašperin (Cosylab), Gašper Tomažič (Cosylab), Janez Golob (Cosylab)

Volume 27 Control Sheet ISSN: 1855-9255

10page:

Automating the Generation of the Site Configuration The manual development and implemen-tation of all the files included in the site configuration is a time-consuming and error prone process. In order to alleviate this, we have implemented the entire process in a software tool, which takes a site description file as an input, in addition to optional support files (e.g. CSS screen templates, magnet characteristics) and outputs a site configuration folder, which contains all the site specific parts of the EPICS IOC (Figure 1).

The site description file can be any struc-tured document or markup language format (e.g. XML, JSON), which makes it convenient, on one hand, for the instal-lation team to manually edit and easy for the software tool to parse on the other. The file describes the properties of every file used in the setup along with some ad-ditional system properties.

The configuration management tool then

processes this site description file and outputs all required configuration files. Besides the configuration files, the output also includes a fully functional graphical user interface which can be used to moni-tor and control the configured devices.

Currently, all types of commonly used EP-ICS related software components are sup-ported. Furthermore, the configuration management tool was developed such that it can be easily extended to generate configurations for new kinds of IOC com-ponents.

EPICS IOC Configuration ExampleAll the information regarding the specific installation of the EPICS IOC is collected in a single file.

Figure 2 shows an excerpt of such a file, from a demonstration IOC configuration, which follows a JSON file structure. The IOC for this example is named SiteCon-figDemoIOC and includes a general IOC configuration, which is responsible for

generating the initialization scripts and one power supply for a dipole magnet. The important thing to note here is, that this file includes all customized device parameters needed by the IOC and CSS screens and it is easy to maintain.

Then, all that the installation team must do is to merge the base EPICS IOC build folder with the site configuration folder.

Summary and ConclusionsInstalling and maintaining several versions of EPICS IOCs, which in its essence con-trols devices of the same type, has proven to be a relatively demanding task during the control system development and in-stallation processes. In order to simplify and speed up the installation and con-figuration of such IOCs, Cosylab uses an automated procedure for managing and deploying the EPICS IOC configurations. With our approach, we ensure that all the site-specific configuration data is main-tained in a single file. From this file, the en-tire configuration of the EPICS IOC is then generated in a fully automated way. The configuration and installation procedure is therefore reduced to merging the IOC binaries and database template files with the generated configuration to produce a fully operational IOC and corresponding CSS operator screens.

In our experience, this has not only re-duced the effort required for IOC installa-tion, but has also reduced the number of errors and misconfigurations and simpli-fied the testing processes.

Matej Gašperin, PhD is a Software Developer at Co-sylab. He has strong background in control systems engineering and statistical signal processing. His work is mainly focused on development and implementation of advanced control and diagnostic strategies for medi-cal accelerators.

Gašper Tomažič is a Software Developer at Cosylab with strong background in computer science and en-gineering. He specialized in development of high-level accelerator control system software components and applications.

Janez Golob is a Senior Software Developer and Proj-ect Manager at Cosylab. He has extensive experience in design and development of EPICS control systems. Recently, his work is mainly focused on EPICS software architecture and design and project management.

ABOUT THE AUTHORS

Figure 1: EPICS IOC configuration generation workflow

SITE DESCRIPTION

EPICS CONFIGURATION MANAGEMENT

TOOL

SITE CONFIGURATION

site description file additional

configuration files

EPICS IOC configuration

CSS screens configuration

Additional plugins

EPICS database substitution files

IOC initialization routines

CSS operator screens

“SiteConfigDemoIOC”: { “iocConfiguration”: “cfg_dir”: “ SiteConfigDemoIOC/siteconfig” }, “powerSupply”: { “devices”: [ { “type”: “dipole_magnet”, “name”: “DIPOLE:M1”, “location”: “SECTION_1”, “ip_address”: “192.168.1.105:8000” },...

Figure 2: An excerpt from the EPICS IOC site description file

Cosylab d.d., Teslova ulica 30, SI-1000 Ljubljana, SLOVENIA

Phone: +386 1 477 66 76 Email: controlsheet@cosylab.com URL: www.cosylab.com

The Picture Board The 55th Annual Conference of the Particle Therapy Co-Operative Group took place from 22 to 28 May 2016 in Prague (Czech Republic). Cosylab was there and here are some moments captured by our PTCOG’55 team.

Cosylab d.d., Teslova ulica 30, SI-1000 Ljubljana, SLOVENIA

Phone: +386 1 477 66 76 Email: controlsheet@cosylab.com URL: www.cosylab.com

The Picture Board Bonus!The 2016 Sciencetival was held in the squares and on bridges around Ljubljana from 3 to 5 June. Cosylab was a sponser of the event and also had a stand in the Garden of Experiments.

The Cosylab Stand, manned by Blaž Kran-jc, Jernej Podlipnik and Blaž Ferjanc (in background) was quite busy.

Recruitment Strategy Cosylab’s early re-cruitment programme was quite tiring for some participants.

Bragg-Peak There was also a demonstra-tion of how the position of the Bragg Peak is moved during a proton thearpy treat-ment.

Table-top Accelerator The in-house built accel-erator worked perfectly at demonstrating how particles are accelerated in a cyclotron.

Cosylab Forever! The free tat-toos were a hit.

...even for a bride to be