# Presentation: 247297

## Control System Java MigrationJ. PatrickJuly 31, 2003

## Outline

- This talk based on overview from tutorial June 23/30
- General overview, limited practical details
- Slides from all 4 talks from that tutorial are on the web
- _[http://www-bd.fnal.gov/controls/java/tutorial_june_2003](http://www-bd.fnal.gov/controls/java/tutorial_june_2003)_
- Linked from controls home page

## Tutorial Talks

- _June 23_
- Overview (J. Patrick)
- What we are doing and why
- Getting Started, Basic Guidelines (C. Schumann)
- PC configuration, programming basics
- _June 30_
- Data Acquisition (K. Cahill)
- Application Framework (A. Petrov)
- How to write a standard application

## Tutorial Goals

- Provide overview of what we are doing, and why, and what we have done so far.
- Give a flavor of how to get started writing applications
- Provide pointers on where to obtain more information
- Not a language tutorial
- Not a “hands on” tutorial
- We don’t expect you to remember every detail, but at least learn how to get started

## What Are We Doing?

- Migrating control system functionality away from VAX/VMS
- Gradually...
- New software is based on the Java language/platform
- Operating system agnostic
- Began over 5 years ago! (K. Cahill)
- Started with infrastructure, central services (no user interface)
- Starter applications were Notify, SDA suite
- The vast majority of OACs have migrated in the last 1.5 years
- Other applications have been done as well
- But a small fraction of the total number in the control system
- Currently ~3000 classes, ~500K non-comment lines of code

## Why?

- Not because the current system is bad
- VAX/VMS is obsolete
- VAX hardware unchanged in ~10 years
- VAXes not manufactured for several years
- HP even trying to get people off of Alphas running unix
- ~12-30 MIP machines; < few % of typical desktop PC
- Younger people have never used it
- Little support for newer tools, languages
- Little support for old stuff either
- e.g. Sybase library unsupported for years
- Non-standard user interface and other programming
- Maybe some of the developments in computing in the last 10 years might prove useful...
- Newer technology is used in many areas outside the core controls software...

## From Recent CDF Shift Training...

## Constraints

- No long shutdowns to replace large blocks of functionality
- Precludes fundamental redesign of the system
- Parts of new system must be plug-compatible/communicate with old
- Must be able to easily switch new things in and back out and/or run them in parallel
- “Scorched-earth” is much harder anyway...
- No big pile of money to replace everything
- Base on inexpensive commodity computing equipment
- Many small PCs/unix boxes rather than few large systems
- No big influx of new people for a parallel effort
- Work must be done by existing lab personnel.
- No long break to learn a new system
- New languages, tools etc. should have modest learning curve
- A lot of code written by non-Computing Professionals
- New system needs to be viable through 2010? 2012?

## Why Java?

- Modern, Object-Oriented Language
- Very much easier to learn, program and maintain than C++
- Focus on learning object-oriented programming
- Very popular and well supported
- Modern programming tools (Integrated Developer Environments)
- Basically platform independent
- Same **object** code runs on Windows, unix, Mac
- Web integration
- Launch programs from web browsers
- Excellent bundled libraries
- Graphical User Interface
- Threads
- Networking
- I/O
- Database access

## Java Overview

- General purpose object oriented programming language
- Potentially better code organization
- Potentially better code reuse
- Borrows basic syntax from C/C++
- But leaves out a lot, no obligation to compatibility
- C++ without *, #, ->
- Source code compiled to processor independent “byte code” (psuedo-assembler code)
- No link/load step, linking is done at run time
- Java run-time interprets and runs byte code
- Locates and loads code as needed
- Gradually compiles to optimized processor specific machine code
- Still slower than C/C++ code for various reasons

## Java Advantages

- Much simpler language than C++ (or even C)
- Transparent memory management
- Automatic garbage collection
- no malloc/free
- no memory leaks (almost)
- No pointers (no int *(*i[10])(int **p))
- Memory overwrites/array overruns are **impossible**
- No preprocessor macros
- No global variables
- No templates
- No operator overloading
- String manipulation cheats

## Java Disadvantages

- Resource intensive
- Memory, CPU
- Performance is < C/C++
- Greatly improved since initial releases
- Adequate for control system type applications
- Performance limitations due to front-ends, networks, database access as well as CPU power
- Most things are still going to be much faster than on a VAX!
- It is harder to write FORTRAN in Java than in C (or C++)
- Which is claimed to not be a disadvantage...
- Forces at least some attention to object oriented design

## Control System Overview

- Sun Netras
- (computer room)

- PCs
- (anywhere)

- Front Ends
- (anywhere)

- ..................

- (16)

- ...........

- ..................

**RMI**

**ACNET**

**ACNET**

## Control System Overview

- Applications generally run on PCs (or nova etc.)
- Data Server Engines (dse, due, dpe)
- Run on Sun Netra systems in the computer room
- Bridge application communication protocol (RMI) to ACNET
- Insulate misbehaving applications from daes
- Some application logic can be performed here
- Boxes also run Open Access Clients (psuedo front-ends),  servlets
- Data Acquisition Engines
- Consolidate requests across entire control system
- Each of 16 dae’s is assigned a set of front-ends
- Provide missing front-end functionality:
- Make all devices look equivalently supported to high level code
- Collection on clock event, event + delay
- Collection on state transition, transition + delay
- FTP/Snap if not supported by front-end (15 Hz limit)
- Front Ends
- Work with new system without changes

## Code Management

- Code kept in CVS repository
- _C_oncurrent _V_ersion _C_ontrol
- By far the most widely used product
- Code and history is viewable on the web
- GUI and command line interfaces
- Currently not as convenient as MECCA
- Releases made of full code base by experts
- Routinely done, <once/day>
- Working on a system to release individual applications

## CVS Web

## Integrated Developer Environments

- Integrated editor, compiler, code browser, debugger
- CVS integration
- Potentially more efficient development
- But requires investment to master
- Several choices of free and/or inexpensive products

## Integrated Developer Environments

## What Infrastructure Exists

- Application framework
- Provides common infrastructure for applications
- Capture, mail, etc. utilities like VAX program tools
- Message capture, application monitoring
- Post images directly to e-log!
- Management of dXe connection
- Open Access Client (OAC) framework
- Makes it rather easy to write an OAC
- Access to entire control system (readings/settings)
- Database access
- Plotting
- Synoptic display infrastructure/drag&drop builder
- Finite State Machine infrastructure including graphical builder
- NOT a straight port of CLIB/User Libraries
- Likely there are missing pieces in the above

## Data Acquisition API

- ACNET API (dio_, datalogger_, etc.) reorganized
- DaqJob (what, from, to, when, who, control)
**what**: device(s)
**from**: Accelerator, DataLogger, SaveFile, SDA, Mirror, Model, ...
**to**: your code, Accelerator, Mirror, Model, DataLogger, SaveFile...
**when**: now, later, clock event (+delay), state transition (+delay), ...
**who**: who is making the request and from where (privileges)
- Still based on “power supply” device paradigm
- The infrastructure allows the potential of manipulating structured sets of devices

## What Infrastructure Doesn’t Exist

- Functionality of most machine specific VAX User Libraries
- Though functional equivalents exist in some cases
- Numerical methods/linear algebra use not extensive so far
- Usage in autotune, some other places
- Third party packages exist that should satisfy requirements
- Full support for GPIB/specific scope models
- Lowest level infrastructure exists, needs to be built up
- We will do this as people ask for it.

## Routine Operation

- Big Saves
- All Data Loggers
- ~45 Open Access Clients (OACs)
- Only ~6 remain on VMS to be migrated
- Some are general purpose: CACHE, MACALC, BATCH, TIMEAV
- All SDA tools
- Configuration, acquisition, viewers
- MiniBoone autotune
- Eventual use in Electron cooling, SY120

## Security

- Must be on Beams network for
- Direct access to control system devices
- Direct access to the database
- And therefore to run most applications
- However:
- Versions of primary infrastructure applications have been written that can be run from outside the beams network
- Parameter page
- Data logger plotter (D44)
- Device Database (D80)
- Others
- Some of these use the web browser as the client and “servlets” as the server part inside the firewall, proxied through www-bd.fnal.gov
- Xml-rpc can be used to perform readings, set cache type devices
- Lower rate capability, less flexibility
- Can be used by non-Java programs to access control system data

## Application Startup

- Application Index
- Catalog of applications
- Web page (http://www-bd.fnal.gov/appix)
- Standalone program (like Windows Explorer)
- Click to start programs
- Can start both normal and browser based applications
- Java Web Start
- Most efficient startup method
- Only Java need be installed on your PC
- All required code is automatically copied to your PC and cached
- Program starts and runs on your PC
- Possible to start some programs manually from P:\AppsRunFiles
- Most sensible for standalone Application Index
- Not always well maintained for other programs – now deprecated

## Application Home Page

## Application Index

## Infrastructure Applications

- Notify
- Parameter Page
- Device Database Examine (D80)
- Data Logger Plotter (D44)
- Synoptic Display
- With drag and drop builder tool
- All of these have versions that run outside beams network
- No settings of course

## Parameter Page

## Device Database (D80)

## Data Logger Plotter (D44)

##  Array Plotter

## Synoptic Display

## Controls Machine Applications

- SDA
- Everything; configuration, data acquisition, analysis tools
- Low Beta QPM
- Now default for operations
- Fixed target autotune
- MiniBoone, SY120, electron cooling
- Booster BPM diagnostic
- Tevatron Vacuum
- Linac - various

## Autotune

## External Machine Applications

- Tevatron:
- Array Display (R. Moore)
- Mountain Range Display (R. Moore)
- Pbar:
- Vacuum display (J. Budlong)
- Performance plots (P. Derwent)
- Booster:
- General waveform monitor (G. Guglielmo)
- Magnet Move (A. Waller)
- Linac:
- TransRec display (B. Bolek)
- General:
- “Studies” application (L. Piccoli)

## Pbar Vacuum

## Resources

- Books
- Ask us for suggestions
- Web Sites
- _[http://java.sun.com](http://java.sun.com/)_
- Considerable documentation + tutorial
- Controls documentation
- _[http://www-bd.fnal.gov/controls](http://www-bd.fnal.gov/controls)_
- Applications, Application Development Guide, Java Work Information, Guide to the Data Acquisition Engine, ....
- Controls examples
- P:\gov\fnal\controls\examples
**Ask us!**

## What Should You Do?

- Spend at least some time learning about this
- Use existing applications and provide feedback
- No harder to start than VAX versions
- Suggest an application that might be useful
- New functionality
- Improve automation
- Address deficiencies in VAX version
- Take advantage of functionality in Java API
- If better performance useful
- Try writing a simple application to gain experience
- Rather than blindly port VAX code, we would like to be driven by what would be useful for the accelerator
- We will provide whatever infrastructure is required
- We will provide whatever personal help people need
- We will write programs that people suggest

## If you want to start writing...

- Talk to us
- Look at examples
- Read “Application Guidelines”
- http://www-bd.fnal.gov/controls/java/guidelines/ApplicationGuidelines.html
- Read “Application Development Guide”
-  _[http://www-bd.fnal.gov/controls/java/getting_started_guide/GettingStarted.html](http://www-bd.fnal.gov/controls/java/getting_started_guide/GettingStarted.html)_
- Read “Application Framework”
- _[http://www-bd.fnal.gov/controls/java/framework/guide/index.html](http://www-bd.fnal.gov/controls/java/framework/guide/index.html)_
- Talk to us some more
- If there is something you need in the infrastructure, we will provide it

## Summary

- Migration of high level control software to Java is ongoing
- Extensive infrastructure exists
- Data Acquisition
- Application and OAC Framework
- 90% of Open Access Clients have been migrated
- A modest number of applications exist – Feedback welcome
- System department input would be beneficial