Paper | Title | Other Keywords | Page |
---|---|---|---|
MOPPC075 | A Monte Carlo Simulation Approach to the Reliability Modeling of the Beam Permit System of Relativistic Heavy Ion Collider (RHIC) at BNL | simulation, distributed, kicker, electron | 265 |
|
|||
Funding: Work supported by Brookhaven Science Associates, LLC under Contract No. DE-AC02-98CH10886 with the U.S. Department of Energy. The RHIC Beam Permit System (BPS) monitors the health of RHIC subsystems and takes active decisions regarding beam-abort and magnet power dump, upon a subsystem fault. The reliability of BPS directly impacts the RHIC downtime, and hence its availability. This work assesses the probability of BPS failures that could lead to substantial downtime. A fail-safe condition imparts downtime to restart the machine, while a failure to respond to an actual fault can cause potential machine damage and impose significant downtime. This paper illustrates a modular multistate reliability model of the BPS, with modules having exponential lifetime distributions. The model is based on the Competing Risks Theory with Crude Lifetimes, where multiple failure modes compete against each other to cause a final failure, and simultaneously influence each other. It is also dynamic in nature as the number of modules varies based on the fault trigger location. The model is implemented as a Monte Carlo simulation in Java, and analytically validated. The eRHIC BPS will be an extension of RHIC BPS. This analysis will facilitate building a knowledge base rendering intelligent decision support for eRHIC BPS design. |
|||
![]() |
Poster MOPPC075 [0.985 MB] | ||
MOPPC076 | Quantitative Fault Tree Analysis of the Beam Permit System Elements of Relativistic Heavy Ion Collider (RHIC) at BNL | operation, kicker, simulation, interface | 269 |
|
|||
Funding: Work supported by Brookhaven Science Associates, LLC under Contract No. DE-AC02-98CH10886 with the U.S. Department of Energy. The RHIC Beam Permit System (BPS) plays a key role in safeguarding against the anomalies developing in the collider during a run. The BPS collects RHIC subsystem statuses to allow the beam entry and its existence in the machine. The building blocks of BPS are Permit Module (PM) and Abort Kicker Module (AKM), which incorporate various electronic boards based on VME specification. This paper presents a quantitative Fault Tree Analysis (FTA) of the PM and AKM, yielding the hazard rates of three top failures that are potential enough to cause a significant downtime of the machine. The FTA helps tracing down the top failure of the module to a component level failure (such as an IC or resistor). The fault trees are constructed for all module variants and are probabilistically evaluated using an analytical solution approach. The component failure rates are calculated using manufacturer datasheets and MIL-HDBK-217F. The apportionment of failure modes for components is calculated using FMD-97. The aim of this work is to understand the importance of individual components of the RHIC BPS regarding its reliable operation, and evaluate their impact on the operation of BPS. |
|||
![]() |
Poster MOPPC076 [0.626 MB] | ||
MOPPC157 | Application of Transparent Proxy Servers in Control Systems | controls, operation, framework, target | 475 |
|
|||
Funding: Work supported by Brookhaven Science Associates, LLC under Contract No. DE-AC02-98CH10886 with the U.S. Department of Energy. Proxy servers (Proxies) have been a staple of the World Wide Web infrastructure since its humble beginning. They provide a number of valuable functional services like access control, caching or logging. Historically, controls system have had little need for full fledged proxied systems as direct, unimpeded resource access is almost always preferable. This still holds true today, however unbound direct asset access can lead to performance issues, especially on older, underpowered systems. This paper describes an implementation of a fully transparent proxy server used to moderate asynchronous data flow between selected front end computers (FECs) and their clients as well as infrastructure changes required to accommodate this new platform. Finally it ventures into the future by examining additional untapped benefits of proxied control systems like write-through caching and runtime read-write modifications. |
|||
![]() |
Poster MOPPC157 [1.873 MB] | ||
TUPPC034 | Experience Improving the Performance of Reading and Displaying Very Large Datasets | network, distributed, instrumentation, software | 630 |
|
|||
Funding: Work supported by Brookhaven Science Associates, LLC under Contract No. DE-AC02-98CH10886 with the U.S. Department of Energy. There has been an increasing need over the last 5 years within the BNL accelerator community (primarily within the RF and Instrumentation groups) to collect, store and display data at high frequencies (1-10 kHz). Data throughput considerations when storing this data are manageable. But requests to display gigabytes of the collected data can quickly tax the speed at which data can be read from storage, transported over a network, and displayed on a users computer monitor. This paper reports on efforts to improve the performance of both reading and displaying data collected by our data logging system. Our primary means of improving performance was to build an Data Server – a hardware/software server solution built to respond to client requests for data. It's job is to improve performance by 1) improving the speed at which data is read from disk, and 2) culling the data so that the returned datasets are visually indistinguishable from the requested datasets. This paper reports on statistics that we've accumulated over the last two years that show improved data processing speeds and associated increases in the number and average size of client requests. |
|||
![]() |
Poster TUPPC034 [1.812 MB] | ||
TUPPC131 | Synoptic Displays and Rapid Visual Application Development | controls, embedded, power-supply, interface | 893 |
|
|||
Funding: Work supported by Brookhaven Science Associates, LLC under Contract No. DE-AC02-98CH10886 with the U.S. Department of Energy. For a number of years there has been an increasing desire to adopt a synoptic display suite within BNL accelerator community. Initial interest in the precursors to the modern display suites like MEDM quickly fizzled out as our users found them aesthetically unappealing and cumbersome to use. Subsequent attempts to adopt Control System Studio (CSS) also fell short when work on the abstraction bridge between CSS and our control system stalled and was eventually abandoned. Most recently, we tested the open source version of a synoptic display developed at Fermilab. It, like its previously evaluated predecessors, also seemed rough around the edges, however a few implementation details made it more appealing than every single previously mentioned solution and after a brief evaluation we settled on Synoptic as our display suite of choice. This paper describes this adoption process and goes into details on several key changes and improvements made to the original implementation – a few of which made us rethink how we want to use this tool in the future. |
|||
![]() |
Poster TUPPC131 [3.793 MB] | ||
TUCOCA03 | Machine Protection Issues for eRHIC | electron, kicker, booster, radiation | 914 |
|
|||
Funding: Work supported by Brookhaven Science Associates, LLC under Contract No. DE-AC02-98CH10886 with the U.S. Department of Energy. The eRHIC electron beams will be damaging both directly and as a result of synchrotron radiation. The machine protection and abort systems will be designed to prevent any equipment damage from the electron beams. In this paper we will review the requirements for the machine protection systems and the plans we have put into place to better evaluate the failure probabilities, beam abort systems designs, and overall machine protection systems designs. The machine protection systems will include a beam permit system that has inputs from loss monitors, power supplies, superconducting RF monitors, vacuum chamber heating monitors, water temperature, quench detectors, access controls systems, vacuum monitors, and longer term beam lifetime or slow loss monitors. There are three systems associated with the machine protection and beam abort systems; the beam permit link, the abort kicker systems, and the beam dumps. We describe the requirements for these systems and present our current plans for how to meet the requirements. |
|||
![]() |
Slides TUCOCA03 [2.012 MB] | ||
THPPC012 | The Equipment Database for the Control System of the NICA Accelerator Complex | controls, database, TANGO, software | 1111 |
|
|||
The report describes the database of equipment for the control system of Nuclotron-based Ion Collider fAcility (NICA, JINR, Russia). The database will contain information about hardware, software, computers and network components of control system, their main settings and parameters, and the responsible persons. The equipment database should help to implement the Tango system as a control system of NICA accelerator complex. The report also describes a web service to display, search, and manage the database. | |||
![]() |
Poster THPPC012 [1.070 MB] | ||
THPPC024 | Operating System Upgrades at RHIC | software, controls, Linux, network | 1138 |
|
|||
Funding: Work supported by Brookhaven Science Associates, LLC under Contract No. DE-AC02-98CH10886 with the U.S. Department of Energy. Upgrading hundreds of machines to the next major release of an Operating system (OS), while keeping the accelerator complex running, presents a considerable challenge. Even before addressing the challenges that an upgrade represents, there are critical questions that must be answered. Why should an upgrade be considered? (An upgrade is labor intensive and includes potential risks due to defective software.) When is it appropriate to make incremental upgrades to the OS? (Incremental upgrades can also be labor intensive and include similar risks.) When is the best time to perform an upgrade? (An upgrade can be disruptive.) Should all machines be upgraded to the same version at the same time? (At times this may not be possible, and there may not be a need to upgrade certain machines.) Should the compiler be upgraded at the same time? (A compiler upgrade can also introduce risks at the software application level.) This paper examines our answers to these questions, describes how upgrades to the Red Hat Linux OS are implemented by the Controls group at RHIC, and describes our experiences. |
|||
![]() |
Poster THPPC024 [0.517 MB] | ||