CSS Core Design Meeting

Shared by: ntz11397

Tags

web design, how to, web standards, css design, style sheets, internet explorer, cascading style sheets, css files, css file, context sensitive solutions, erik swenson, web 2.0, the meeting, web design company, expression web

Stats

views:: 22
posted:: 6/13/2010
language:: English
pages:: 11

Public Domain

Document Sample

Doc No: TDI-CTRL-MIN-0006
Issue: 1
CTRL Date: 14 August 2006
Page: 1 of 11

MINUTES OF MEETING
Title/Subject: CSS (Control System Studio) Core Design Meeting
Chairman:
Venue: Room 204, Building 55, DESY, Hamburg
Matthias Clausen
Secretary:
Time/Date: 7th – 11th August 2006
Emma Shepherd
PARTICIPANTS ADDITIONAL DISTRIBUTION
Matthias Clausen DESY
Piotr Bartkiewicz DESY
Jan Hatje DESY
Kenneth Evans ANL
Andre Grunow C1-WPS
Kay Kasemir ORNL
Igor Kriznar Cosylab
Judith Rock SLAC
Emma Shepherd DLS

Students:
Anze Vodovnik Jozef Stefan Institute / Cosylab
Blaz Lipusc Jozef Stefan Institute / Cosylab
APOLOGIES
Jurij Kodre Jozef Stefan Institute / Cosylab
Alen Vrecko Jozef Stefan Institute / Cosylab

AGENDA REF:
ATTACHMENTS:

1
Doc No: TDI-CTRL-MIN-0006
Issue: 1
CTRL Date: 14 August 2006
Page: 2 of 11

1. Agenda
Monday Tuesday Wednesday Thursday Friday
CSS DAL Configuration: Alarm handling CSS
Introduction Introduction VDCT and the (8) Management
(2) (5) EPICS IDE (6) and Update
(10)
General CSS DAL DnD Data Alarm handling Authorization
Discussion (3) Discussion (5) Types (7) (8) and
Authentication
(10)
Synoptic Strip Tool Configuration DnD Data Synoptic
Display discussion and continued (6) Types Display
Requirements demo (9) continued (7) Example (11)
(4)
Synoptic DESY Tour Data Viewers Wrap-up (12)
Display (9)
Discussion (4)

2. CSS Introduction
Control System Studio (CSS) is the name of a proposed new framework for creating Control
System applications. The main motivation for developing CSS comes from DESY: two new
projects (PETRA III and XFEL Cryogenics) are just starting up and would greatly benefit from
a suite of control system tools that:

1. Offer a common look and feel,

2. Run on several operating systems,

3. Provide an infrastructure for management, updates and logging, and

4. Interface to multiple underlying control systems (e.g. EPICS or TINE)

A contract funded by the German government is in place to develop version 1.0 of CSS in a
partnership with Hamburg University, C1-WPS (a Hamburg based company) and Cosylab.
The chosen platform is Eclipse, as this already has many of the features we need, as well as a
very large and well established developer community.

Current status

A prototype of the CSS-Core plug-in has already been developed. This is the central plug-in
that CSS applications will build on top of, and provides some basic functionality common to
all control systems such as logging and update management. Cosylab have also implemented a
prototype of the Data Access Layer (DAL); the „glue-code‟ layer between applications and
control systems. A number of test applications have been developed to demonstrate the basic
CSS functionality: these include an IOC browser and a record property viewer. Some work
2
Doc No: TDI-CTRL-MIN-0006
Issue: 1
CTRL Date: 14 August 2006
Page: 3 of 11

has also already been done at DESY to gather requirements for the key „real‟ applications,
such as the synoptic display tool which will be used to create and operate control system
screens. This application has the highest priority and it is hoped that C1-WPS will have a
working prototype by the end of the year. Other proposed CSS applications include:

 An alarm handler
 A data viewer (Strip Tool / Archive Viewer replacement)
 Programming and debugging tools
 SNL editor
 A data integration tool (for viewing associated offline data such as CAD drawings and
purchase orders etc.)

Meeting aims

The main aims of the meeting were to:

1. Review the current CSS-Core design and implementation,

2. Review the current CSS application prototypes, and

3. Design the key new CSS applications.

3. General CSS discussion

Architecture

The “Summary of CSS Workshop” presentation given at the EPICS meeting in June was re-
visited (please see
http://www.aps.anl.gov/News/Conferences/2006/EPICS/presentations.html).

There will be two contexts or user roles for running CSS:

 As an operator: CSS will run on the Eclipse Rich Client Platform (RCP), with only
the minimum set of plug-ins required to operate a control system (such as the synoptic
display, alarm handler and archive viewer applications). This essentially means that
access rights and software updates will be controlled, and users will be required to log-
in when starting the system.

 As a developer: CSS can run in a standard Eclipse installation, along with other
desired plug-ins such as the C Development Tools for example. This will be the full
suite of CSS tools, with no log-in required.

MB3

MB3 (Mouse Button 3) is the name given to the mechanism by which CSS plug-ins can
interact with each other. Plug-ins that are capable of performing meaningful actions on a
3
Doc No: TDI-CTRL-MIN-0006
Issue: 1
CTRL Date: 14 August 2006
Page: 4 of 11

particular data type can register as „MB3 receivers‟ for that type. When you use MB3 to bring
up the context menu on an object, you will see a list of all the MB3 receivers registered for that
type. For example, when you click on a record in an IOC browser, you might see options to
launch the Strip Tool plug-in to plot a graph, the JProbe plug-in to view its current value, and
the VDCT plug-in to edit the database that it belongs to.

A related but slightly different concept is that of „drag and drop‟ (DnD), which allows you to
drag an object from one view to another that understands that particular object type. The main
difference here is that the plug-in acting as the receiver for the object must already be launched
and visible to the user.

CSS-Core

CSS-Core is the central CSS plug-in that defines the essential extension points and some
generic functionality. Extension points that have been identified so far are:

 logManager
 iocReceiver
 cssManager
 mb3Receiver

One of the design goals is that this plug-in should also act as a bridge to avoid dependencies
between plug-ins. It was pointed out that avoiding inter-plug-in dependencies is not a feasible
long-term goal, but it is a good clean starting point.

Another key design feature is that a user should not be allowed to update CSS (running in
operator mode) with new plug-ins unless authorised to do so. This is the purpose of the CSS
Manager which will be discussed later.

Demo

Kay then gave a demonstration of a PV viewer that was first written as an Eclipse plug-in
using JCA, and then refactored to use some of the functionality in CSS so far (note it does not
use DAL yet). There were just two principal steps involved in the refactoring:

1. Adding calls to the CSS logging manager to centralise the logging
2. Implementing the MB3 interface to contribute a „PVViewer‟ option to the context
menu for records

4. Synoptic Display
This will be the first „real‟ CSS app, and it is aimed to have a working prototype by the end of
the year.

4
Doc No: TDI-CTRL-MIN-0006
Issue: 1
CTRL Date: 14 August 2006
Page: 5 of 11

Requirements

Some requirements had been gathered from DESY operators before the meeting, and these
were discussed here:

 It should keep the concept of separate view and edit modes (like EDM)
 Integrate with external tools should be possible(e.g. Acrobat to read PDF specs
associated with device)
 It should support different user roles, for example to distinguish between the
knowledge and skill required to modify help/tool-tip text vs. actual graphical layout
and PV bindings
 A graphics object library is needed, but developers should be in control of whether
library updates affect screens that have already been created
 The representation should be stored in XML, and the edit mode will allow you to
switch between graphical and XML views
 The appearance of widgets should be able to change depending on runtime PV values
 A scripting language behind controls is required for ultimate extensibility
 A (yet another) conversion tool from MEDM / EDM is also needed
 A „sitemap‟ view of a synoptic to show how displays link together should be available
 A tree view could be used to easily navigate between screens
 A zoom option would be useful to manage layers of detail
 Use of a VDCT style navigator was suggested to solve the problem of opening lots of
windows

JoiMint

A demo of JoiMint (Java Operator Interface and Management Integration Tool) was then
given. JoiMint is an XML driven GUI toolkit implemented in Swing; please see http://www-
kryo.desy.de/projects/JoiMint/docs/ICALEPS2001/ICALEPCS-2001-Paper.pdf for a detailed
description.

As a proof of concept, JoiMint has been quite successful, and it is envisaged that the CSS
synoptic display tool will have a similar architecture. However, it does have some
performance problems which will need to be resolved, and connection handling is currently not
managed properly.

Design discussion

The students from Cosylab had already spent some time „brainstorming‟ about the synoptic
display tool, so we discussed some of their ideas. It was commented that many of them
overlapped with the requirements already gathered from the DESY operators. The main topics
of discussion were:

1. How to assign process variables to widgets
A channel explorer should be available to allow users to drag and drop PVs onto the
synoptic. A naming service such as JNDI could be used. There should be a single
browser that can talk to multiple sources such as Channel Access, IRMIS etc.
5
Doc No: TDI-CTRL-MIN-0006
Issue: 1
CTRL Date: 14 August 2006
Page: 6 of 11

2. How to customize the appearance dynamically
Some kind of scripting language should be used, whereby PVs are mapped to local
variables and used to set various properties of the widget (such as colour, size and
visibility). It is possible that this feature might be mis-used and lead to too much
functionality being developed on the client side, but we agreed that this is a necessary
risk. The scripting language to be used is still to be decided; Jython was suggested.

5. Data Access Layer
The goal of the Data Access Layer (DAL) is to enable a generic way of accessing data from
multiple Control System sources. Although some sites use only EPICS, this feature will still
be useful as it will insulate applications from CA protocol changes in future versions. It also
provides a way to easily substitute simulations in place of a running IOC.

Design highlights

Terminology used:
‘property’ == EPICS channel
‘device’== container for properties and commands

The DAL distinguishes between data being „delivered‟ and „updated‟ (actually changed).
Cosylab currently has prototype implementations for EPICS and simulation (but not yet as
Eclipse plug-ins). A special protocol syntax is used for specifying property names, for
example DAL-EPICS:///myProperty or DAL-SIM:///myProperty

Design review comments

1. We need finer grained time stamps (the current implementation only has second
precision).
2. There is a requirement to be able to use DAL outside the CSS framework. It was
decided to keep DAL as a standalone library, and package it into a simple plug-in, with
no dependencies on Eclipse or CSS.
3. For use within CSS, how does DAL know what implementations are present? It was
proposed to use the Eclipse extension registry to determine this dynamically.
4. The Eclipse preferences framework should be used to allow you to select the default
provider.

6. Diagnostics and Configuration

VDCT and the EPICS IDE

Emma re-visited the “Future of Visual DCT” presentation given at the EPICS meeting
(http://www.aps.anl.gov/News/Conferences/2006/EPICS/presentations.html) and Ken gave a
demonstration of the EPICS IDE prototype (http://www.aps.anl.gov/epics/meetings/2006-
6
Doc No: TDI-CTRL-MIN-0006
Issue: 1
CTRL Date: 14 August 2006
Page: 7 of 11

06/Infrastructure/EPICS_IDE_in_Eclipse.pdf). Both of these applications fit into the
development mode of CSS, and should be able to be run in a standard full Eclipse installation.

An important requirement of the new CSS-aware VDCT is that the record model should be
independent of the graphical display.

VDCT could fit into the Control System Studio by:

1. Registering as an MB3 receiver for records and databases. For example, this could
provide the ability to navigate straight from a synoptic display to a database in VDCT.
2. Acting as an MB3 source of object data. This will provide integration in the opposite
direction, allowing you to launch JProbe on a particular record for example.

It was noted that it is important to anticipate this MB3 functionality from the start, as it may be
difficult to retro-fit afterwards. For this reason a detailed design should be done to ensure that
the data types are compatible.

A new idea for the VDCT plug-in was also suggested by Kay: a simple text editor for .db files,
using the same record model as the VDCT graphical editor. This should provide standard
features such as syntax highlighting, error checking, drop down menus for link fields etc.

SNL debugger

There are plans for an SNL debugger to be developed at DESY in the near future – we should
work together to try to integrate this with the new VDCT plug-ins.

7. Drag and Drop Data Type
An important requirement of CSS is to support drag and drop to exchange data both with
external applications (e.g. Gumtree and XAL), and within CSS itself. The main issue under
discussion was whether to use one or multiple data types for this purpose. One candidate
being considered for the single data type option is Service Data Objects (SDO), a standard
specification for data exchange being developed by IBM and other companies.

One factor involved in the decision is that in Java, in order to determine whether a particular
object can be accepted by a target, only the data type can be used (not the contents of the object
being transferred). This points towards multiple data types being the preferred choice.
However, Matthias is strongly in favour of extensibility, to allow new data types to be
contributed by new plug-ins. This could potentially be solved by the use of SDO, but it was
agreed that an SDO solution would introduce too much complexity for the first version of CSS,
and might put off developers from contributing. Registering new data types using the Eclipse
extension point mechanism might also be another solution. In any case, being able to add a
new variant of an SDO object does not solve the problem of other plug-ins not knowing how to
deal with it.

7
Doc No: TDI-CTRL-MIN-0006
Issue: 1
CTRL Date: 14 August 2006
Page: 8 of 11

After much discussion, it was decided to use an initial set of CSS data types, that people are
free to extend using Java inheritance if they wish to provide additional functionality. Kay is to
take the lead on designing these types for the first version.

8. Alarms
Part of the “Summary of CSS Workshop” presentation
(http://www.aps.anl.gov/News/Conferences/2006/EPICS/presentations.html) dealing with
alarm handlers was re-visited. Some work has been done at SNS to design an alarm pushing
system in EPICS whereby there is a dedicated alarm server that IOCs push alarms to and
clients connect to. This solves the problem of having to configure alarm handlers to be
interested in specific alarms, and means that new alarms that haven‟t necessarily been
configured yet on the client side can still be caught.

One requirement is to be able to use different alarm filters for:

 Logging alarms, e.g. to an RDB or text file
 Displaying them to the operator
 Invoking actions, e.g. sending text messages or e-mails

Another requirement is to be able to synchronise new alarm clients with existing IOCs. The
proposed solution is to use an LDAP server to keep the current state of all alarms. CSS
currently has an LDAP viewer prototype that you can use to browse this current alarm
information, select a particular record and use MB3 to launch associated plug-ins.

Alarm server implementation

The alarm server is essentially a message queue, and will be implemented using the messaging
standard JMS (Java Message Service). The chosen JMS provider is OpenJMSServer, and a
prototype implementation developed at DESY was demonstrated. This uses MapMessages
which contain multiple String name/value pairs for various properties including:

 TYPE
 EVENTTIME
 HOST
 USER
 TEXT

For a full list of the properties which have been defined so far, please see
http://css.desy.de/content/e339/index_eng.html. As there are currently no C libraries available
for creating JMS messages, the IOC (which is a simulation only in the prototype) simply sends
a byte stream to an interconnection server. This is essentially a small Java program that uses
the JMS APIs to create a MapMessage from the byte stream and forwards it to the alarm topic
in the JMS server.

8
Doc No: TDI-CTRL-MIN-0006
Issue: 1
CTRL Date: 14 August 2006
Page: 9 of 11

A Java application called a filter manager is responsible for forwarding filtered messages to
various topics (e.g. a „vacuum‟ topic for alarms related to the vacuum system). Alarm clients
subscribe to these filtered topics to get their alarm information.

Message filters

Filters are made up of Java „condition‟ classes that implement an interface containing a method
boolean match(String message). Any number and combination of condition classes can be
used in a given filter.

The configurations are stored in an Oracle database and edited using a web client (in the future
a CSS plug-in will be written for this purpose). This web client currently allows you to
enable/disable conditions, and connect them using logical operators.

BIRT

BIRT (Business Intelligence and Reporting Tools) is an Eclipse based reporting system. It has
been proposed to use BIRT in this context to query the RDB containing the historical alarm
data and create some useful reports. The output is in HTML, and formatting rules can be
configured to customize the output (for example highlighting specific words and changing the
font size etc). Graphs and charts can also be easily created.

9. Data Viewers
The category of data viewers encapsulates all the functionality currently available in Strip Tool
and Archive Viewer. It was suggested that these should probably be combined into a single
tool in CSS.

The requirements for a CSS aware data viewer were discussed:

 Configurability, e.g. showing/hiding axes and legends
 Multiple y axes (not currently available in Strip Tool)
 Zooming individual axes
 Auto scaling
 It should be simple to add new channels onto a plot
 Ability to annotate plots
 Launched through MB3 and DnD from other CSS plug-ins

Kay demonstrated some of these features in a prototype he has developed. The Swing vs.
SWT debate was also touched on briefly. There are currently no decent plot APIs available in
SWT, but there are some for Swing. There used to be problems integrating Swing into
Eclipse, but these seem to have been resolved now (since Eclipse 3.2 and Java 1.5). Ken
reported that he has had success with this integration.

9
Doc No: TDI-CTRL-MIN-0006
Issue: 1
CTRL Date: 14 August 2006
Page: 10 of 11

The conclusion of this discussion was that this is a very big development job, and more
detailed requirements need to be developed. Kay will take the lead on this.

10. Authentication, Authorization and Management

Authentication/Authorization

As was discussed earlier, this functionality is necessary for the operations mode of CSS (not
development). We decided that there is a requirement to be able to re-authenticate as a
different user within the same session, so as not to lose the workbench layout and settings.
This places some restrictions on the mechanisms that can be used, for example Eclipse „action
filters‟ can be used to prevent users from doing certain things, but these cannot be changed
dynamically. There was some discussion about whether operations that are not allowed due to
access restrictions should still be visible and disabled, or simply hidden.

For access to certain screens, it was decided to make use of defined symbols (such as a lock)
on the widget that launches them to indicate that they require special access rights. Clicking
on them would then open a new login dialogue.

The current design makes use of four fixed roles: guest, operator, engineer, and manager/super
user. It was proposed to extend this into a 2 dimensional matrix of groups (e.g. vacuum,
magnets,…) against role (guest, operator,…) for greater flexibility. The roles are fixed, but
groups should be configurable on a per-site basis.

Management

The CSS management plug-in encapsulates functionality for centralising control over multiple
CSS instances deployed at a particular site. The proposed solution is to maintain a central
repository containing information about all the currently registered CSS instances. One special
CSS instance (the manager) can perform operations on other instances, such as:

 stop()
 startUpdate() (for new plug-ins)
 getInfo()

The implementation could use the XMPP protocol used by the Eclipse Communication
Framework (ECF). The Cosylab students are to investigate this possibility. One advantage of
this approach is that it would enable users to drag and drop data (e.g. strip charts) between CSS
instances, and a chat client could also be easily integrated for text communication.

11. Synoptic Display Example
During the week, the Cosylab students worked on a simple prototype using the Graphical
Editing Framework (GEF). They demonstrated a design in which a screen is designed in so-
10
Doc No: TDI-CTRL-MIN-0006
Issue: 1
CTRL Date: 14 August 2006
Page: 11 of 11

called „layers‟, each one containing several „pages‟. An outline navigator view (like VDCT) is
used to move around the current layer.

The students felt that it wasn‟t clear whether GEF is the right tool to use, and so a full
evaluation needs to be done.

12. Conclusion

Current Infrastructure

All code developed so far is in the DESY CVS repository, and the CodeBeamer website
(http://elogbook.desy.de:8081/cb/proj/doc.do?doc_id=1632) is being used as a repository
browser and bug tracker, as well as a location to store general project information. You can
log in as user guest with password guest. There is also an Eclipse plug-in available for the
CodeBeamer bug tracker.

The current CSS website can be found at: http://epics-office.desy.de/content/index_eng.html
It was commented that this should be updated and a non-technical description of the project be
added.

It was agreed that CSS should not be tied to the DESY namespace, so a new name will be
registered: www.csstudio.org

Next steps

The meeting notes and presentations will be made available on the website as soon as possible.
A summary of the agreed actions and next steps follows:

 Igor to finish the DAL implementation

 The Synoptic Display tool will be contracted to C1-WPS and a working prototype
ready by the end of the year

 Emma to pursue funding for VDCT. Matthias proposed a more detailed feature design
of VDCT in the context of CSS to be done (by Cosylab); some funding might be
available from DESY for this

 Cosylab students to start work on prototypes of an alarm handler

 Jan and Kay to propose some basic CSS data types to use for DnD

 Kay to investigate possible solutions for the data viewer tool

 Cosylab students to investigate ECF as a possible solution for CSS management

 Everyone to keep in touch via the mailing list (subscribe on the website)
11

Related docs