Download UNIFIED ARCHITECTURE FOR TELE

UNIFIED ARCHITECTURE FOR
TELE-EXPERIMENTING
Hermann POMMER
Armin VEICHTLBAUER
University of Salzburg
Institute for Computer Science
Software Quality Lab
hotspot@utanet.at
University of Salzburg
Institute for Computer Science
Software Quality Lab
aveichtl@cosy.sbg.ac.at
Eberhard MÜLLER
University of Salzburg
Institute for Computer Science
Software Quality Lab
emueller@newmedia.at
Keywords:
Unified Tele-Experimenting Architecture (UTEA), Application Programming Interface
(API), Graphical User Interface (GUI), Object Model, Functional Model, Entity-Relationship
Model (ER-Model)
Abstract:
The paper provides a proposal for the design of UTEA. It basically consists of simple
client-server architecture with device drivers on the server side and a GUI on the client
side as a front end. Streaming media is used to supervise the execution of the experiments.
The UTEA is visualised with according graphics, and the process structure gives a short
overview of how to work with the system. The chapter “general description and
functionality of UTEA” provides the user manual in which also the GUI (with the
Scheduler) is illustrated. The final part of the paper contains several models which are
useful to describe the Tele-Experimenting system: The simplified object model
demonstrates the structure of UTEA, the function related model shows transformations of
data and its interdependence and the entity-relationship model illustrates a conceptional
database design. In conclusion UTEA is usable for every experimental environment due to
the design of generic components allowing easy adaptation for special purpose.
Additionally a new User- and Instrument Administration has been developed supporting
group management and giving special access rights. In order to give our TeleExperimenting system full functionality a scheduling system (reservation in a definite
timeslot, reservation in a queue) and a billing system have been worked out.
1
User interfaces of UTEA
1.1
Client-Server Architecture
Fig. 1-1 shows the Client-Server-Architecture of UTEA. It illustrates general objects
(Dependent on Experiment, Independent on Experiment) and their correlation.
Dependent on Experiment
Independent on Experiment
Vehicle
Microscope
Robot
Vehicle-Control
Microscope-Control
Server on Control
Room
Robot-Control
Internet
Interface
Filetransfer via TCP/IP
Mediatransfer via UDP/IP
Client-Server
Win98
Win2000
Linux
further Operating
Systems
Client GUI
Client GUI
Client GUI
Client GUI
Fig. 1-1 Client-Server-Architecture of UTEA [3]
1.2
Application Programming Interface (API)
The UTEA has two API’s (Fig. 1-2): Device-API, User-API. The Client-GUI is a Webbrowser with
HTML-Documents and Java-Applets (therefore the UTEA can be executed on every operating
system). The user can select different functions and set the corresponding parameters. All data are
transferred via TCP/IP [5], streaming media [8] via UDP/IP [5]. On the server side the Experiment
Control uses multimedia settings to create an Audio/Video-Stream [9], [10] and Time/InstrumentSettings control the experiment.
1
Experiment Control
Audio,
Video
Device
API
Server
User/Group- Administ. of
Administ.,
Instruments
Registration
Begin,
End
Multimedia- Scheduler
Settings
In/OutputParameter,
Media
InstrumentSettings
Analyser
DataAdminist.
Scheduler
Internet
Interface Client-Server
API
Filetransfer via TCP/IP
Mediatransfer via UDP/IP
Client-PC
Mediatransfer via UDP/IP
Client-PC
Client-PC
Client-PC
User-API
Client-GUI
Client-GUI
Client-GUI
Fig. 1-2 API of UTEA [3]
1.3
Process-Structure
Fig. 1-3 shows the Process-Structure in order to operate with UTEA. The ordinal numbers
demonstrate the typical usage of UTEA.
5a. Send controlled parameter to
instrument and save it in the data base
5b. Receive topic parameter and save it in
the data base
Instrument
Server
Interface
Database
Internet
Client-Server
2. Status Connected!/not Connected!
1. Login (Username, Passwort) or set up UserProfile
4. Confirm access rights via eMail
3. Select instrument and define group
6. Receive current output parameter
5. Book time for instrument and set
input parameter for experiment
7. Load analysis tool or data sheet
Client-PC
Webbrowser and
GUI
Fig. 1-3 Process structure of UTEA [3]
2
2
General Description of UTEA
This chapter provides a general description of the system architecture of UTEA, which makes it
possible to control remote laboratory instruments via the internet. A data base serves for the
initialisation and provides specific information [6] (like user profile, type specific instrument
parameters, experiment dependent in/output parameters, reservation information, specific system
settings). The experiment can be operated both Online [7] (supervised/controlled by audio- and video
feedback on the screen) and also Offline. In both cases there are different reservation possibilities. The
following table shows the correlation between a Type of Experiment and Scheduling:
Table 2-1 Correlation between Type of Experiment and Scheduling
Type of Experiment/ Online
Scheduling
Reservation in a
Fixed predefined times
definite time interval
Offline
Reservation in a
queue
Predefined time interval without
definite times;
Begin of the experiment is selected
with the "first- fit-method"
Predefined time interval without
definite times;
Begin of the experiment is selected
with the "first- fit-method";
The experiment beginning is
signalised via SMS, eMail etc.
Fixed predefined times
In order to finance the project, a charging system is introduced. Reservation in a definite time interval
will be combined with higher costs for the user than reservation in a queue.
The experiment can be prepared, executed and evaluated in offline mode by means of a local PC and
operating system with a Webbrowser. In online mode the computer also must be multi-media capable
for audio-visual streaming media [7].
In user-specified files media data (audio and video) and parameter data (experiment-dependent) can be
stored and later interpreted with analyse-tools [6]. This is realised by a data base to which also other
colleagues or group members shall have worldwide access with corresponding authorities (reading /
writing).
In a second construction phase asynchronous (like eMail, FAQ-Board) and synchronous
communication modules (like Live-Chat, Whiteboard, Videoconferencing tools) shall be integrated to
allow teamwork with other colleagues or to obtain help from teachers.
2.1
Functionality of UTEA
Via internet HTML-Documents are transferred by using Hypertext Transfer Protocol (HTTP). A
Webbrowser offers the user interface. After loading the main page from the server a general
description about UTEA and its instruments is displayed. At the bottom of the main page the service
buttons Registration, Disconnect, New User, Change User, New Instrument/GroupProfile, Change
Instrument/GroupProfile, Selection of Instrument(s) and Close UTEA are offered. The services
associated to the buttons are following:
1.
Registration:
A user must register at the system with Username and Password. If this is successfully carried
out, then the status is "Connected", otherwise the status is "not Connected".
2. Disconnect:
At any time, the user has the possibility to disconnect from UTEA again.
3. New User:
A user who uses UTEA for the first time must set up his user profile. This ensures that the user
must identify himself explicitly by a chosen Username and Password. Due to the fact that the
3
4.
5.
6.
7.
8.
operation of UTEA is combined with costs a billing system is required. In order to authenticate
a user a digital signature has to be used. You can get it in a national administration centre for
digital signature by sending personal authentication data (like first name, last name, address,
passport/identity card number, driver's license number). If your personal data has been checked
successfully, you will obtain your private digital signature. With that you can pay on the
internet. After sending a registration form for the UTEA to the user, which contains the user
profile, it has to be confirmed with the private digital signature. On the server-side a decoder
checks the digital signature and if the authentication holds, the user can operate with UTEA.
The amount of the charges depends on the type of instrument, the duration of reservation and
the type of reservation (reservation in a definite time interval, reservation in a queue).
Change User:
If a user wants to change his profile for any reason, then a registration in the data base is
required. After activation of the button Change User his user profile appears in a window of its
own and he only needs to modify the fields.
New Instrument/GroupProfile:
To be able to carry out definite experiments the user must set up a New
Instrument/GroupProfile. At this point the user has to decide himself whether he is a group
leader (default) or only a member of a defined group for a definite instrument. If the group
leader wants to supervise several persons, he can assign a (unique) group name which has to be
used by the group members. If a user is a group leader, then he also has reading access rights on
his members and therefore he can analyse their results. Beyond this there is the possibility that
the group leader also assigns read authorities which permit the single members to examine her
results mutually.
Change Instrument/GroupProfile:
If a user wants to change Instrument/GroupProfile, then first a registration in the data base is
required. After activation of the button Change Instrument/GroupProfile the fields of the
profile can be modified in an extra window.
Close-REX
UTEA is ended and the Browser-Window is closed.
Selection of Instrument(s):
If the user of the system has definite access rights to execute experiments then he can select an
instrument from the drop-down-menu in which a description of the chosen instrument and its
functionality are offered simultaneously. At the bottom of this side the buttons Settings,
Scheduler, Experiment-Online, Experiment-Offline, Analyser, Data, Back to the Main are
offered. The services associated to the buttons are the following:
a) Settings:
With the help of Settings the user can select his best connection to the WWW regarding to
streaming media. After that the client derives the best audio- and video format and informs
the server about it. Furthermore audio/video can optionally be turned on/off.
b) Scheduler:
Only one person at the same time has active access to the respective experiment (however
other persons have the possibility to watch the experiment passively). There are two
possibilities to book an experiment:
Reservation in a definite time interval (Fig. 2-1 – above):
In the graphical user interface a timetable is offered to the user showing which times
are booked by an experiment. Here a green joist means the "Own User Time" and a
red joist "Booked by other Users".
At first the user has the possibility to select a particular week and a particular day. In
the second step, he chooses the experiment time (e. g. 12:00-18:00), subsequently the
experiment duration of 6 hours is reported to him. After being sent to the data base
the selected times are represented graphically in the Scheduler (the "Timetable").
Beyond this the booked time can be cancelled by selection of the interval and
activating of the button Delete Reservation.
The system also guarantees that an instrument always is reset into its starting point
before a new test starts. Therefore the user reservation always represents the actual
4
beginning and end of an experiment. If the user has booked until 18:00 and it takes
two minutes to reset the machine, then parameter can be sent to the machine until
17:58. The remaining two minutes are reserved as time buffer (which is different for
every instrument) in order to reset into its original position.
An instrument at which the experiment end isn't foreseeable represents an exception.
This is signalled to the user as time-critical device by the database. If an experiment at
such an instrument lasts longer than the reservation time is foreseen, then the
following reserved experiments are cancelled in order to avoid an appointment
collision. In this case high safety is more important than guaranteed execution.
Reservation in an queue (Fig. 2-1 – below):
Such reservations can only be performed with not time-critical instruments. A
predefined time interval (e.g.: "10 min/30 min/1 h") can be selected and sent to the
data base by pressing the button Booking. After that the reserved interval(s) is/are
shown in the scheduler (in the listbox), and they can be cancelled by pressing Cancel
while they are selected. The experiments in the queue are executed in free timeslots
according to the “first-fit-principle”. To make such experiments online executable the
beginning time(s) must be signalled to the user via eMail or SMS.
The fees in a definite timeslot must be more expensive then in an indefinite (queue) because
in the latter free time slots in the scheduler are filled up. For this reason a better system
performance can be reached through intelligent scheduling.
c) ExperimentOnline and ExperimentOffline:
ExperimentOnline is chosen, if the user wants to have streaming media besides the device
control. Therefore an Audio/VideoReceiver [8] and a Control-Applet for the experiment are
downloaded. Now the user has the possibility to watch a regular experiment of others or to
initiate an experiment for his own with corresponding access rights. The appropriate
experiment parameters are entered in the Control-Applet and the file names for saving
in/output parameters for the later analysis are specified here. The parameters can only be
sent, if the status is active (experiment time has started). After sending the suitable
experiment parameters from the Control-Applet the Access control (Fig. 3-2 Simplified
Object Model ) checks the input parameters on their legitimacy (ParameterRange) in order to
prevent a damage of the machine. Subsequently the parameters are sent simultaneously both
to the data base for later analysis and to the Experiment Interface. After the experiment has
started, current output parameters in the Controller are shown and the corresponding
experiment parameters are saved in a file specified by the user.
ExperimentOffline is selected, if the user does not want to have any streaming media. Only a
Control-Applet corresponding to the instrument is downloaded which accepts input data and
stores it in the data base. From there in a free time slot the parameters are selected again and
sent to the Experiment Interface. All in/output parameters are also saved for the analysis in a
user-defined file.
d) Analyser:
In/output data can be loaded in an analysis-tool with graphical interpretation in an extrawindow. Moreover archive multi-media files corresponding to the experiment can also be
chosen. The analyser offers the user the possibility to interpret input/output data of the
chosen experiment corresponding to the user’s access rights. Not only the user, but also the
members of his accompanying group (if they have got reading rights from the group leader)
may have access to the archive data. This should promote group learning.
f) Data:
In/Output data are listed in an Excel table which can be downloaded in order to analyse it
offline.
g) Back to the Main Menu:
Here the user navigates back to the main menu again to take up corresponding services.
5
2.2
Example of a GUI
Fig. 2-1 shows an example of a GUI (the scheduler) in UTEA. It illustrates both the
reservation of a definite Time-Interval and the reservation of an indefinite Time-Interval.
S c h e d u le r 0 4 .0 6 .2 0 0 1 - 1 0 .0 6 .2 0 0 1
H e lp
S e le c t W e e k
S c h e d u le r
R e s e rv a tio n o f a d e fin ite T im e -In te rv a l:
T im e C ritic a l:
E x p e rim e n t T im e :
< N e in >
O w n U s er-T im e
0 :0 0
12 :00
18 :00
1 0 :0 0
R obot
1 0 :0 0
In stru m e n t:
A v a illa b le T im e :
6 H o u rs
B ooked
6 :00
1 2 :0 0
18 :00
2 4:0 0
B ookin g
Mo
D elete R es ervation
Tu
We
B ac k to Ins trum en ts
Th
B ac k to E xp erim en tO nline
Fr
Sa
B ac k to E xp erim en tO ffline
Su
R e s e rv a tio n o f a u n d e fin ite T im e -In te rv a l (Q u e u e ):
T im e -In te rv a l:
10 m in
R e se rv e d T im e -In te rv a ls:
B ookin g
3 0 m in
1 h
D elete R es ervation
B ac k to In s tru m ents
B ac k to E xperim en tO n lin e
B ac k to E xperim en tO fflin e
Fig. 2-1 Scheduler [3]
3
Appendix: Models of UTEA
3.1
Function-Related Model according to Rumbaugh [1]
User
Client
UserProfile
Audio Transmitter
Audio data
Audio Card
Raw data
Microphone
Video Transmitter
Video data
Video Capture
Card
Raw data
Video Camera
Data
Audio stream
(UDP/IP)
Experiment/GroupProfile
Video stream
(UDP/IP)
update
Time settings
Status parameter,
Output parameter
(TCP/IP)
Connection settings
Raw data
Input parameter
send
Access Control
Experiment
Interface
Instrument
Input parameter
Input parameter
Output parameter
Input parameter
Data base
change
Data
Data telegramms
(TCP/IP)
HTTP Server
HTTP
(TCP/IP)
Userdata,
Experiment/Groupdata,
Time settings,
Connection settings,
Archive data,
Archive media
(TCP/IP)
CGI(x)
CGI Sripts
HTTP(x)
Status OK
delete
verify
HTML Documents
UName, Password
TCP/IP
Fig. 3-1 Functional Model of UTEA [3]
6
3.2
Simplified Object Model according to Rumbaugh [1]
Dependent on Experiment
Independent on Experiment
has-a
ExperimentOnline
has-a
ExperimentOffline
has-a
has-a
has-a
Settings
send/receive
send/receive
has-a
OnlineControl OfflineControl send/receive
Scheduler
receive
send/receive
has-a
receive/send
receive/send
Access Control
has-a
has-a
has-a
send send/receive
receive
Experiment Interface
send/receive
send
receive/send
GroupProfile
send/receive
GraphicAnalyser
has-a
receive
send/receive
send/receive
send/receive
send/receive
receive/send
receive/send
HTTP-Server
send
Video Transmiter
has-a
send
receive/send
has-a
MediaPlayer receive/send
receive
send/receive
HTTP-Documents
send/receive
send
receive
UserProfile
Data
send/receive
send/receive
has-a
has-a
Registration
send/receive Analyser
send/receive
Audio/Video Receiver
Instrumentshas-a Main
has-a
has-a
send
receive/send
Database
receive/send
receive/send
Audio Transmitter
send/receive
receive
Video Capture Card
receive
send
Audio Card
receive/send
receive/send
receive/send
receive/send
receive/send send
receive/send
receive/send
Video
Kamera
Camera
receive
send
Microphon
Experimentiergerät
Device
receive
receive/send
Fig. 3-2 Simplified Object Model of UTEA [3]
7
3.3
Entity-Relationship Model according to Chen [2], [4]
FirstName
LastName
UName
Password
Zip Code
Street
Country
Location
Phone
Number
UID
UID
Group
Manager
ExpTypID
GroupName
GroupProfile
IS-A
IS-A
n
Settings
addInfo
Grroup
Rights
UserProfile
SID
PersNr
eMail
AID
selects
m
User
has access
Audio
Analyser
m
Password
VideoFormat
AudioFormat
Video
UName
m
1
Administrator
administrates
n
UID
m
has access
AdminID
n
m
OwnerPath
Data base
1
Data
books
ExpID
has
ALastName
Media
n
n
ExpTypID
administrates
ExpTypID
ExpTypID
ExpID
n
UID
AFirstName
1
Access
m
ExpTyp
has
n
m
n
has access
ExpTypID
Scheduler
ExpBuffer
ExpPark
AccID
SessionID
general
Descripton
IS-A
UID
IS-A
Critical
Descripton
Reservation
Queuing
Parameter
Range
freeWeek
freeDay
Timeslot
ExpBegin
ExpEnd
Timeout
Day
Week
resTimeslot
Fig. 3-3 Entity-Relationship Model of UTEA [3]
References:
[1]
[2]
J. Rumbaugh, “Objektorientiertes Modellieren und Entwerfen,“ Hanser München, 1993.
G. Vossen, “Datenmodelle, Datenbanksprachen und Datenbank-Management-Systeme,“
Addison-Wesley Bonn, second edition, 1994.
[3] H. Pommer, “Software-Design für Tele-Experimenting – Diploma,“ University of Salzburg,
2001.
[4] P. Chen, “A preliminary framework for entity-relationship models,” North-Holland Amsterdam,
1983.
[5] A. Tanenbaum, “Computernetzwerke,” Prentice Hall München, 1997.
[6] C. Röhrig, A. Jochheim, “Remote Control of Laboratory Experiments,” Proc. of the 19th ICDE
World Conference on Open Learning and Distance Education Vienna, June 1999.
[7] Project Page, “Reale Systeme im virtuellen Labor,” http://rsvl.fernuni-hagen.de
[8] Sun
Microsystems,
“Java
Media
Framework,”
http://java.sun.com/products/javamedia/jmf/2.1.1/index.html, April 2001.
[9] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, “RFC 1889 RTP: A Transport
Protocol for Real-Time Applications,” http://www.normos.org/rfc/rfc1889.txt, January 1996.
[10] H. Schulzrinne, “RFC 1890 RTP: Profile for Audio and Video Conferences with Minimal
Control,” http://www.normos.org/rfc/rfc1890.txt, January 1996.
8