Control System Studio (CSS)

1. Synoptic Display Studio (SDS) Jan Hatje, Matthias Clausen, Markus Moeller, Helge Rickens DESY, Hamburg Abstract SDS Workbench The Synoptic Display Studio (SDS) is an application to create, manage and run displays for control systems. It will replace dm2k at DESY and is integrated in the operating system independent platform Control System Studio (CSS) based on Eclipse. All widgets of SDS (bar graph, meter, polygon, …) are separated components and are inherited from an abstract widget model. To add new widgets the developer has to extend the java classes of the abstract widget model supported by the eclipse extension mechanism. For the communication with the control system SDS uses the Data Access Layer (DAL) integrated in CSS. Therefore it is possible to show values of different control systems in the same display. The settings of a display are stored in XML format. SDS provides an editor with rich functionality to arrange and configure the widgets for a display. It is not necessary to have any programming knowledge to create displays. To reuse the current dm2k displays an ADL-Converter has been developed. It converts the adl files into XML files of SDS displays The SDS workbench is a combination of navigator, property view and the editor in CSS. It is offered as a CSS perspective. Navigator: shows all configuration files for SDS displays (and files for other CSS applications) organized in projects. It provides the standard Eclipse CVS support for revision control and group development of SDS displays. Widget palette Workspace Editor field Property View Motivation Editor: shows a SDS display in editor mode. Unlike the run mode the channels are not connected to avoid accidentally updates. Functions like grid, ruler, alignment, match size for selected objects, … assist arrangement of widgets. On the right side of the editor is the widget palette with all available widgets. Property view: shows all properties of the currently selected widget in the editor. If more than one widget is selected only the common properties are displayed and can be changed for all widgets. Dynamisation and Rules Each property of a widget can be dynamised. That means it is connected to a process variable (PV) and depends on the changing of the value. A very simple example is a dynamised text property showing the current value. The dynamisation of a property is indicated by a gear wheel. SDS Design SDS is built on Control System Studio (CSS) and the Graphical Editing Framework (GEF). CSS is a platform for any kind of control system applications. Like SDSCSS applications can be integrated as plugins in CSS. Because CSS is an Eclipse Rich Client Platform (RCP) it is operating system independent. The Eclipse open source project GEF and its part Draw2D provides an environment for layout, rendering and editing. CSS App. SDS CSS Core Rules manipulate values from PVs before the dynamised widget property is updated. On the one hand rules are necessary to calculate a new value with another data type if the data types of PV an widget property is different. On the other hand with rules any manipulation or transformation is possible. There are two kinds of rules: Java rules are implemented as java classes in SDS plugins. To add or change java rules it is necessary to edit java code and build a new SDS application. Script rules are implemented as script files. Unlike java rules they are located in the workspace of CSS. Therefore the user is able to edit and create script rules in a running CSS instance. The disadvantage is the lower performance compared to java rules. GEF/Draw2D Eclipse RCP Widgets Common parts necessary for every widget are located in abstract classes of SDS. Therefore it is easy to add new widgets by extending just three classes and adding special features for the new widget. SDS is using the Model-View-Controller design pattern from the underlying framework GEF. Each class of a widget corresponds to one element: WidgetModel (Model) – Holds all available properties for the widget. WidgetFigure (View) – Sets appearance of the widget. WidgetEditPart (Controller) – Defines behavior for user actions and events. For each widget one or more initializers can be implemented. An initializer sets all default properties for each new widget created by the user on a display. In the preferences the type of initializer is selectable. Control System CSS SDS DAL Rule: Double → RGB Widget Color Property PV 1 (Double) Widget Text Property PV 2 (Double) Connection and Condition States can be visualized by every property of a widget. Each state is mapped to a special value of the property and shows the current status on the running SDS display. Like static widget properties the configuration of dynamisation and connection states can be set in initializers. Draw2dFigure AbstractWidgetEditPart New Widget Alias NewWidgetEditPart NewWidgetFigure In case a record is used frequently in a display or widget an alias can be definedfor its name. To identify an alias it has to enclosed by character ‘$’. Aliases will be inherited to sub elements. E. g. aliases set for displays are available in all widgets and are overwritten if an alias with the same name is defined in a widget. NewWidgetModel IWidgetModel Action Data Access Layer (DAL) With actions users can execute commands on displays in run mode. Actions are related to displays or widgets and will be inherited like aliases. There are two types of actions: The Data Access Layer (DAL) is a layer to access dynamic data of control systems. It decouples the data access from the implementation for a specific control systems. EPICS TINE • Open as View/Shell: Open a new display from the workspace as a View or Shell. To reuse displays for similar facilities aliases can be passed to the new display. • Send Value: Write a value to the control system. Control System Studio (CSS) Data Access Layer (DAL) EPICS Plugin TINE Plugin TANGO Plugin ADL converter ADL Converter is an application integrated in CSS for converting ADL in SDS displays. EPICS Plugin EPICS Plugin EPICS Plugin EPICS Plugin CSS Plugin DAL stores for each Process Variable (PV) characteristics to reduce the number of connections to the control system. Characteristics are meta data of PVs like resolution or display maximum. The DAL notation for a PV connection begins with the prefix for the control system. After the delimiter ‘://’ is the PV name. Optionally a characteristic can be added in brackets followed by the data type.