JAVA-BASED OPEN ACCESS FRONT ENDS IN THE FERMILAB CONTROLS SYSTEM
Dennis Nicklaus · 2003
As part of Fermilab's Java-based controls software infrastructure, we have implemented an “Open Access” Front-end architecture [1]. This Java-based architecture supports software tasks commonly found in more conventional microprocessor-based front-ends. These Open Access Front-ends (OAFs) can interface Ethernetcapable devices with the rest of the control system, as well as performing other tasks such as periodic settings, data archiving, and monitoring other control system nodes. Another key task is creating readings for virtual devices by computationally combining readings from other control system devices, and various frameworks have been created to support different categories of these computations. The open access front ends exist in the console and server layers of the control system, so all the facilities of the upper layers of the control system, such as database access, are available to the OAF. Because of their Javabased object-oriented implementation, all OAFs automatically inherit support for all the data acquisition protocols of the controls system. Java classes and interfaces are provided to allow the OAF programmer to intercept readings and settings, control error returns and otherwise control the behavior of the devices contained in a particular OAF. Since the OAFs are purely software front-ends, they easily can be moved between machines, upgraded to a faster computer if needed, or instantiated on a different machine for testing. ARCHITECTURE OVERVIEW The Fermilab Data Acquisition Engines (DAEs) are Java-based servers which communicate with control system applications and nodes, speak Fermilab’s proprietary ACNET protocol, and utilize resources of the control system for themselves and on behalf of authorized clients. They run on hardware which is easily upgradeable, within high-speed network segments. The DAEs work together to consolidate traffic and functions across the control system. The OAFs exist at this server level of the control system and are instantiated as objects within the DAE. Another phrase, “Open Access Client” (OAC), is used more-or-less interchangeably with OAF. The OAFs allow developers to add devices to the control system with out needing to know anything about conventional front-end microprocessor computer hardware or software, including real-time operating systems. All the OAF devices support the reading, setting, basic status, basic control, analog alarm block, and digital alarm block properties. The Tevatron clock, fast time plot, snapshot plot, and alarm protocols are supported. Settings, status, and alarm blocks are downloaded from the device database. The OAFs can receive information about “Tevatron clock” (hardware timeline) events which have occurred. However, these event notifications are not delivered in hard real-time. Needing hard real-time notification of these hardware events is often a key requirement which will differentiate between implementing an OAF or a more traditional front-end (e.g. a VME-based system). OAF software has access to all the devices assigned to it, either accessing the devices as a whole set, or picking out particular devices by name.