2. Centralized Visualization with Vision

A corporate sponsor of our institute triggered the Vision project when they decided to make a switch from a user interface which just incorporates graphics to a truly graphics oriented one. Looking for a ready to use product at the beginning, the restrictions for the user interface which finally lead to a new development were:

• low memory consumption
• low system run-time overhead
• the source code must be available to be able to act quickly and independently from the system vendor in case of an emergency
• predictable run-time behavior
• fit for long system up-times, i.e. > one year

In fact a Vision based application is now able to perform well on a i386 based machine with only 1MB of RAM. The current prototype runs on an MS-DOS based machine, though all hardware dependent parts of the implementation have been encapsulated to minimize the effort needed to create a micro-controller based version.

The first step in development was to design and implement the classes, which provide the human user interface and message distribution on a single computer. Similar to popular graphical user interfaces Vision implements its own interface with windows, buttons and menus.

2.1 Basic Structure

Each visible element of the user interface is represented by an instance of a corresponding class. Basic elements like buttons, or static text fields are atomic; they do not contain objects themselves. More complex items like windows are composed of a group object, which manages one or more other objects that are used as its building blocks. Thus object reuse is more frequently done by aggregation than by inheritance. Whenever an instance of a compound object is created, usually its constructor in turn creates all of its elements. However this is not required by the system. The elements of a compound object may vary during its life cycle. The best example for this is the object representing the global desktop, which also contains all currently existing top-level windows.

The visible user interface can be viewed as an n-ary tree whose root is the global desktop, whose nodes are compound objects and whose leaves are the atomic building blocks of the user interface.

Visibility is defined by the following rules:

• Each user interface object covers a rectangular area of defined size and position.
• Atomic objects are able to draw a screen representation, which defines the contents of the entire area covered by them.
• The screen representation of compound objects is defined by their elements entirely. Elements may overlap. The total area covered by the elements needs to cover the entire area of the parent. Elements exceeding the boundaries of the parent are clipped.
• Precedence of overlapping elements in the tree is left to right.

2.2 Events

Vision is an event driven system. Message passing between objects is based more on explicit events rather than method invocations. Each object is able to send and process messages. Sent messages are queued in Visions message queue, which is serviced by the object which forms the root of an n-ary tree of active event handling objects at runtime. The tree of visible user interface objects is part of this tree of event handlers, but not all event handlers are associated with an object on the screen.

Messages are represented as structures. To allow both different attributes for different kinds of messages and also different ways of determining the target of a message, there are four different structures to represent four classes of events.

• mouse events: Events specific for the mouse, which are always combined with the mouse pointer coordinates. Any event is passed to the top-most (=visible) user interface object covering the area, which includes the mouse coordinate. Events are passed down the event handler tree until the destination is found.
• keyboard events: Events generated when a key is pressed. Any event is passed to the atomic user interface object currently holding the input focus. Events are passed down the event handler tree until the destination is found.
• message events: Events generated for internal program communication. An event of this class either has a single object as specific destination or is a broadcast event sent to all objects.
• process data events: Events related to process data, either sent from or to the process controller.

After a particular event has been handled the type field describing the events class is set to the reserved value evNothing. This signals that the event has been handled properly and no further processing is needed.

In addition to ordinary event handling mechanisms there exist two special phases. The "pre-process" phase enables an object to monitor all events of a specific class, which occur in the system. The "post-process" phase allows monitoring of all events that have not been processed properly during normal event handling. To receive events in any of those two phases an object has to set this in its options via a method call. During the pre-process and post-process phase events are broadcasted to all objects registered for the respective phase. Sending all events through the entire tree of objects would cause a heavy performance penalty. Therefore whenever the option for receiving events in one of the two phases is changed the minimal subset of the tree required for event distribution is determined and a flag in each node is set accordingly for later use when these specialized broadcasts take place.

So when a message is read from the event queue, it is first sent through the event handler tree in the pre-process phase. Then it is sent either through the tree or directly to its destination depending on the type of the event. If the event was not processed it is then again broadcasted through the tree in the post-process phase.

2.3 Handling of Process Data

To be able to relate to specific process data values, both the visualization system and the process controller need to share a common data model for process variables.

On each system there exists a local copy of a common process data specification. There the individual data values which represent sensory input or target settings of the control system are defined together with unique ids and other properties, such as whether changes of a value are sent to the visualization automatically or only upon request.

Individual process data values may be visible on more than one instrument at a time, but need not be visible at all. To be able to access the most recent value of a specific process variable at any time and also to cope with the update problem when a variable is visible on several instruments at the same time there is a central object which handles these tasks during the entire up-time of a visualization system. This object is an instance of the class "Post" and because there exists precisely one instance of that class we also refer to that object as the "post". This concept is explained in detail in [MuEs94].

The post keeps track of all process variables. It handles the entire communication with the controller. When a new instrument is instantiated it has to send a special message to the post to register itself for a process data variable. When an instrument is closed the destructor automatically sends a message to cancel all registrations for that instrument. Thus the post knows all objects referring to a specific process data variable at all times and ensures the consistency of the displayed data by generating update events when necessary.