英语原文共 5 页，剩余内容已隐藏，支付完成后下载完整资料
外文原文
REAL-TIME JAVA TO SUPPORT THE DEVICE PROPERTY MODEL
C. Cardin, M.-A. Galilee, J.-C. Garnier, K. Krol, M. Osinski, A. Stanisz, M. Zerlauth CERN, Geneva, Switzerland
Abstract
Todayrsquo;s front-end controllers, which are widely used in CERNs controls environment, feature CPUs with high clock frequencies and extensive memory storage. Their specifications are comparable to low-end servers, or even smartphones. The Java Virtual Machine (JVM) has been running on similar configurations for years now and it seems natural to evaluate the behaviour of JVMs on this environment to characterize if Firm or Soft real-time constraints can be addressed efficiently. Using Java at this low-level offers the opportunity to refactor CERNs current implementation of the device/property model and to evolve from a monolithic architecture to a promising and scalable separation of the area of concerns, where the front-end may publish raw data that other layers would decode and re-publish. This paper presents first the evaluation of Machine Protection control system requirements in terms of real-time constraints and a comparison of the respective performance of different JVMs. In a second part, we will detail the efforts towards a first prototype of a minimal RT Java supervision layer to provide access to the hardware layer.
INTRODUCTION
The device property model has been used at CERN since the exploitation of the Proton Synchrotron (PS) in the early 1960s and the subsequent Super Proton Synchrotron (SPS). In this model, users are aware about devices. A device is uniquely named, and represents a physical device such as a Beam Interlock System, or a software service such as an abstraction layer to a group of systems. Each device belongs to a Class. The Class defines the Properties that can be used to access the device. A property can support 3 types of operations: get, set, subscribe.
A set operation allows the user to send a value to the property. The device will then handle the values in the appropriate way, typically in case of a hardware device, writing it into a register. A get operation allows the user to read a value from the property. Typically in case of a hardware device, this actions reads a value from a register. A subscribe operation allows the user to receive notifications from the property. Typically reading the value from a register following the refresh frequency of the hardware device.
The device property model is supported at CERN by the Controls Middleware (CMW [1]) for the communication. The control software for any equipment consists basically in a software server exposing the devices along with their properties using CMW.
The Machine Protection interlock systems, like the Beam Interlock System (BIS [2]), are designed in a highly dependable way: The entire critical functionality is implemented in a hardware layer, while the software layer brings only mon-itoring and control features. If the software is unavailable, the system safety is not compromised and it will continue to be able to perform the most critical safety functions and put the machine into a fail-safe state, if required. However, controlling and e.g. re-arming the system will not be possible anymore without a fully operational software layer, hence the availability of the accelerator could be reduced.
The software layer for the interlock system is therefore not safety critical. Simply put, it provides monitoring and control operations to:
bull; get all the board registers
bull; get the history buffer
bull; set a register value
The clients of this API are multifold. Operation crews and interlock experts are using Graphical User Interfaces (GUIs) to control the interlock systems, to perform operations on them and to know their state. As interlock systems are a crucial component of accelerators handling large amounts of stored energies, they are also used by automated sequences [3], and by online and offline analysis tools.
The interlock software layer also handles some repetitive procedures. They send values to users that subscribed to properties or verify some states in the hardware. In addition, the software layer reacts upon asynchronous events such as a Post Mortem [4] dump request in order to send its internal states and history buffer to the Post Mortem service for diagnostic. The handling of repetitive procedures and asynchronous events as well as synchronizing the accesses to the hardware buses are the most relevant use cases for the required real-time behavior.
The Machine Protection use cases for the interlock controls supervision software is to acquire data from the hardware registers and rolling buffers at a frequency of 1 Hz. Only a few routines are executed periodically. Measurements have shown that the longest execution time was 130 ms. This leaves a large portion of the one second period to handle asynchronous requests from users and other tasks.
The Machine Protection software layers also involve a few virtual devices backed by Java servers, in order to provide a better level of abstractions to its clients, and to perform more advanced functionalities, e.g. to decode on the fly all boolean signals published by the interlock devices.
The Front-End Controllers (FEC) on which the supervision layer is executed are becoming more powerful. The current architecture has 2 cores and 1 GB of RAM, while the minimum setup of the next generation osf FEC is 4 cores and 4 GB of RAM. These ressources are more than enough to run a Java Virtual Machine. The FEC runs Real Time Linux.
The growing FEC computing capabilities, the available processing time in the period, and the experience developing with the Device Property model hardware classes backed by C servers and virtual classes backed by Java servers triggered the deeper investigation of a possible real-time Java implementation of th
全文共29433字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[15876]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
