JAVA-BASED OPEN ACCESS FRONT ENDS IN THE FERMILAB CONTROLS SYSTEM ... - PDF document

JAVA-BASED OPEN ACCESS FRONT ENDS IN THE FERMILAB CONTROLS SYSTEM D. Nicklaus, Fermilab, Batavia, IL 60510, USA Abstract 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 Ethernet-capable 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 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 Java-based 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 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 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 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. Most of the existing OAFs can be grouped into one of Utilities General purpose computing Single instrument front-ends Implementation of a specific algorithm Utility OAFs Some of the control system utilities that have been implemented as OAFs at Fermilab are: Monitoring the status of other front-ends, OAFs Reflecting settings into readings for test purposes Logging clock events and state changes Scheduled “big saves” of all devices. General purpose computing OAFs We’ve constructed several general purpose OAFs which produce readings for their assigned devices by combining readings from other device in various ways. One evaluates an algebraic expression of component devices. Others concatenate readings of the components into one larger composite device. Another performs various time-averaging algorithms on the specified devices. In all these cases, the algebraic equation or list of component devices is stored in the control system’s relational database and downloaded to the OAF at startup. Single instrument front-ends In this category, OAFs are used as traditional front-ends --- providing an interface into the control system for a particular hardware device or instrument. Typical applications here include interfacing with an Ethernet-enabled oscilloscope or A/D card, or an industrial controller. There have also been abstract OAF classes written to handle a general type of instrument such as an A/D card. Implementation of a specific algorithm This type of OAF implements computations too complicated to be expressed in a simple algebraic equation. An example is emittance calculation using flying wire device readbacks and information from other devices and models. READ/SET INTERVENTIONS A key feature of the OAF programming model is the ability to insert code to be run before and/or after a device is read or set. We call this code an ``observer’’ and there are BeforeReadObservers, AfterReadObservers, BeforeSetObservers, AfterSetObservers, and others. A BeforeReadObserver might be used when a user requests the reading of a device assigned to the OAF. The OAF could call the BeforeReadObserver which could then acquire a reading from the remote instrument, and set that value as the value to be returned to the end user. A Before- or AfterSetObserver can be used to pass a setting sent to an OAF device along to a remote instrument, or to issue the proper sequence of actions required to carry out a reset command. The OAF can also be notified before or after a periodic read of a list of the OAFs devices is started. This allows the OAF to more efficiently handle the periodic reads of its remote instrument or other devices. An OAF can also receive notification of when a download of information from the database about this OAFs devices has been completed. This allows the OAF to react to changes or additions to its list of devices on-the-fly. FEATURES FROM JAVA Since the OAFs are implemented in Java, an object-oriented language, the OAF environment inherits several desirable features. Information Hiding I consider “information hiding” the most important feature of object-oriented development using Java. Information hiding allows the developer to use an existing Java class without having to know many details of its implementation, only worrying about the software interfaces the new Java code is using. It only requires a handful of Java statements to implement a simple OAF which just reflects settings back into readings. This simple OAF’s devices instantly support the core protocols of the Fermilab ACNET control system. From this simple skeleton, the OAF developer might add before- or after- read- or set- observers to intercept readings or settings, or other custom programming. Other OAF programming tools There are many other tools available to the OAF programmer, using other Java classes already developed at Fermilab. There are classes to read or set other devices in the control system, to create jobs performing periodic readings of other devices; for interaction with the controls system relational database; for receiving notification of accelerator timeline events or state changes; archival data logging; and much more. Development Environment There are several high quality software engineering interactive development environments (IDEs) available for Java, such as Jbuilder, Visual Café, Forte, etc. Use of such IDEs greatly improves the productivity of software developers. An important feature of these Java IDEs is to assist the developer in perusing the growing set of Java software developed in the controls department. CONCLUSION The OAF environment has proved to be a very versatile framework for implementing virtual front-ends. OAFs have been developed to service a wide variety of interfaces, including UDP, TCP/IP, CORBA, XML/RPC, JNI, and SCADA, and for a variety of application types including calculators, instruments, industrial controllers, and models. REFERENCES [1] http://www-bd.fnal.gov/controls/public/JavaControls.htm