Control Sheet No. 12
By: T. Nakamoto (Cosylab Japan)
Situated in Slovenia, Cosylab has been providing system integration and engineering solutions to our customers literally all over the world. Our high quality services have been successfully delivered to the customers for 10 years, and we gained the leading position in the field of control system integration for accelerators and large physics facilities.
Since Cosylab started in 2001, we have been consistently growing to deliver our best services to as many customers in the world as possible. Now it is a time for us to establish local branches to effectively deliver our services all over the world. We established our first branch here in Japan called "Cosylab Japan". One year has passed since the establishment, and we are now providing our quality software development and other services in Japan.
The most important characteristic of this branch is that it is not only representing Cosylab, but is also able to provide some of our engineering services directly, ranging from writing specification to implementing software. Staffs of this branch understand physics, control system, software, EPICS and jargon in this field. It means that customers in Japan can get our services quicker than before in native tongue. For those in Japan who were reluctant to ask a company abroad to do something, our branch eases your anxiety and solves your problems.
This branch is intended to provide services not only in Japan, but also in China, Korea, Taiwan and other countries in Asia. For those who are situated in Asia, our branch is now closer to you than before. Now Cosylab is able to work more closely with the customers in Asia and effectively deliver our services with smaller overhead using geographical advantages. If you are in Japan or other countries in Asia, you have a chance to benefit from our integration services optimized for your needs.
If you want to contact Cosylab Japan, feel free to directly contact Dr. Shin-ichi Kurokawa, the head of Cosylab Japan:
T: +81 (0) 80 4111 4062
A: Namiki 2-9-1006, Tsukuba, Ibaraki, 305-0044, Japan
Or you may visit our Japanese web site.
Company booth of Cosylab Japan in the 8th Annual Meeting of Particle Accelerator Society of Japan (Tsukuba). From left to right: Takashi Nakamoto, Dr. Shin-ichi Kurokawa, Satoshi Ueda
By: F. Amand (Cosylab)
How important is the usability of the operator user interface for your accelerator facility? Amazon.com spends fortunes on user tests to determine how minute, pixel-size changes improve their UI. Should we attempt the same? Or should the next version of our UI be as revolutionary as iPad's with all possible "pinch", "drag" and "throw" multi-touch gestures? Let's not get carried away.
Those UI's, besides the functional purpose, also serve as a tool of seduction, charming the customer in the direction of the companies' bottom line. Operator UI's serve the (noble) purposes of the experimental machine by minimizing operator error and allowing the trained user to go under the hood and fix unexpected behavior, quite a different animal. Still, the above mentioned companies push limits of contemporary UI design and come up with ideas, concepts and improvements we should not just ignore.
The desktop metaphor
One thing that really changed over the last 10-15 years is the amount of windows you need to drag around to achieve one task with well designed, modern software. The idea to mimic a physical desktop with paper documents spread out on a computer screen, conceived at Xerox laboratories, was pretty brilliant. It was a huge improvement over the constrained, terminal style interaction that preceded it. But by the mid-nineties it got carried too far with multiple, multiple-document applications on one desktop (don't SW people like recursion and small windows popping up all over), bugging you with feature options you didn't ask for. Major applications like the Office suite came back from this approach. New software avoids the visual clutter of throwing one new window after another at you. It rather guides you through a workflow that serves the task you aim to achieve (say e.g. a flight reservation). Or it organizes multiple "documents" in tabs (e.g. browsers, email tools, …).
My point is this: if you see your operators dragging around (pop-up) windows a lot before they reach the information or button they need, then your system might be too much indebted to the old desktop paradigm. It might needlessly slow them down, frustrate them, or even force them into operator error.
Goal Oriented Interaction Design
Goal oriented interaction design is a term coined by Alan Cooper, the father of visual basic and prolific writer on UI design. The term is well chosen. I agree with Mr. Cooper that these two elements are key ingredients to superior UI designs: Goal orientation and seeing the UI as a way to interact (deeply) with the software application rather than a shallow window or hatchway between two separated worlds.
To make it concrete. Instead of implementing a system requirement to e.g. display all the dipole magnets of the system in one panel, one should ask: what goal are we accomplishing in the first place? In which (important, frequent) scenario does the operator needs this screen? A step in commissioning, error recovery, …?
Approaching it this way, it becomes much more obvious which magnet details to show and, equally important, which ones of the many to hide, to keep the screen neat, uncluttered and above all usable. The second part is the "interaction" aspect. For sound technical reasons, the user interface layer of a software system is rather shallow and by design separated from other parts of the software. Programmers typically find this layer relatively easy to program and would rather first concentrate their efforts on the challenging parts "down below". This holds the risks for the usability of the UI, as it might get bolted on the system and not seen as an integral part of the top level design. UI designers rather take abstraction from the specifics of the used UI technology and focus on designing workflows or interactions, that achieve a number of well-defined user goals in a logical and consistent way.
A good starting point is to do what is called "ethnographic research": observation of users of a similar or previous version of the system to be designed and, together with the product owner, deciding on types of users (called Personas) and their primary goals with the system. Only then these goals are broken down in procedures or "tasks" and do they design an outline interface (a concept).
If this sounds radically different than giving the operators a GUI toolkit to script their own UI's on an existing system, well, it is. The toolkit can be a nice extra on top of a well-designed operator user interface that takes care of the essential interactions with the system. It can never replace it.
If you'd like to find out more, write me a line and I'll get back to you: email@example.com
By: G. Cuk (Cosylab), Z. Kroflic (COBIK), R. Tavcar (Cosylab)
Accelerators do not come cheap. Obviously, protection of expensive equipment is needed to avoid damage because of a missteered beam, whatever the cause may be. Since particles travel at nearly the speed of light with GeVs of energy, a fast and reliable response to a “beam gone bad” is crucial.
This article will outline a systematic view of machine protection system (MPS) stemming from our experience with FRIB  and ESS  MPS conceptual designs as well as presentations and debates from the first MPS Workshop on Linear Accelerator complexes which was held in Cern in June 2012 .
The article’s aim is to standardize the terminology and understanding of basic components and principles involved in MPS design.
Machine protection is much more than beam interlock system
When talking about machine protection, people often only think of the Beam Interlock System (BIS) – an autonomous system that collects signals from various devices and triggers shutdown of the machine when any of the devices detects a failure. This system usually comes down to a hardware based solution with powerful FPGAs, fiber optics etc. capable of monitoring thousands of devices and triggering mitigation actions upon detecting a fault condition, often with other features like configurable responses, signal logging for post-mortem analysis, input masking etc.
Because of very fast response, large number of devices and high level of reliability, interlock systems pose unique design challenges and can be a tough nut to crack - that is why too often broader aspect of machine protection is overlooked. The Beam Interlock System is a key component and part of a larger machine protection strategy. One must further realize that the beam interlock greatly relies on systems and devices that are capable of failure detection and others that can shut off the beam. Figure 1 below summarizes some major building blocks of machine protection system. There are two components that are as important as the interlock system: MPS Input Devices (MID) which include all devices that measure machine or beam health (e.g. beam loss monitors, collimators, wire scanners, magnets, RF systems, cryogenic systems, powering systems, vacuum system and many others) and MPS Output Devices (MOD) that include all possible mitigation devices like choppers and beam dumps.
Without proper configuration and reliable operation of MID and MOD devices, beam interlock system could never protect the machine. Other important MPS components are Configuration Management (for configuring MID, MOD and BIS devices), Beam Permit System (for validating device configuration and machine status before beam injection) and Post Mortem (for log analysis after the MPS shuts down the machine).
Systematic approach to MPS design
Interlock systems can be developed by one group of smart people, but machine protection is a responsibility of several accelerator groups. Communication and cooperation among groups is of utmost importance for ensuring machine safety.
Usually, there is a large variety of MID devices based on different principles of detection of improper machine behavior. If they are left completely to their own design, this variety will result in a large number of different interfaces to the BIS, posing a big and expensive design problem. It is therefore important that the people responsible for machine protection pre-define a single interface to the beam interlock system and help other groups to adhere their devices to it. To achieve high reliability, interlock should accept simple binary signals only. All MID devices should internally analyze and assess measured parameters and status and should report to interlock only two states: ok or not-ok.
To unify and speed up the integration of thousands of devices, a framework with clearly defined features, interfaces and set of rules how to integrate MID devices to MPS system should be prepared as early in the development process as possible. Accompanying this, a vertical prototype of MID device with full integration with other MPS components should be provided to demonstrate a typical instance of MID design and integration. There are several features that should be introduced in the scope of this demonstration. MID settings may depend on beam or machine mode, so integration with other systems (e.g. timing system) is needed to obtain the information of current mode. Furthermore, MID devices are expected to perform extensive logging to provide enough information for successful post-mortem analysis. Logs should be precisely time stamped and synchronized with logs of other devices. With such a systematic approach, one can take the necessary steps towards a system which truly respects the conceptual view of MPS illustrated in.
Safety awareness to sustain reliability when maximizing availability
Even if all measures described in previous chapter are taken and the finished MPS is sound, this ultimately still does not assure safe operation. For example -- if a threshold on a MID device is for some reason set too high, the device will not report a fault and the machine will not be stopped even if the actual monitored parameter is out of safe range. On the other hand, a threshold set too low will lead to unnecessary beam dumps, resulting in reduced machine availability. Machine protection is therefore a delicate compromise between reliability and availability. In order to reach optimal balance, a high degree of safety awareness should be infused in day to day operations of a machine.Decisions to change an already proven MPS configuration should not be taken lightly and should be discussed within a group of experts.
MPS is not constrained to a definition of an interlock system and must be considered much wider. To successfully integrate all subsystems into a coherent protection system, several steps such as early framework definition and vertical prototyping should be taken. Finally, a responsible operation of already running system should be ensured by nurturing a high degree of safety culture among operators and supervisors.
Components of machine protection
By: K. Meyer (Cosylab)
“If you, like we do, have the urge to make things work properly, why don't you join us?” - these were the words that changed my life.
OK, maybe nothing so dramatic, but it certainly was the beginning of a new phase of my life. They appeared in an advert in the November and December 2011 issues of the British Institute of Physics magazine “Physics World”. And so I carefully typed up my covering letter and sent off my job application package. The rest, as they say, is history! I have now joined Cosylab. Some of you may have seen me briefly at the end of March. If you're wondering why you haven't seen me since then, it's because I am back in South Africa. I need to get my Blue Card approved (work and residence permit for the highly skilled) and then I will be relocating to Slovenia. Thanks to the internet, though, I can telecommute and have already started working for the ITER group.
So how did this happen? Let's just say that I like variety. I am a Jack-of-all-trades, with an interest in software, electronics and business processes (as comfortable with a keyboard as with a soldering iron). I am also a scientist, consultant and systems integrator. I had been looking for a full time job for a while, but I was being very careful – I wanted my next job to be a fantastic match with my interests and one that would keep me engaged for at least the next 10 to 15 years, with an open and engaging management. I have a B.Sc. majoring in Computer Science, Physics and Applied Physics, a B.Sc. Honours in Computer Science, an M.Sc. and a Ph.D. in plasma physics (both of them experiment based).
I have worked as a software developer, in electronics and as a business consultant. My jobs have taken me to the Kalahari Desert in Botswana the rainforests of Ghana, deep underground in a platinum mine, the forests of Canada and the beautiful island of Evia in Greece. I have driven a (virtual) 120-ton ore transporter, driven a (virtual) amphibious armoured vehicle and handled (man-made) diamonds. I have even been able to scratch the chin of a rhino. In my spare time I enjoy reading (mostly science fiction), gardening and walking, and I am a contributor to the Apache Isis project.
What appeals to me about Slovenia?
For most satisfaction the job advert recommended joining the head office in Ljubljana, Slovenia, but just where was Slovenia? Loading up Wikipedia and Google Maps, I was quickly able to locate Slovenia, and it looked good – small yet well developed, in Europe but with plenty of nature, with a reasonable population size (so not overcrowded), it was all quite perfect. Once I had been through the interview and evaluation processes and it became clear that Cosylab had a position for me, it was time for my wife (Jaynie), and I to visit Ljubljana and see the city for ourselves. Our primary concerns had to do with food (Jaynie is a keen nutritionist and mostly vegetarian), cost (we believed that Europe was very expensive) and social integration (we're a mixed race couple). We needn't have worried – our first foray into a supermarket (the Maxi Mart) revealed a very well stocked health food section. Almost every restaurant we found had vegetarian options (there are even at least two entirely vegetarian restaurants!) and most people were quite friendly. Even our cost calculations revealed that only accommodation (followed by appliances) are really much more expensive than in South Africa – food and entertainment are about the same. Slovenia (and Ljubljana) appealed to us for a number of reasons: It's the third most forested nation in the EU (after Finland and Sweden), with a low population density and high human development index. All of which were confirmed by our visit.This means that we can move to a stable country in the EU, with convenient access to nature (mountains and forests close by), all the advantages of living in a capital city with none of the disadvantages (crowding – having grown up in Africa, we like our space). And with good opportunities to travel!
The “Physics world” advert appealed to me – working on the control systems of big physics experiments – not everyone wants to do big physics, some of us do want to work on the control systems! Further reading about Cosylab showed that it was young, yet established, and clearly a growing company with many international clients. It also offered the opportunity to work as a software developer and a scientist, and to work with software developers and scientists. They even have hardware projects!
Thus far, my experiences with Cosylab have been amazing, I have never worked for a company that is so well organized. Peter and Igor have a well structured applicant evaluation system. Their interviews were detailed and to the point. Their interest in me as a candidate was tangible, and my questions were taken seriously. After my candidacy was confirmed, my sign-on was straight forward – and all Cosylab business and HR systems are online and accessible via their web portal.
And the people!
Everyone I met at Cosylab was friendly and engaging. I can't wait to join them. I am already quite envious of the staff at the head office in Ljubljana – the emails on the internal mailing lists show a social, vibrant and productive working community. A special thanks to the people that I have worked with, who made me feel welcome and who have helped out where I've needed it.
And so has begun a new adventure for us.
By: M. Rescic (Cosylab)
In April ESS hosted it's first Innebandy (floorball—a form of indoor hockey) tournament. The joint Accelerator-Target team (pictured) a.k.a. the "Red team" took on the Programme-Neutrons team (100% Swedish) and the Administration (100% Swedish) team. After 3 merciless, brutal matches and one treason the Red team finished 2nd in an all-Swedish sandwich. For an international team that had one month of innebandy experience that was not bad at all. There you have it, the first of many ESS floorball tournaments is over and after a week, when all of our muscles stopped hurting, we were very happy with the experience and we are already looking forward to the next one!
From left to right: Miha Rescic (Slo-Cosylab), Aurelien Ponton (Fra), Stephen Gallimore (UK), Mohammad Eshraqi (Iran)back to previous content