Control System Studio (CSS)
6
The Java programming language and runtime environment allows the creation of software that can be
used on several operating systems like Microsoft Windows, Linux and Apple Mac OS X. The same CSS
application code can thus run in the control room as well as on office computers. While the Java runtime
might in certain cases be slower than a program that was specifically created for a certain operating system
in a language like C++, the speed is usually "good enough", and there are more advantages:
• Standard library covers basic data structures (lists, hash tables, ...) as well as network communication
for all currently used protocols. No need to re-implement the wheel.
• Excellent software development tools: Debuggers, Profilers. Even without a debugger one can usually
get a meaningful stack trace from a program that appears to be hung by sending the 'QUIT' signal to
it (at least on Linux and OS X).
It is hard to imagine that a program suite as complex as CSS could have been implemented without Java.
As Java code becomes more complex, it can be split into several library files called Java Archives or 'JAR'
files. The Java runtime can dynamically load and unload these libraries. Through introspection it is possible
to locate features in such JAR files. For example, one can create a Java program that communicates with a
control system, where the specific network protocol implementation is in a JAR file. While developing or
later extending the software, a test JAR file is used to simulate a control system. For the operational setup,
a site-specific JAR file connects the software to the actual control system. The same program can be used
at different sites because the site-specific portion of the code is "plug-able".
While Java supports such dynamic binding, it does not enforce a standard way to do this. The Eclipse
software framework provides three key elements:
1. Plug-Ins: A Plug-in is fundamentally a JAR file that the Eclipse runtime can dynamically load or
also unload. Each Plug-in contains a MANIFEST.MF file that describes dependencies, i.e. which other
Plug-ins are required to load a given Plug-in. Eclipse will automatically load these other Plug-ins as
needed. The manifest file further defines which Plug-in content should be visible to other Plug-ins, and
what is only accessible to code within the same Plug-in.
2. Extension Points: A Plug-in can define interfaces called extension points. An example would
be an interface for getting data from a control system. Other Plug-ins can then implement them. The
Eclipse Registry allows Plug-ins to locate available extension points.
3. Rich Client Platform (RCP): Finally, Eclipse provides a complete application framework
that is based on extension points. The entry point of the application itself, i.e. the "main" routine of the
application, is an extension point. Items that are meant to appear in the menu bar are contributed by
Plug-ins via extension points.
An Eclipse Product combines selected plugins with configurations files and a Launcher.
Traditionally, Java products require a Unix shell script or a Windows batch file to set certain environment
variables, configure the Java CLASSPATH, and finally invoke the Java runtime. Eclipse provides each
product with a Launcher, which is an application native to the operating system. The Launcher can display
a “Splash” screen, locate the Java Runtime, configure it, and finally start the product. To the end user, an
Eclipse product thus looks just like any other application that is native to the operating system. CSS has
icon and shows up as CSS in the task bar or process list, while traditional Java programs often appeared
as shell scripts. While almost all the CSS and Eclipse Java code is fully portable across operating systems,
this Launcher is specific to an operating system.
Another part that is operating system specific is the Eclipse Standard Window Toolkit (SWT). Java itself
provides the Abstract Window Toolkit (AWT) to generate user interface code. At least in the past, AWT
had an appearance that clearly differed from the native user interface of the operating system on which a
Java application ran. The Eclipse community developed SWT, which always uses the native user interface
elements of an operating system. For example, SWT on Mac OS uses Cocoa widgets, while SWT on
Linux uses GTK widgets. The Eclipse and CSS code mostly uses SWT in a transparent way, but when