Control Sheet 27 (June 2016)

Control Sheet Cosylab’s Newsletter Volume 27

ISSN: 1855-9255

June 2016 Table of Contents Are there major trends and insights in Big Physics machine integration projects?

2

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?

3

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.

6 9 11

Client Device

Raspberry Pi

Web Browser

Input/Output Controller (IOC)

Integration of the Raspberry Pi NoIR Camera into EPICS

RESTful API

Network

SITE DESCRIPTION

 

site description file additional configuration files

EPICS CONFIGURATION MANAGEMENT TOOL

 



Student project using the Raspberry Pi and its camera for area detection with EPICS.

Camera API and Hardware

EPICS IOC configuration CSS screens configuration Additional plugins

SITE CONFIGURATION

  

EPICS database substitution files IOC initialization routines CSS operator screens

Site Independent EPICS IOC Software Automation to simplify and speed up installation and maintainenance of several versions of EPICS IOCs, which essensially control devices of the same type.

The Picture Board Featuring some snapshots from PTCOG55 in Prague, Czech Republic and the 2016 Science Festival in Ljubljana, Slovenia.

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

page:

Control Sheet

Volume 27

2

ISSN: 1855-9255

Cosylab Experts

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

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 different 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.

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

My first observation is this: if there are to be major trends, they are not necessarily obvious to the naked eye. The architectures 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 applications 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 engineering, giving us an eagle-eye view, so to speak. Let us share some of the trends and ensuing insights we’re discovering.

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 decide that your system requirements justify large custom developments. Adaptations of existing systems might well be the more rational decision.

Documentation gains importance Rok Hrovatin

Looking further than the “close neighbor” projects for commonality At first glance, one would not expect significant commonality in system requirements between, for example, an archiving system for a radio telescope and that for a large accelerator, yet there are. Furthermore, these system requirements, at the implementation level, also share many details 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

Postponing writing the documentation to a later point in the project (some developers hope for and infinite postponement!) is a practice that is less and less acceptable in accelerator integration projects.

There are a few possible explanations.

First, there’s a certain maturation and professionalization of the discipline where the non-functional requirement of maintainability 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 important medical component: for research in Proton and Carbon-ion therapy. To prepare the technology to spin-off to actual patient treatment requires that it is certifiable, with the imposed documentation requirements. Thirdly, recent dramatic increases of accelerators being built purely

page:

Volume 27 for Proton Treatment means a shift in the direction towards medical applications of the accelerator systems “market” as a whole. Medical devices require a considerable, often underestimated, quantity of documentation. The documentation, besides 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 system) is considered, but due to its complexity, also the (documented) development 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 parties 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-

Control Sheet rations can become quite complex, especially 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 administrative hurdles they’ll encounter when bringing innovative (novel) systems together. An institute’s purchasing department 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 parties. This can cause serious project delays that in hindsight turn out easily avoidable, 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.

3

ISSN: 1855-9255

ABOUT THE AUTHOR Rok Hrovatin, Ph.D., Rok’s basic education was in Mechanical 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 focussing on the optodynamic characterization of the interaction 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 industrial 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 appropriate 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 prefers wine over beer and sausages over foie gras. Most of all he likes spending quality time with his grandson.

FAQ: What is the maximum allowed length of an EPICS record name? by: Miha Vitorovič (Cosylab)

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.

Introduction

And as with many such questions it has a few answers, and we often hear all of In all EPICS-based control system projects, them: a recurring question is: What is the maximum allowed length of an EPICS record ◊ “It depends” – always an easy and correct answer :), name? This question is very popular, especially in the early stages of the project, ◊ Sometimes you hear answers like “28 characters” or “40 characters”, when the naming convention policy is defined. Searching the Tech-talk mailing list ◊ “60 characters” is the answer for newer shows that this question is quite regular EPICS systems. there as well.

In this article, we will explore this question

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

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

page:

Control Sheet

Volume 27

4

ISSN: 1855-9255

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.

Record Name A 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 Name EPICS records often need values from other 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 record name.

Database and Channel Access Links Database links and Channel Access links reference PV names and consist of the target PV name plus 2 optional flags separated by white spaces. These 2 flags may be one of these: ◊ Process Passive flags • NPP (default if no Process Passive flag is specified) • PP

• 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 maximum of an additional 8 characters.

Exploring the Limits Equipped 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 current EPICS version (3.15.3) is 60 characters.

Let’s change the name of the record Input:1 to something longer like A:Vari able: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 database 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 limited 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 truncated 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. Ending 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, field(SCAN, field(CALC, field(INPA, field(FLNK, }

“Calc:1”) { “.5 second”) “A>0.9?-1.0:A+0.1”) “Input:1”) “Input:1”)

Figure 2: A sample database

page:

Control Sheet

Volume 27

record(calc, field(SCAN, field(CALC, field(INPA, field(FLNK, }

5

ISSN: 1855-9255

“Calc:1”) { “.5 second”) “A>0.9?-1.0:A+0.1”) “A:Variable:That:Changes:Its:Value:From:Zero:To:One::In:Steps.VAL”) “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:1 Calc:1 Calc:1 Calc:1 Calc:1 Calc:1

2016-04-22 2016-04-22 2016-04-22 2016-04-22 2016-04-22

11:27:19.584635 11:27:20.085292 11:27:20.584780 11:27:21.085298 11:27:21.585039

0.7 0.8 0.9 1 -1

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

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/displayed 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 extensions well beyond the current 60 character limit.

A final word on the limits So, can you always use more than 28 characters for naming records? It depends. If you know that all your IOCs run EPICS version 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

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

ABOUT THE AUTHOR Miha Vitorovič is a Senior Software Developer at Cosylab. 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 Machine configuration, naming, cabling and lattice applications. In his free time, Miha enjoys spending time with his family, hiking and enjoying the mountains.

############################################################################ ## 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> dbl Calc:1 A:Variable:That:Changes:Its:Value:From:Zero:To:One::In:Steps epics> dbgf Calc:1.FLNK DBR_STRING: “A:Variable:That:Changes:Its:Value:From” epics> $ caget Calc:1.FLNK Calc:1.FLNK Figure 5: Using caget

A:Variable:That:Changes:Its:Value:From

page:

Volume 27

Control Sheet

6

ISSN: 1855-9255

$ 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:From New : Calc:1.FLNK A:Variable:That:Changes:Its:Value:From $ camonitor Calc:1 Calc: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:1 Calc: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

Student Project

Integration of the Raspberry Pi NoIR Camera into EPICS

by: Domen Soklic (Cosylab)

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.

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

Architectural Overview 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 viewing software is required

The 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 requests and manages the setting PVs. The acquisition of images was implemented

page:

Control Sheet

Volume 27

Client Device

Raspberry Pi RESTful API Input/Output Controller (IOC)

Web Browser

Network

Camera API and Hardware

Figure 1: System Architecture

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-development framework for Python [3].

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

Driver Implementation Figure 2 shows an overview of the workflow of the driver that was written to support 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 captured. A new thread is then created, which

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 image 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 API The 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 outdated PIL library.

The API uses Attribute Routing to retrieve and send information.

For example, a record value can be accessed 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

Recieve PV change

Wait for event Prepare memory

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

False

True

Acquire

Grab image and store it

Trigger photo event

Convert image Update metadata

Figure 2: Flowchart of the program.

Other

Reason

Continuous

Thread B

ISSN: 1855-9255

image is loaded by simply getting the URL: http://<url>/image/ The image is a special case, since it requires additional operations such as determining the size of the image and encoding it into a suitable format. The encoding 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 working prototype, so the results are not optimised. It is possible that the use of better algorithms could have reduced the encoding times.

The use of JPEG might not be suitable for carrying out any computer vision operations 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 Tornado. Tornado is a Python web framework and asynchronous networking library. By using a non-blocking network I/O, Tornado can scale to tens of thousands of open connections, making it ideal for long polling, WebSockets, and other applications that require a long-lived connection to each user. [5]

Web Client Write value to API

Thread A

7

Check readback

The web client provides a system independent 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-

page:

Control Sheet

Volume 27

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 AngularJS [6], which is a Model-View Controller framework. By using a Model-ViewController architecture, the complexity of implementing a real-time web interface was significantly reduced.

Messaging the server with changed settings 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 client doesn’t require any additional code to display the image, so it can be included in a simple <img> HTML tag.

Continuous Mode The 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 interface starts continuously refreshing the image.

ISSN: 1855-9255

By doing some profiling with the resolution at the lowest setting (320 x 240), a framerate of about 6 fps is achieved. Details 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 convert 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

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

Time (ms) Capture

33.3

EPICS

112.0

Conversion

2.0

Encoding

4.0

Network

20.0

Total

171.3

fps

5.8

REFERENCES

These results show that EPICS is the bottleneck and if a higher framerate and/or resolution is required, proper video capture should be implemented outside of EPICS.

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

Conclusion

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

Using the Off-The-Shelf available Raspberry 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 requests for more information are welcome at info@cosylab.com.

[2] http://cars9.uchicago.edu/software/epics/ areaDetector.html [3] http://flask.pocoo.org/docs/0.11/ [5] http://www.tornadoweb.org/en/stable/ [6] https://angularjs.org/

ABOUT THE AUTHOR 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 University of Ljubljana. His previous work experience mainly includes web technologies and mobile platforms.

Image loading time breakdown in ms BMP

PNG

JPEG 0

8

500

1000 CA Get

1500 Convert

Figure 3: Image loading time breakdown

2000 Encode

2500 Network

3000

3500

page:

Volume 27

Control Sheet

9

ISSN: 1855-9255

Site Independent EPICS IOC Software by: Matej Gašperin (Cosylab), Gašper Tomažič (Cosylab), Janez Golob (Cosylab)

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.

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 devicetype or implements a specific functionality. How all of these components are assembled together and initialized defines the final application, i.e. a specific EPICS IOC. However, during the system integration, integrators are often faced with the situation, where the same basic EPICS configuration 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 different 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 update 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 ,

2. the site-dependent configuration and startup scripts.

◊ EPICS database template files ◊ Startup scripts (i.e. st.cmd)

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

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

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 instances used by the site and their parameters (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 similar IOCs, which share the same functionality and/or are used to control devices of the same type.

In this article, we present the requirements for the EPICS system architecture, to support this feature, followed by the design of the configuration management tool, which automates the process of generating the site-dependent configuration.

We conclude with a discussion regarding further development and opportunities.

Separating the EPICS IOC Core and Configuration Without delving too deeply into the EPICS development, we can roughly view a typical EPICS IOC as an assembly of the following components: ◊ EPICS application binaries ◊ EPICS database definitions

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

As we’ve stated, these components present 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 configurations, device count or device placement. All of this is then part of the site-dependent EPICS IOC or site-configuration.

The site configuration therefore includes: ◊ Customized pre- and post- initialization 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 sequencer programs, magnet ramping configurations, etc.

page:

Control Sheet

Volume 27

SITE DESCRIPTION

 

site description file additional configuration files

EPICS CONFIGURATION MANAGEMENT TOOL

 



EPICS IOC configuration CSS screens configuration Additional plugins

SITE CONFIGURATION

  

EPICS database substitution files IOC initialization routines CSS operator screens

Figure 1: EPICS IOC configuration generation workflow

Automating the Generation of the Site Configuration The manual development and implementation 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 structured document or markup language format (e.g. XML, JSON), which makes it convenient, on one hand, for the installation 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 additional 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 monitor and control the configured devices.

Currently, all types of commonly used EPICS related software components are supported. Furthermore, the configuration management tool was developed such that it can be easily extended to generate configurations for new kinds of IOC components.

EPICS IOC Configuration Example All 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 SiteConfigDemoIOC and includes a general IOC configuration, which is responsible for

“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

10

ISSN: 1855-9255 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 Conclusions Installing and maintaining several versions of EPICS IOCs, which in its essence controls devices of the same type, has proven to be a relatively demanding task during the control system development and installation processes. In order to simplify and speed up the installation and configuration 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 maintained in a single file. From this file, the entire 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 reduced the effort required for IOC installation, but has also reduced the number of errors and misconfigurations and simplified the testing processes.

ABOUT THE AUTHORS Matej Gašperin, PhD is a Software Developer at Cosylab. 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 medical accelerators.

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

Janez Golob is a Senior Software Developer and Project 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.

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â&#x20AC;&#x2122;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ž Kranjc, Jernej Podlipnik and Blaž Ferjanc (in background) was quite busy.

Recruitment Strategy Cosylab’s early recruitment programme was quite tiring for some participants.

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

Bragg-Peak There was also a demonstration of how the position of the Bragg Peak is moved during a proton thearpy treatment.

Cosylab Forever! The free tattoos were a hit.

...even for a bride to be

Cosylab d.d., Teslova ulica 30, SI-1000 Ljubljana, SLOVENIA Phone: +386 1 477 66 76

Email: controlsheet@cosylab.com

URL: www.cosylab.com