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:
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.
Figure 1: The Vision graphical user interface
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.
Figure 2: Example of a tree of user interface objects
Visibility is defined by the following rules:
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.
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.
Figure 3: Example of a tree of event handlers at runtime
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.
Figure 4: establishing a common data model
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.