Java Data Acquisition Engine

last updated:  27 Jan 98

This note outlines current ideas for Java supported data acquisition. Data acquisition in the VMS version of the ACNET control system encompasses several services and APIs (Application Programming Interfaces).  Present use of Global sections, servers, library routines, and the ACNET messaging protocol combine to provide a relatively raw accessibility to control system data.  As the control system embraces object oriented design and programming, looks to exploit commercial software packages, and seeks cost effective implementations (measured in dollars, manpower, and maintainability), many technologies have undergone scrutiny.  Java is best poised to deliver these desired features.  This document will attempt to present a coherent vision for supporting data acquisition, explain the rationale of some of the choices, and suggest an implementation strategy.

• VMS provides neither a Java virtual machine nor an expansive vendor set of inexpensive CORBA products.  VMS has no future.
• The ACNET messaging protocol's inherit limitations do not fit with the trends in more modern control system architectures.
• Most messaging protocols employed today within this control system are not object oriented or portable.
• Services, tools, and expertise in the Java world continue to grow.
• Thinner clients are better; and Java invites this.
• By design Java provides an object oriented language within modern networking environments; in contrast to just being another objected oriented language, like C++ for example.
• No significant investment of effort in an operating system specific technology is desired. The Data Acquisition Engine--and other services as well--seek operating system independence and will therefore reject the utilization of the ACNET messaging protocol over the long term.

• The applet security model dictates a service on the node from which the applet was downloaded.
• Accessibility, security, thinness, encapsulation, consistency, reliability, efficiency, and flexibility will be exploited.
• It is time to change the model of data acquisition to further assist the front ends.
• This proposed architecture invites a path for migration of desirable attributes of the current and future data acquisition needs.

• Encompasses pooled, fast time plot and snapshot data as well as any redirected data source (dataloggers, save/restore, private database tables, models).
• Directly supports services such as dataloggers, save/restore, SDA.
• Implements the retryable, resource limiting error recovery mechanisms, like those found in save/restore and SDA.
• Provides the ability to have data acquisition requests persist over reboots and restarts.
• Implements reboots, downloads, and other front end services.
• Consolidates front end traffic across the control system with hierarchical based DAE front end responsibility chain.
• Establishes single point of control for bandwidth, security, and statistics.
• Uses only Remote Method Invocation (RMI) for applet communication.
• Uses binary tcp/ip-to-ACNET bridge for front end communication initially.

• The present ACNET device database will need to be expanded and enhanced to support this model of data acquisition.
• As services migrate to Java implementations, RMI becomes the standard interface with binary tcp/ip (perhaps through servers) serving non-Java applications.
• The front ends will be encouraged to migrate to RMI if available, binary tcp/ip if not.  The ACNET messaging protocol will be phased out over the long term.

Of course, all of this is subject to change.