4. Implementation details of key concepts

4.1 Centralized coordination and event replication by the Post

Communication between Post and control has its own rules. There is a data model, represented by a data definition file, which each stations and the control must have. This data definition file contains a description for all process data variables used in a Vision system. The description includes a unique variable ID which is used by all objects when they send messages concerning process data or register/deregister. A group ID entry is used for defining groups of variables which belong together. Groups are only updated, if the timestamps of all group members are identical. An example for groups are X/Y/Z axes. An entry length is used for dynamically allocating memory for process data, which is passed through a stations message queue. This enables Vision to handle huge process data packets without losing performance.

An important detail is the way how data comes from the control to the Post. There are two ways the Post can receive data from the control. A first one is that the Post behaves passive and simply waits for data from the control. This takes place when the update entry of a data description is set to auto or groupauto. Sometimes the control delivers sensor values faster than a human operator can recognize, or some data values may not be so important to be updated in short intervals. To avoid unwanted high network traffic the update entry can be given a timer interval, which is used by the Post for requesting new data values for a specific variable ID from the control. In this mode the Post is the active part who requests data while the control behaves passive waiting for the Post´s requests.

The following shows an entry of a Vision´s data definition file:

# diameter

name = diameter ; name of the variable
ident = 43 ; clear identification
group_id = 0 ; group membership
type = integer ; element type
length = 1 ; number of elements
update = timer:36 ; specifies, how the variable should be updated
controllable = true ; specifies, weather the variable can be modified
defaultinstrument = ... ; reserved for future improvements

4.2 Implementation of Instruments

All visualization Instruments are structured by the following hierarchy: At the top there is an instance of the class ViewWindow. This class traces a window with a frame on the desktop, which can be freely positioned. Within this Viewer multiple instruments (classes: GraphInstru, RoundInstru, AnalogBarInstru, ..) can be placed. Instruments again can consist of several displayelements. Displayelements are classes directly derived fromView: DispMicro, DispZoom, DispUpdate, DispCursor, ScaleGrid, ScaleVert, ...

This hierarchy allows to combine different displayelements within an instrument. Furthermore the complexity of instruments is reduced by dividing them into components.

Figure 7. Example for the structure of a display object

The class instrument is the basis class for instruments. Its constructor implements common behaviour like building a window, setting up the instruments background and displaying a titletext. Basic communication with the post is performed by the methods Register(ident), GetUpdate() and GetName(ident). Register(ident) must be called in order to become registered for the process variable ident at the post. If ident doesn´t belong to a group, the post sends the latest value immediately. Otherwise the instrument has to call GetUpdate() after the registration of the last variable to get the latest values right now.

4.3 A Graph Instrument

The graph instrument is used to figure process data as characteristic line with a cursor. The current value at the cursor position is shown in a separate part of the instrument. For displaying the whole graph there exists a reduced chart, where the part which is shown in detail is colored.

Figure 8. The graph instrument

This instrument consists of seven display elements:

 

Figure 9. Components of the graph instrument

A graph instrument can receive and handle the following events:

evCommand: This is an event, which carries new process data values. The instrument stores the data and plots the new characteristic curve. Afterwards the graph instrument has to free the memory where the delivered data was stored. Any receiver of process data must do this.

evKeyDown: Event for user interaction. It can contain the following key codes:

key_left: cursor one position to the left
key_right: cursor one position to the right
key_ctlleft: cursor ten positions to the left
key_ctlright: cursor ten positions to the right
key_pos1: cursor to position 1
key_ende: cursor to the end of the data array

4.4 VertAnalogBarInput - an example for an input instrument

This instrument consists of three display elements and can be used to manipulate process variables. It can handle both keyboard- and mouse events.

The variable, which the instrument is registered for, can be modified by clicking into the vertical analog bar. Its also possible to input new values by keyboard.

Figure 10. The vertical analog bar instrument and its components

Updating of a process variable by the instrument:

The instrument creates an event of type evCommand, which is addressed to the unknown receiver with destip = NULL and infoadr = NULL. Of course the events destination is the post, but instruments do not know the posts address. The event is sent along the object hierarchy until it is caught by VNetPrograms HandleEvent method. Because of the addressing to NULL this method recognizes that the event is meant for the post. It fills the fields destip and infoadr with the correct values and decides if the event has to be sent over network or not. When the event reaches the post the new process data value is distributed to all registered instruments as described above.

4.5 Failure safety

Failure safety is implemented on a level, which allows for the total failure of any participating station. The recovery time of the system depends on whether the station failed on which the post was running. If that was not the case, there is no perceivable delay in operations.

If the station running the post fails, all logical network connections break down. To be able to resume operations another station needs to create a new post and establish connections with the process controller and all other stations.

Figure 11. Presentation of the ICMP control connections

To accomplish that each station is capable of creating and running an instance of the post class. The decision on which of them has to actually do that is embedded in Visions communication protocol. It is essential that only exactly one new post is created.

The communication module manages a list of active station (LAS). The dead station is removed from this list. The station which detects that it is now the first in the list generates the new post and connects to the process controller. Through the same mechanism the other stations automatically know the network address of the new post and try to log in and register their instruments. If the first m of n stations fail at the same time, the m+1st station can not log in at the station, which should create a new post. After a defined time out, the station that should execute the post is declared dead and the m+1st station takes that position.

To recognize the failure of stations, the network layer periodically uses diagnostic messages to check the other stations. In the TCP/IP based implementation of the prototype ICMP (Internet control message protocol) packets are used for that purpose. An important property of the diagnostic messages is that they are transferred with priority over the logical connections, thus making it possible to distinguish between network congestion and station failure.

4.6 Network performance considerations

An important goal of Vision is safety. To reach this goal a fault tolerant connection oriented protocol is used for network communications. The disadvantage of the TCP/IP protocol used by the prototype and other similar protocols is that they do not satisfy real-time requirements. On the other hand this is not necessary for pure visualization. But it is important to have an estimate for the worst case response time.

As long as the data sources for a station do not generate more data than the station can process, the maximum response time is determined by the time needed for passing an event to its destinations plus the longest time needed to process an event. It is the responsibility of the programmer not to create event-handling routines, which take extended periods of time to complete. The event handling routines contained in Vision itself all take only milliseconds (depending on the hardware) to complete.

The maximum throughput measured on a test system using cheap hardware (i386-20) lies between 50 kB/s and 70 kB/s. Frequently process data does not arrive continuously but in bursts when a lot of sensor readings are taken during a short significant period of time during the process. This transfer characteristic presents the worst case for the system because although in the average there is enough transfer bandwidth the system might not be able to process the data as fast as it is generated.

The following diagram shows possible throughput and traffic density:

Figure 12: Network traffic overload

To solve this problem and to eliminate the necessity to dimension the hardware according to peak transfer needs Vision uses a smart buffering technique especially suited for process data. Only the latest measurements for individual process data values are buffered, while other data like Register/DeRegister messages are fully buffered. Therefore stations can survive long periods of network overload without getting problems with buffer overflows.

4.7 Communication module is replaceable (i.e. for different communication protocols)

As mentioned already VISION works with the TCP/IP protocol at the moment. This was fine during development, but TCP/IP isn’t used in common real-time systems. It was one of the development goals that communication protocols can be changed without big efforts. The design of VISION is extremely modular so changing the communication protocol is very easy. One only has to replace the communication module because this is the only part where network functions are called. The other parts of Vision don’t care where messages should go. Messages go through a distribution module, which decides if they are addressed to a different station. In this case a message is serialized, converted into a packet and passed to the communication module. There it is sent across the network according to the rules of the communication protocol used. The distribution module periodically asks the communication module for new data arrived from the network. If there is any, the packets are converted into messages, which are queued in Vision’s message queue.

 

Figure 13. Communication interfaces in Vision

The interface between the distribution module Post and the communication module doesn’t change, therefore there is no danger of side effects.


[back]

[beginning]

[forward]